Discussion :

[Chevalier au taureau]

Bonjour à tous,

Depuis quelques jours je code des fonctions de calcul avec NASM sous Debian, plus pour m'amuser que par foi dans les résultats. J'ai testé les temps d'exécution avec les mêmes fonctions codées en C, compilées avec GCC. Il se trouve que contrairement à ce que j'imaginais et ce que l'on m'a enseigné, l'assembleur codé à la main va plus vite que le C compilé avec gcc au maximum de son optimisation. Les gains sont de l'ordre de 10% pour un incrément ( a[i] += b[i] ) à 400 % pour une racine carrée !
Alors, je ne vois pas bien où je me plante.
La première partie, l'incrément d'un vecteur de double, se trouve ici : http://les-sauvages.fr/Assembleur/Assembleur17.html
Je rédige la partie suivante, mais peut-être puis-je déjà avoir votre opinion sur le sujet ?

Cordialement.

[Obsidian]

Bonsoir,

Depuis quelques jours je code des fonctions de calcul avec NASM sous Debian, plus pour m'amuser que par foi dans les résultats. J'ai testé les temps d'exécution avec les mêmes fonctions codées en C, compilées avec GCC. Il se trouve que contrairement à ce que j'imaginais et ce que l'on m'a enseigné, l'assembleur codé à la main va plus vite que le C compilé avec gcc au maximum de son optimisation. Les gains sont de l'ordre de 10% pour un incrément ( a[i] += b[i] ) à 500 % pour une racine carrée !
Alors, je ne vois pas bien où je me plante.

Tu touches du doigt la réalité qui caractérise les compilateurs modernes : ils sont devenus beaucoup plus efficaces qu'on l'imaginait il y a peu encore.

Non seulement la théorie et les algorithmes qui utilisent ont eu le temps d'être affinés mais d'une part, les processeurs pour lesquels on compile se prêtent beaucoup plus au jeu que les anciens et, d'autre part, il devient difficile de gérer humainement tous les cas de figure qui entrent en jeu. Du temps du 486 (il y a 25 ans tout de même), l'exemple-type était le « DEC ECX ; JNZ etiquette » qui était plus rapide que l'instruction dédiée « LOOP etiquette » pourtant faite pour ça. Aujourd'hui, outre ces cas particuliers, il faut gérer proprement la ligne de cache, se souvenir de son état et éviter autant que faire se peut de briser le pipeline.

Si on arrive à maintenir manuellement à jour l'état de tous ces mécanismes, il faut ensuite faire des optimisations sur son propre programme, notamment en identifiant les ressources déclarées mais jamais utilisées, par exemple, et voir si certains points purement algorithmiques peuvent être simplifiés également, comme les boucles.

500 % de différence sur une racine carrée, par contre, ça commence à faire beaucoup. Le goulet d'étranglement doit provenir de l'algorithme lui-même, que tu utilises pour extraire cette racine. Il doit probablement y avoir plus efficace.

[Invité]

Utilise intel compiler, plutôt que gcc, tu verras la différence se faire.

Moi aussi je bas haut la main gcc avec mon asm, mais bon sous icl, c'est pas le cas :/

Honnetement je n'ai toujours pas compris pourquoi icl me devance de 200% de performances même aprés des heures d'analyse du code asm produit par icl, j'ai même reproduit dans l'intégralité tout son asm dans nasm.

Mais même en reproduisant tout l'asm code j'ai les mêmes performances que mon propre code.

Ceci ne peut pas très bien s'expliquer, mais il y a une info que j'ai oubliée, c'est qu'icl refuse de produire l'asm fil avec (/Qipo) active, et si on ne le met pas, ça plante lors de l'exécution du code (ça active toutes les optis du compilo sur le code).
Donc en gros, on ne peut pas voir ce qu'icl fait pour optimiser le code et me battre à plate couture

Bon je vais de ce pas, aller faire mon rapport sur intel developper zone.

Mystère et boule de gomme

[Chevalier au taureau]

Bonsoir,
Tu touches du doigt la réalité qui caractérise les compilateurs modernes : ils sont devenus beaucoup plus efficaces qu'on l'imaginait il y a peu encore.

