Discussion :

[Kannagi]

Il y a le HLA un langage assembleur avec POO dont le préprocesseur est doté de #if #while #for #print théoriquement il peut produire n'importe quelle source

Quel rapport avec le C ?

Sinon , le HLA , de mon point de vue n'a aucun interet , y'a pas mal de macro assembleur , mais un ça remplacera jamais un langage haut niveau et secundu le plus important , le compilateur fera mieux que toi.
Optimiser en asm des bout de code que le compilo n'arrive pas : "pourquoi pas" , mais en grande majorité le compilo fera mieux.
Mais surtout optimiser sur du x86 est loin d’être trivial , il faut connaître l'ensemble des instructions et connaître ceux qui peuvent aider ton algo , sans parler des instructions à éviter + sur connaître les zero idiom , les macro op , ,gérer les caches ,aider le parallélisme etc etc , bref tout ça est tout sauf trivial !
Surtout qu'un débutant à une vision très faussé du fonctionnement du processeur , je pense que avant de vouloir optimiser en asm , il faut avoir quand même quelque notion avancé en architecture des ordinateurs.
La doc d'Intel fait a peu près 600 pages pour les conseils d'optimisations ,et cette doc est très technique et demande une grosse connaissance en amont pour en comprendre toute les subtilités.

[Guesset]

Bonjour,

Il y a les bouquins gratuits d'Agner Fog qui traitent très bien les optimisations. Il y en a un pour le C. L'avantage relativement à ceux de Intel ou AMD est, d'une part, l'indépendance relative (par exemple où trouver les incompatibilités entre les deux ?), d'autre part, ils sont (un peu) plus lisibles.

Mais ça reste un sport de combat.

En ce qui me concerne, je laisse le compilateur faire son job pour jouer avec les instructions élémentaires. En revanche, si j'ai besoin de performances et qu'il existe des instructions assembleurs non élémentaires pour y contribuer, je retrousse mes manches et active quelques neurones.

Une instruction en langage évoluée utilise une ou plusieurs instructions assembleur élémentaires tandis qu'une instruction assembleur non élémentaire correspond à plusieurs instructions en langage évolué. A l'origine ces dernières n'existaient pas alors qu'elles sont (trop ?) nombreuses aujourd'hui. Certaines ne font pas des choses très complexes comme rcl par exemple (rotation de bits y compris le bit de retenu). D'autres, comme la multiplication haute des jeux d'instructions SIMD sont assez sophistiquées.

Il en résulte qu'il ne faut jamais passer à l'assembleur pour traduire un code initialement en langage évolué mais qu'on peut repenser ce code directement en assembleur à partir d'un potentiel d'instructions que ne sait évoquer un langage évolué.

Salutations

[Kannagi]

Bonjour,
En ce qui me concerne, je laisse le compilateur faire son job pour jouer avec les instructions élémentaires. En revanche, si j'ai besoin de performances et qu'il existe des instructions assembleurs non élémentaires pour y contribuer, je retrousse mes manches et active quelques neurones.

Une instruction en langage évoluée utilise une ou plusieurs instructions assembleur élémentaires tandis qu'une instruction assembleur non élémentaire correspond à plusieurs instructions en langage évolué. A l'origine ces dernières n'existaient pas alors qu'elles sont (trop ?) nombreuses aujourd'hui. Certaines ne font pas des choses très complexes comme rcl par exemple (rotation de bits y compris le bit de retenu). D'autres, comme la multiplication haute des jeux d'instructions SIMD sont assez sophistiquées.

Justement ,tu as une vision un peu ancienne des compilateurs , GCC est capable d'utiliser les instructions SIMD , donc SSE et AVX compris
Et c'est pas théorique, c'est simple , j'avais fait une multiplication de matrice (à la mano en asm avec les instruction SSE) , le compilo a réussi à faire mieux que moi avec les instructions SSE , mais en plus , avec l'option "avx" il a pu me filer le code AVX optimisé aussi

Bref , certain compilateur sont clairement pas à sous estimé , ils ont une analyse du code assez poussé...

[WhiteCrow]

[...]

Bref , certain compilateur sont clairement pas à sous estimé , ils ont une analyse du code assez poussé...

En effet, par exemple le code :

Code :

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

