Reprise du message précédent :
en tout cas, je pense pas que memcpy soit le point chaud d'une appli pédagogique.

yawen> Je ne traîte personne de "con". Ce que je déplore : La fausse "connaissance" - Ou croire que l'on sait. Alors qu'en fait, on ne sait jamais. J'ai aussi appris sur le tas, mais je me suis documenté, j'ai beaucoup lu et analysé pour comprendre et pas simplement recopier des programmes. On peut toujours apprendre par soi-même, mais cela demande de la rigueur. Mais même en cours, les élèves (souvent) considèrent les cours de prog comme du français, des maths, histoire... C'est là qu'est le problème.
Pour tes problèmes, il t'est toujours possible de te documenté pour savoir si ce que tu fait est cohérent. Ce n'est pas parce qu'un prog fonctionne qu'il n'est pas exempt de bug ou d'erreur de programmation. Je découvre parfois des erreurs dans les applis que l'on vend...
 
Taz> Tu vas comprendre avec un petit exemple :
- Faire un logiciel pédagogique performant, élégant (beau  design), fonctionnel, ergonomique, avec des animations, des effets... Le tout sous Windows et sur des bécanes anciennes.
Le plus gros problème n'est pas la pédagogie, même si cela représente souvent 50% du temps de dvlp, mais la manipulation graphique pose de gros soucis de vitesse. D'où l'intérêt d'un memcpy performant.
On ne peut pas demander à une école de changer son parc informatique sous prétexte que les logiciels nécessitent des machines gourmandes (comme c'est le cas pour Director et Flash).
 
Up> Il y a encore trois ans, je bossais avec Visual C 1.51 pour faire les applis sous Windows 3.11. On en vend toujours !

La suite...
 
Je vous livre une "grosse" astuce pour copier des éléments plus rapidement se trouvant en RAM, c'est le bloc prefetching.
 
En fait, cela consiste à faire des transfert par bloc, il sont temporairement stocké dans le cache L1 (merci la polution).
On va prendre un exemple concret :
 
-> On dispose d'un processeur ayant un cache L1 de 16Ko (on va le poluer entièrement). Les pentium std dispose de 8Ko.
-> Le processeur dispose de lignes de cache de 64 octets (32 octets sur pentium std).
-> On doit copier un bloc de 2Mo d'une zone vers une autre.
 
1. On découpe le bloc de 2Mo en 128 blocs de 16Ko.
 
2. On charge dans le cache 16Ko de données :

On peut faire un léger unrool de cette boucle pour améliorer la vitesse.
Maintenant que les 16Ko sont dans le cache, la lecture va être ultra-rapide !
 
3. On copie les données en lisant avec movq (MMX) et en écrivant avec movntq (SSE) - Il est possible d'utiliser movaps(SSE) et movntps(SSE). On peut utiliser également les fonctions FPU (fld/fstp) ou CPU, mais on va poluer le cache. Cela dit dans un processeur sans SIMD, on a pas le choix.
 
4. Il ne reste qu'à reboucler sur 2/3 pour copier les 2Mo.
 
 
 
Cette technique permet d'augmenter le débit de +50% à +100% suivant les machines. L'augmentation est souvent très importantes car les processeurs disposent souvent d'une ligne d'écriture de 16 ou 32 octets.
 
On est pas obliger d'utiliser une taille de 16Ko. Mais même si on utilise une taille de 8Ko ou 4Ko, le L1 sera complètement pollué si la taille totale dépasse sa propre taille (SizeCopy>SizeL1).
Le cache L2 est également souvent pollué puisque les données sortantes du L1 vont se retouver dans le L2.
 
Il existe également un variante (que j'ai mise au point), c'est le Half-BlocPrefetching ou Middle-BlocPrefetching. Cela consiste à organiser le code pour d'abord remplir la ligne cache puis finir la copie :
 

Dans l'exemple, on utlise également les propriétés du WriteBack. L'écriture juste après la lecture (5 premières lignes de la boucle) est partiellement masqué car il faut un grand nombre de cycles pour charger la données se trouvant en RAM (ou dans le cache L2 ?).
 
N'oublions pas que memcpy standard bousille complètement le cache L1/L2

christophe_d13>

qu'est ce que tu entends par rigueur ?
 

Me documenter où ? parce que si par exemple je veux savoir si la structure globale d'un de mes programmes est correcte (i.e. organisation des classes, héritages, constructeurs/destructeurs, etc...), le seul moyen de faire que je vois est de regarder comment font les autres et de comparer... ou alors de récupérer des cours de programmation et de les lire, si c'était ça que tu voulais dire...
 
désolé de sortir du sujet, au fait...
 
Taz>

tout dépend du niveau de l'application, qu'elle soit pédagogique ou pas... dans tous les cas, comprendre comment fonctionne le pc aux plus bas niveaux (i.e. assembleur, gestion de la mémoire, etc) ne peut-être que très enrichissant. Tu serais le premier à gueuler sur ceux qui font des conneries en programmation parce qu'ils ne comprennent pas ce qu'il y a derrière leur langage

n'empeche que ca reste de la sodomie de drosophile :|

Et l'altivec, c'est quoi ?
C'est comprendre mieux le matériel non ?
 
Aujourd'hui on est plus à faire des progs en ModeX ou tenter de faire des scrolls rapides et fluides. Mais juste gagner le plus de temps pour faire autre chose et décharger le CPU pour avoir de la marge et en rajouter.
Je précise que je suis programmeur système à la base (et optimiseur). Donc j'ai toujours développé en travaillant d'abord sur le matériel pour tenter de trouver un max de subtilités ou d'astuces.
 
Dans une appli que je développe en parallèle, je dois charger une cinquantaine d'images, les redimensionnés, les déplacer...  Tout cela prend du temps, et je ne peux savoir à l'avance quoi faire puisque tout dépend de l'utilisateur.
Après avoir fortement améliorer mes routines de chargement et de rotation, il ne me reste que mes bitblt et les bitblt (quand la transparence n'est pas géré), c'est du memcpy amélioré.
J'ai fait un test avec le bitblt de DirectDraw, celui de la GDI et le miens. Les BitBlt de DirectDraw est 16% plus rapide que celui de la GDI, et le miens est environ 60% plus rapide que celui de DirectDraw. Tout ça simplement car je sais à l'avance où se trouve l'image source et que le code est choisi pour être le plus rapide suivant l'emplacement.

Une vrai extension SIMD
 

Non.
 

Ben c'est pas l'impression que tu donnes
 

Aucun rapport.
 

Ben c'est mal .... désolé.  

Joel> Sur PC, t'as pas beaucoup de choix. Il en va de même sur les Atari ST et Amiga. On programmait plus avec de l'astuce qu'autre chose.
Sur toutes les machines, il y a des choses (matérielles) à connaitre : les latences cache et mémoire, les prédictions de saut du CPU...
Les seuls processeurs où il n'y pas besoin de connaître tout cela, ce sont les DSP (genre le DSP16). Toutes les instructions tournent en 1 ou 2 cycles et rien ne peut modifier la rêgle.
Alors s'il faut ruser pour gagner 1, 2 ou 10% de perfs en plus (ou plus encore), et bien si le temps le permet, il faut le faire.
 
J'oubliais, seul le résultat compte dans l'optimisation (cf concours No 4 dans la partie ASM), peu importe la méthode du moment que le logiciel est plus performant.

 
Ca fait plaisir de lire cela, je suis entièrement d’accord avec toi.  
 

 
si t'en est tellement a vouloir preserver ton cache, pkoi t'utilises pas movntq ?
 

 
y sert a rien ton push ebx (vs te le protege)
si tu veux gagner deux cycles sur ta routine, tu vire ton mov edx,64 et tu remplaces tes add machin, edx par des add machin,64, idem avec EAX (pkoi diable se priver d'un registre pour juste y foutre une constante ?), et tu remplace l'utilisation de ESI par EDX et EDI par eax, ca t'alege tes prolog / epilogue de fonction
 
 
(pis tiens, fous ta fonction en __declspec(naked) et hop, a la dure)

Comme je l'ai déjà écrit, j'ai globalement 4 routines de copie : Pour maximiser le cache L1, le L2, la RAM et un compromis global.
Au total, j'ai réduit mes routines au nombre de 14. Certaines utilisent exclusivement le CPU, d'autres la FPU, ou le MMX, MMX+SSE/3DNow!, SSE...
Ensuite, movntq c'est une routine SSE non compatible MMX. Donc très bien pour préserver le cache mais sur une Pentium II ou Pentium MMX, c'est nada.
 

C'est également ce que je croyais (c'est écrit dans la MSDN) mais je me suis rendu compte que les optimisations (-O2) de VC avaient des comportement bizarres avec les registres. Après plusieurs investigations, j'ai pris l'habitude de sauver EBX et parfois même EFLAGS (d'ailleurs, je pourrais mettre EBX dans une variable plutôt que via SS:ESP, mais cela limite la portabilité de certaines routines, et surtout, je peux rechercher plus facilement mes "push/pop ebx" pour les enlever, même si maintenant j'utilise une macro selon le compilo).
 

Car une constante "immédiat" alourdi la taille du code et surtout, on perd l'alignement par 2 ou 4 des instructions :
mov eax, ebx = 2 octets
mov eax, 8 = 3 octets
Grâce à cela, on gagne un poil de vitesse (en fait on évite de ralentir le chargement).
Update> C'est pourtant ce que je faisais pour mes routines de texturages puisque j'utilisais du code-morphing souvent avec les immédiat pour avoir des variables locales en Read-Only. Mais difficile à faire sous Windows. D'ailleurs si quelqu'un à trouver une astuce (pour modifier le code qui s'éxécutera 10 lignes plus bas après un JMP), je suis preneur.
 
 

En fait, dans les docs Intel, AMD et Cyrix, il n'y pas de différence dans l'utilisation des registres globaux, sauf pour ESP. Aucun de ces derniers n'ajoute de préfixe. En fait c'est le compilateur qui fait ce choix, dans TASM, il y avait, si mes souvenirs sont bons une option pour ajouter automatiquement les bons préfixes suivant les registres (ES pour DI).
Je rappelle par défaut (en adressage 32 bits) que tous les registres travaillent sur DS sauf EBP et ESP qui travaillent du SS. De toute façon, dans la majorité des programmes, DS et SS ont la même valeur, c'est le même sélecteur.
 
 
J'espère avoir été suffisament clair sur les choix que j'ai fait.

 
un poil faux, une constante immediate doit avoir la meme taille que l'operande de destination
donc mov eax,8 => 6 octets (ou 5, on peut coder mov eax, en un seul octet)
(c'est dans l'adressage, genre [eax + 2] que l'on peut faire varier la taille de l'operande (via les tres sexy mod bits))
(ca aide pas trop ton alignement sur 4, mais bon, aligner les instructions, bonjour)
 

 
oué, mais moi je te parle des conventions d'appels de fonction, une fonction est tenue de rendre EDI / ESI / EBP / ESP et EBX dans l'etat ou elle les a trouvé, le reste elle fait ce qu'elle veut avec. (sinon ca devient l'anarchie). Donc quand tu tapes dans edi (par ex), le compilo va te rajouter un push/pop dans les epilogues / prologue

Reli bien tes docs. Un immédiat peut être codé sur 8 ou 32 bits même si le registre est sur 32 bits.
 
Lis bien cela :
add esi, 64
est codé : 83 c6 40
 
à l'inverse :
add esi, 128  
est codé : 81 c6 80 00 00 00
 
enfin :
add esi, ecx
est codé : 03 f1
 
Elle est pas belle la vie ?
 
 

Tu as raison, je ne l'avais pas compris comme cela. Mais les comportement bizarres de VC avec EBX me font douter de l'éfficacité du compilateur. Mais tu as bien raison, il faut rendre tous les registres tels-quels (sauf bien sûr pour edx:eax).

@christophe_d13:
 
Et globalement obtiens-tu qqchose de plus rapide que le memcpy_amd ?
 
 

Je suis débutant en assembleur, et je n'arrive pas à passer le memcpy_amd en fichier asm. En effet j'essaye de porter un programme de traitement d'images sous le compilateur AMD64 de VS Whidbey, et ce dernier ne prend pas en compte les directives __asm. Si quelqu'un pouvais m'aider. D'avance merci.

l'assembleur inline __asm {...} n'est plus et ne sera plus supporté par visual. Et c'est bien dommage. Tu peux te reporter vers MASM64 (ml64.exe) qui compile du vrai code assembleur. Si t'arrives à t'en servir c'est que t'es très fort car il n'y a pas de documentation et appeler ml64 /? affiche l'aide de MASM 6.

maze123cool> J'ai des gains de temps importants puisque j'ai un programme qui manipule une grosse quantité de données (images).
Sur une machine récente, le gain n'est pas vraiment perceptible car c'est assez fluide, mais sur des P3-600, la fluidité devient vraiment très bonne !
A l'inverse, pour vous donner une idée :
Une fonction de copie (bitblt) à un gain de vitesse de x2 à x5 suivant le contexte et le processeur.
Mes fonctions de stretching sont passées de 28cps à 132cps.
Les fonctions memcpy n'ont que peu d'interêt puisque dans ce programme elles ne manipulent que de très petites quantités de données (moins de 1 à 256 octets).
Par contre ma gestion de cache mémoire y gagne énormément puisque je travaille sur des blocs (1 à 4 Ko). Le gain est variable, l'amélioration est perceptible, mais je ne l'ai pas mesuré.
 
Up> Dans tous la plupart des cas, c'est la technique du block prefetching qui apporte un gain de vitesse ainsi qu'une copie 64 bits (FPU ou MMX). Le hardware prefetching apporte rarement des gains importants.
Dans les routines de copie où la taille est définie lors de la compilation, il y a là un travail interressant à faire...
 

J'attend de voir ça... D'autant qu'avec gcc le support sera toujours présent.

Ouais enfin l'asm inline de gcc c'est une horreur : du AT&T dans des strings...
Je préfère passer par MASM.

Juste pour illustrer l'asm de at&t... Voici une petite routine au qui affiche un point en PAL8...

 
 
je suis presque arrivé à passer le fichier memcpy_amd.cpp vers un code MASM mais je ne vois pas pourquoi il me remplace la ligne suivante :
     mov [CPU_Type], eax
par celle-ci (en code machine) :
     mov dword ptr cs:[_CPU_Type (42D91Ch)],eax  
Et grace à ce remplacement j'ai une magnifique exception !
 
Le MASM est en plus super documenté j'adore !    
 
note : CPU_Type est un unsigned long.

Avec MASM quand tu as une variable* il ne vaut mieux pas mettre de crochets autour sauf pour lea.
 
exemple :
 

 
*En assembleur la notion de variable, de pointeur et de référence est confondu.

A noter qu'il existe aussi NASM pour linux, donc l'asm at&t n'est pas une fatalité

ouais des trucs portables il y en a, je pense simplement que :
 
- l'assembleur est assez répulsif comme ça pour en + se tapper une syntaxe dégueue.
- MASM devrait devenir une référence car c'est le meilleur assembleur actuel, il est toujours mis à jour, gratuit et utilisable sous Unix au prix d'une petite bidouille (il faut lui faire faire un OMF qui est ensuite converti en ELF avec objcopy).

euh, NASM c'est quand meme une reference

Une fois l'habitude de coder en at&t, je le trouve plus evident.