C'est précisément ce que j'imaginais : les compilateurs modernes sont paraît-il efficaces. Pas si efficaces que cela car l'implémentation naïve est plus rapide qu'eux.

Non seulement la théorie et les algorithmes qui utilisent ont eu le temps d'être affinés mais d'une part, les processeurs pour lesquels on compile se prêtent beaucoup plus au jeu que les anciens et, d'autre part, il devient difficile de gérer humainement tous les cas de figure qui entrent en jeu. Du temps du 486 (il y a 25 ans tout de même), l'exemple-type était le « DEC ECX ; JNZ etiquette » qui était plus rapide que l'instruction dédiée « LOOP etiquette » pourtant faite pour ça. Aujourd'hui, outre ces cas particuliers, il faut gérer proprement la ligne de cache, se souvenir de son état et éviter autant que faire se peut de briser le pipeline.

Si on arrive à maintenir manuellement à jour l'état de tous ces mécanismes, il faut ensuite faire des optimisations sur son propre programme, notamment en identifiant les ressources déclarées mais jamais utilisées, par exemple, et voir si certains points purement algorithmiques peuvent être simplifiés également, comme les boucles.

Je n'ai pas été clair : sans optimisation de mes fonctions, je vais PLUS VITE que GCC, jusqu'à (typo) 400 %.

500 % de différence sur une racine carrée, par contre, ça commence à faire beaucoup. Le goulet d'étranglement doit provenir de l'algorithme lui-même, que tu utilises pour extraire cette racine. Il doit probablement y avoir plus efficace.

C'est gcc donc, qui a un problème d'algorithme.

Typoli, je suis désolé, je ne comprends pas ton message.

[Invité]

https://software.intel.com/en-us/c-compilers

En gros ce compilateur est plus performant que gcc, je l'ai intégrée a visual studio pour plus de facilité.

Et ce que j'ai dit, cest juste que j'ai fait deux code source asm et C, produisant deux meme programme.

Avant je compilé mon C code avec gcc, et l'autre avec nasm, et je dépassais largement gcc, plus tard j'ai choisis icl (intel compiler) et ce n'était plus le cas (200% performance en+).

Puis j'ai décidé d'analysé l'asm file produit, pour voir en quoi le code d'icl va plus vite, en vain, donc j'ai reproduit dans l'intégralité le code asm produit par icl en nasm version pour l'assemblée, et là surprise; j'ai eu les memes performances qu'avec mon code asm d'origine.

Après j'ai vu qu'il fallait que je décoche l'option /Qipo, pour pouvoir produire un code asm dans icl, cette option active enfaite toutes les optimisations du compilateur pour le C code. Et de plus si on l'enlève, le programme compilé sous icl crash dés l'entrée.

Donc j'en suis venus à la conclusion que si on ne peut pas voir les optimisations faites par icl (/Qipo active), intel ne veut pas qu'on "pirate" ses idées

[Chevalier au taureau]

Il serait payant, apparemment. Et je ne suis pas certain qu'il optimise sur AMD, parce que je suis sur AMD, sous Linux de surcroît donc sans Visual Studio. Et en désassemblant le code fini, on ne retombe pas sur le code ASM ?

[Invité]

Mais il me semble qu'il gère aussi sur AMD, tu peut toujours essayer.
Tu veut dire si il produit un code source asm AMD ? bah surement si il arrive a compiler sur AMD

Fausse alerte, il n'est pas gratuit meme sous linux ^^, mais sinon tu as une platfome linux trial: https://software.intel.com/en-us/int...llel-studio-xe

Quant tu parle de calculs vectorielle ? tu parle d'AVX ?

[Chevalier au taureau]

Non, SSE. Je n'ai pas la chance d'avoir un proc AVX.

Et je voulais dire qu'on peut normalement retrouver le code ASM à partir du code objet.

[Invité]

Si tu as un désassembleur qui va avec oui, et pour la question des calculs vectoriel dans les languages de haut niveaux.