1
2
3
4
5
6
unsigned sum(unsigned n) {
    unsigned acc=0;
    for(unsigned i=0; i<=n; i++)
        acc += i;
    return acc;
}

donne une fois compilé avec clang 14 (→ godbolt):

Code :

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

1
2
3
4
5
6
7
sum:                                    # @sum
        mov     ecx, edi
        lea     eax, [rdi - 1]
        imul    rax, rcx
        shr     rax
        add     eax, edi
        ret

[Guesset]

Bonjour Kannagi,

Justement, tu as une vision un peu ancienne des compilateurs, GCC est capable d'utiliser les instructions SIMD , donc SSE et AVX compris

Qu'il sache utiliser les instructions SIMD ne veut pas dire qu'il s'en serve pour optimiser. Il faut lui déclarer des structures particulières. Faute de quoi...

Ma vision ancienne, que tu ne connais pas, me permet d'avoir des performances très sensiblement supérieures à ce que peut faire le compilateur quand j'utilise des instructions assembleurs non élémentaires (et bien sûr qu'elle soient appropriées). Les benchmarks resteront toujours plus fiables que des certitudes abstraites.

Un exemple simple, toutes optimisations activées, où on veut trouver à la fois le quotient et le modulo d'un nombre i par j (plus les chiffres sont faibles meilleurs sont les résultats):

• divmod en asm ............................891 005 500
• q = i / j, puis m = i-q*j .................913 347 676 (+ 2,50%)
• q = i/j puis m = i % j ...................1 855 434 088 (+108.24 %)

Un autre tout aussi simple :

• CODE GRAY -> BIN (asm)..............9 799 498 973
• CODE GRAY -> BIN.....................13 453 224 254 (+37,28%)

Il est certes plus facile de ne jamais analyser le code assembleur produit par un compilateur et croire en sa magie. Mais l'étude et l'analyse des codes assembleurs générés par les compilateurs montrent effectivement des choses remarquables et des loupés tout aussi manifestes.

Salut

[Kannagi]

Qu'il sache utiliser les instructions SIMD ne veut pas dire qu'il s'en serve pour optimiser. Il faut lui déclarer des structures particulières. Faute de quoi...

S'il le faisait pas ,je ne l'aurait pas dit, mais un exemple vaux mille mots ?
https://gcc.godbolt.org/z/Tb5jjEY6G

Les benchmarks resteront toujours plus fiables que des certitudes abstraites.

Je ne parle pas d'abstrait ,surtout qu'il est difficile d'évaluer la vitesse d'un code asm , vu que le superscalarie Out or order rend quasiment impossible la prédictions ou le calcul de combien ça peut prendre.

Voilà donc ce que ça donne sur mon mulmatrix :

----------------------------------------------------------------------------------------
Benchmark Time CPU
----------------------------------------------------------------------------------------
BM_Matrix4MultNative: 15.3 ns 15.1 ns
BM_Matrix4MultAsm: 13.9 ns 13.8 ns
BM_Matrix4MultGCC: 5.06 ns 5.21 ns
BM_Matrix4MultGCCAVX: 3.12 ns 3.12 ns

[Guesset]

Bonjour Kannagi,

S'il le faisait pas ,je ne l'aurait pas dit, mais un exemple vaux mille mots ?
https://gcc.godbolt.org/z/Tb5jjEY6G

C'est l'exemple même d'une structure préparée. Non ? Matrices et vecteurs sont les structures recommandées pour les opérations vectorielles des CPU.
En revanche les couleurs se présentent souvent sous forme d'entiers non signés de 32 bits (avec ou sans transparence). Ce sont des vecteurs qui ne disent pas leur nom. Ainsi les encodages donnant par exemple la luminance d'une couleur n'utiliserons jamais les SIMD sauf, et encore, si on fait un travail de présentation vectorielle préalable (ou que l'on se charge du codage en assembleur).

Voilà donc ce que ça donne sur mon mulmatrix :

Je ne sais pas ce que cela représente. Différentes optimisations compilateurs ? D'autres codages de programmeurs ? Si les version "native" et ASM ont d'aussi mauvais résultats c'est qu'elles n'utilisent pas les possibilités SIMD dédiées au calcul vectoriel, elles font une course en sac alors que tout le monde a les dernières chaussures. Et pourquoi la compilation dite native n'est pas optimisée : ciblage machine trop large incluant des vieilles machines ?