C'est la panic , trop d'option à cocher (opti du compilateur), changement de la façon de structurer le code (fonction instrinsincs (https://software.intel.com/sites/lan...trinsicsGuide/) et union a gogo*).
Franchement c'est dix fois plus simple de vectoriser/paralleliser des calculs en asm.

*

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
typedef union xmm
{
	float	vec[4];
	__m128	xmm;
}vector128;
vector128	var_1;
vector128	var_2;
vector128	var_3;
 
var_1.xmm = _mm_mul_ps(var_2.xmm, var_3.xmm);

équivalent à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
mulps      xmm1, xmm2, xmm3

Il est préférable d'utiliser des fonctions intrinsics (doit exister sous amd) que directement de l'asm in line, pour la seul raison que la fonctions intrinsics peut choisir un registre 128 bit sans conflit avec le meme registre si il a était utilisé auparavant.
Alors qu'avec des asm inline, tu n'a aucune idée si le registre que tu utilise pour ta fonctions SIMD a déjà était utilisé.

[Chevalier au taureau]

D'accord, mais alors, pourquoi n'a-t-on pas ce genre de fonctions dispos dans les libs standard ? Je ne les ai jamais vues.

[Invité]

Tout simplement car personne, je dit bien personnes des developeurs des language de haut niveaux ne s'est intéréssé à ce genre de technologie du CPU datant de ... 1999 (http://fr.wikipedia.org/wiki/Streaming_SIMD_Extensions).

Apparement jugée trop complexe pour pouvoir le gérée, et ce n'est que maintenant, que ça commence à sortir le bout de son nez

Et pourtant les ingénieur d'intel ne se sont pas arretés: https://software.intel.com/fr-fr/intel-isa-extensions a innover (AVX-512) malgré ce dénigrement de cette technologie

Et je te parie, que les nouvelles techno telle: MPX-SGX-SHA, ne seront utilisé que 16 ans plus tard, donc en 2031 (j'aime troller, c'est fou)

Donc meme si icl me bat à plat de couture meme si je vectorise a fond les calcules, je m'en contre fiche, je garde espoir, car cette technologie est non seulement ingénieuse dans sa façon d'éxécuté son code, mais le code source devient plus compacte, petit et donc lisible.

[Chevalier au taureau]

D'accord.
C'est délirant, dire que je suis dans le calcul scientifique.
Si je fais de telle fonctions, ça intéresserait du monde ?

[Invité]

C'est à dire telle fonctions ?
Des fonctions de calculs ?

Personnellement, j'essaye de dévellopé un 3Dengine voxel entierement sur CPU, je ne fait appel au GPU que pour afficher mon screen final.

Quant je parle de voxel, je parle de vraie voxel, c'est a dire au niveaux pixel et non au niveaux de bloc de pixel

[Chevalier au taureau]

Oui. Comme celle qui est présentée ici. J'ai sous la main 1/sqrt(), sqrt(), inc() pour des vecteurs de double. Je vais essayer de m'amuser avec les trigonométriques.

[Invité]

Honnetement je vais te dire quelque chose qui à mon sens est scandaleusement vraie, les étrangers sont plus apte a faire de l'assembleur que nous

Va sur https://software.intel.com/en-us et sur http://forum.nasm.us/index.php pour trouver du monde qui peut s'intéréssé à de telles choses, bon meme si il y a quelque personnes ici aiment l'asm, c'est peanuts comparé à la communauté au usa

[bifur]

je ne sais pas ce que ça vaut en terme de rapidité mais j'avait réaliser une petite calculette en ligne de commande qui utillisai des nombre sous forme fractionnaire (2x32bit) plutôt que des nomres a virgules flottante

est ce que quelqu'un a déja vu un systeme de calcul semblable?
je ne pense pas que ce soit très utillisé car si les multiplications & divisons sont assez simple a faire, les additions & soustraction sont plutot complexe (si e/f=a/b+c/d alors e=a*d+c*b et f=b*d)

[Chevalier au taureau]

Oui, on voit passer ce genre de choses. Ca n'atteint pas le range des double pour la représentation des grands nombres. Et les instructions ne sont pas codées en dur, c'est donc assez mauvais en terme de rapidité.

[Chevalier au taureau]

J'ai donc avancé. Le code, la réflexion et les résultats sont disponibles ici : http://www.les-sauvages.fr/Assembleur/Assembleur18.html.
Je suis preneur de toute remarque, anecdote ou histoire drôle.