@WhiteCrow : c"est vrai que c'est impressionnant. Je me demande cependant pourquoi il n'a pas écrit :

Code :

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

1
2
3
4
5
6
sum:                                    # @sum
        mov     ecx, edi
        lea     eax, [rdi + 1]
        imul    rax, rcx
        shr     rax
        ret

D'un autre côté ce qui est impressionnant aussi, c'est qu'un développeur puisse écrire une boucle pour ce calcul .

Salut

[Kannagi]

C'est l'exemple même d'une structure préparée. Non ? Matrices et vecteurs sont les structures recommandées pour les opérations vectorielles des CPU.
En revanche les couleurs se présentent souvent sous forme d'entiers non signés de 32 bits (avec ou sans transparence). Ce sont des vecteurs qui ne disent pas leur nom. Ainsi les encodages donnant par exemple la luminance d'une couleur n'utiliserons jamais les SIMD sauf, et encore, si on fait un travail de présentation vectorielle préalable (ou que l'on se charge du codage en assembleur).

Alors ici , le compilateur a fourni le meilleur code ASM pour une multiplication de matrice, impossible de faire moins (l'IPC tourne autour de 3/4 ici ).
Je ne sais pas ce que tu appelle structure préparée , oui c, c'est une matrice, mais justement, tu peux avoir des matrices sans que le compilateur optimise en SIMD , je peux te passer du code de mulmatrix, et que le compilateur optimisera pas ( par exemple du code que j'avais vu sur OpenGL pour le mulmatrix , qui du coup le compilo optimisera mal ).
Du coup tu donne l’exemple des couleurs, mais pour la multiplication de matrice , c'est pareil , si tu montre pas que le code C utilise du SIMD , il trouvera pas.

techniquement un code qu'il optimisera pas en SIMD (et pourtant c'est la même chose que en haut )

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
void MatrixMultiplyFPU(float* dest,float* src1,float* src2)
{
	int i;
	float x,y,z,w;
	for(i = 0;i < 16;i+=4)
	{
		x = src2[i+0];
		y = src2[i+1];
		z = src2[i+2];
		w = src2[i+3];
 
		dest[i+0] = (src1[0+0]*x) + (src1[4+0]*y) + (src1[8+0]*z) + (src1[12+0]*w);
		dest[i+1] = (src1[0+1]*x) + (src1[4+1]*y) + (src1[8+1]*z) + (src1[12+1]*w);
		dest[i+2] = (src1[0+2]*x) + (src1[4+2]*y) + (src1[8+2]*z) + (src1[12+2]*w);
		dest[i+3] = (src1[0+3]*x) + (src1[4+3]*y) + (src1[8+3]*z) + (src1[12+3]*w);
	}
}

Bref juste pour dire qu'on doit écrire du code C optimiser , mais pour ça il faut aider le compilateur , pour qu'il comprend qu'on a affaire à du SIMD.

Je ne sais pas ce que cela représente. Différentes optimisations compilateurs ? D'autres codages de programmeurs ? Si les version "native" et ASM ont d'aussi mauvais résultats c'est qu'elles n'utilisent pas les possibilités SIMD dédiées au calcul vectoriel, elles font une course en sac alors que tout le monde a les dernières chaussures. Et pourquoi la compilation dite native n'est pas optimisée : ciblage machine trop large incluant des vieilles machines ?

Cela représente d'autre codage.
La version ASM utilise bel et bien les instruction SIMD (ce n'est pas moi qui l'ai écrite par contre ) , mais elel fait justem oins bien que le compilo.
j'en avais aussi écrite une , mais qui au final était presque aussi proche que la version compilo (mais legerement moins bonne).

La version native, c'est juste si tu fait une multiplication de matrice naïve en C ou C++.

Pour la conclusion , c'est juste pour dire que le compilo fait du bon boulot, on trouvera de toute façon des instruction sur le x86 un peu "alambique" qui s'utilisera que en asm.
Mais bon , l'optimisation du x86 ne se résume pas seulement à utiliser les bonnes instructions, il y'a plein d'autre chose à prendre en compte.