Discussion :

[vayel]

La documentation du AMD Bulldozer mentionne 3 cycles d'horloge pour les instructions shl, shr, sar. Mais sur le Ryzen, ces instructions peuvent etre utilisé dans le pairing. Est-ce que ca veut dire que sur les Ryzen ces instructions ne prennent de base qu'un cycle ? et si oui, est-ce seulement les Ryzen ?

Autre question. En considerant les codes :

Code :

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

1
2
3
 
  mov ax, [ebx]
  mov dx, [ebx+2]

et

Code :

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

1
2
3
4
 
  mov edx,  [ebx]
  mov ax, dx
  shr edx, 16

La deuxième version prends vraissemblablement plus de cycles d'horloge, mais elle ne contient qu'un seul accès à la mémoire. Laquelle des deux versions est la plus rapide ? Est-ce que cette rapidité est liée au caching ?

[Kannagi]

Les processeurs actuel (et surtout ceux dites "Out of Order" ) sont très difficile à prédire au cycle près !

Effectivement quand tu lit une nouvelle adresse il y'a un cache miss , et le CPU va charger dans la mémoire cache une partie de la RAM (la taille d'une ligne de cache).
Et donc la lecture de cette adresse et des suivantes sont plus rapides.
(Pour cela que la première version est plus rapide).

Pour les instructions qu'ils fasse 3-5 cycles ou plus , na pas d'importance si il y'a peu de dépendance entre elle , les processeurs actuelle sont pipeliné donc pendant que ton shr s’exécute il bloque le cpu que pendant 1 cycle , sauf si bien sur on tombe sur une pipeline stall (et fera donc les 3 cycles) , de même que les processeurs actuelles sont superscalaire donc qui peuve exécuter 2 voir plus d'instructions en même temps.
Ce que signifie sûrement ton 'pairing' , c'est que 2 instructions peuvent s’exécuter simultanément (mais les chances d'avoir un pipeline stall augmente aussi ) ,mais pas toutes les instructions peuvent être superscalaire (c'est par exemple fort rare de voir 2 mul s’exécuter en même temps).
Et donc pour répondre a tes premières questions tout les processeurs (actuel) sont pipeliné et superscalaires oui.

Je que j'ai dit est bien sur complètement invisible pour le programmeur , qui programme son bon X86 comme dans les années 80 ! (compatibilité oblige ).
Mais savoir ce que fait exactement ton CPU en interne est difficile et donc connaître le cycle prés me semble assez illusoire avec ce type de processeur néanmoins tu devrait donc lire ceci : https://fr.wikipedia.org/wiki/Ex%C3%..._d%C3%A9sordre et https://fr.wikipedia.org/wiki/Renommage_de_registres

Certain type de processeur In Order , comme le processeur CELL de la PS3 , ne possède nullement tout ceci et c'est a la charge du programmeur d'organiser manuellement la pipeline donc réorganiser les registres et les instructions pour éviter tout pipeline stall , il existait même des mémoires cache 'manuelle' quand nomme scratchpad memory (ce qui permet d'éviter tout les soucis du cache miss si bien utilisé).

[Invité]

En complément de ce qu'expose Kannagi, j'ai pris l'habitude, en pareil cas, de pratiquer un test avec l'instruction RDTSC (ReaD Time-Stamp Counter) qui lit ponctuellement l'état de l'horloge et le mémorise dans la paire de registres EDX:EAX. On la met une première fois avant la séquence à tester puis après et on fait la différence. Je me souviens de l'avoir utilisé une fois et ça a marché ! Et quelquefois, j'ai été très surpris par les résultats car il variaient en fonction du contexte selon lequel la séquence était exécutée.
Evidemment, tout ceci suppose que ladite instruction a été implémentée dans le Ryzen...
Si je trouve le temps, je fais un petit test.

[Invité]

Voici un programme qui teste les 2 séquences et le résultat que j'obtiens avec un processeur Intel i7 3770 cadencé à 3,4 GHz :


Quelques remarques
1) Je ne teste que les 32 bits inférieurs du compteur EDX:EAX, ce qui explique que j'obtienne parfois des résultats délirants (notamment si le compteur est sur le point de faire un tour complet)
2) Il faut lancer le test plusieurs fois pour obtenir des valeurs stables ce qui confirme bien la thèse selon laquelle les résultats dépendent du contexte du moment.

Je serais intéressé par des résultats obtenus sur des processeurs plus performants.
Voici le listing :

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
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
;================================================================
;                   CyclesHorloge.asm
;    Programme de comptage de durée d'exécution
;----------------------------------------------------------------
.386
.model flat,stdcall
option casemap:none
include \masm32\include\windows.inc
include \masm32\include\user32.inc
include \masm32\include\kernel32.inc
includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib
 
.data
MsgBoxCaption	db "Nombre de cycles d'horloge",0
 
MemoTime1		dd 0
MemoTime2		dd 0
 
Sequence1		db 'La Séquence1 :',9,'mov ax,[ebx]',13,10,9,9,'mov dx,[ebx+2]',13,10,'nécessite ',0
 
CyclesH			db " cycles",0
 
 
Sequence2		db 13,10,13,10,'La Séquence2 :',9,'mov edx,[ebx]',13,10,9,9,'mov ax,dx',13,10,9,9,'shr edx,16',13,10,'nécessite ',0
BufferAscii		db 512 dup(?)
 
.code
Start:
;==== Test Séquence 1
db 0Fh, 31h	; instruction RDTSC (n'existe pas sur cette version de MASM)
mov esi,eax	; mémo partie basse du compteur
;---- Séquence 1 répétée 8 fois
mov  ax,[ebx]		; 1
mov  dx,[ebx+2]
mov  ax,[ebx]		; 2
mov  dx,[ebx+2]
mov  ax,[ebx]		; 3
mov  dx,[ebx+2]
mov  ax,[ebx]		; 4
mov  dx,[ebx+2]
mov  ax,[ebx]		; 5
mov  dx,[ebx+2]
mov  ax,[ebx]		; 6
mov  dx,[ebx+2]
mov  ax,[ebx]		; 7
mov  dx,[ebx+2]
mov  ax,[ebx]		; 8
mov  dx,[ebx+2]
 
db 0Fh, 31h	; instruction RDTSC
sub  eax,esi
shr  eax,3			; équivaut à une division par 8
mov  MemoTime1,eax
 
;==== Test Séquence 2
db 0Fh, 31h	; instruction RDTSC (n'existe pas sur cette version de MASM)
mov esi,eax	; mémo partie basse du compteur
;---- Séquence 2 répétée 8 fois
mov  edx,[ebx]		; 1
mov  ax,dx
shr  edx,16
mov  edx,[ebx]		; 2
mov  ax,dx
shr  edx,16
mov  edx,[ebx]		; 3
mov  ax,dx
shr  edx,16
mov  edx,[ebx]		; 4
mov  ax,dx
shr  edx,16
mov  edx,[ebx]		; 5
mov  ax,dx
shr  edx,16
mov  edx,[ebx]		; 6
mov  ax,dx
shr  edx,16
mov  edx,[ebx]		; 7
mov  ax,dx
shr  edx,16
mov  edx,[ebx]		; 8
mov  ax,dx
shr  edx,16
 
db 0Fh, 31h	; instruction RDTSC
sub  eax,esi
shr  eax,3			; équivaut à une division par 8
mov  MemoTime2,eax
 
mov  esi,offset Sequence1
mov  edi,offset BufferAscii
call CopyChaine
 
mov  eax,MemoTime1
call ConvertAscii
 
mov  esi,offset CyclesH
call CopyChaine
 
mov  esi,offset Sequence2
call CopyChaine
 
mov  eax,MemoTime2
call ConvertAscii
 
mov  esi,offset CyclesH
call CopyChaine
 
xor  al,al		; un zéro pour terminer la chaîne
stosb
 
 
 
;------------ Boîte de message d'affichage de la séquence 1 -------------
invoke MessageBoxA, NULL, addr BufferAscii, addr MsgBoxCaption, MB_OK
 
 
 
;------------ Boîte de message d'affichage puis sortie -------------
;invoke MessageBoxA, NULL, addr BufferAscii, addr MsgBoxCaption, MB_OK
invoke ExitProcess, NULL
 
;================================================================================
;        Conversion valeur binaire format Word en chaîne ASCII dans le Buffer
;--------------------------------------------------------------------------------
; A l'entrée : 	EAX contient la valeur binaire à transformer en chaîne ASCII
;				EDI pointe le buffer recevant la chaîne ASII
ConvertAscii:
push ebx
push ecx
push edx
mov  ebx,10
xor  ecx,ecx
 
;--- Divisions par 10 successives pour obtenir un résultat affichable
BcleAscii:
xor  edx,edx ; edx = 0 (car c'est la partie haute du dividende)
div  ebx		; division par 10 de EDX:EAX
push edx		; on stocke le reste en pile
inc  ecx		; on compte le nombre d'empilages
or eax,eax		; si le quotient est nul, on arrête
jnz  BcleAscii
 
;--- Restitution de la pile dans le buffer
BcleBuffer:
pop  eax
add  al,30h	; conversion en ASCII
stosb
loop BcleBuffer
 
pop  edx
pop  ecx
pop  ebx
ret
;================================================================================
;               Copie d'une chaîne ASCIIZ
;--------------------------------------------------------------------------------
; A l'entrée : 	ESI pointe la chaîne à copier
;				EDI pointe l'emplacement accueillant la chaîne à copier
; NE COPIE PAS LE ZERO DE FIN !!!!
CopyChaine:
lodsb
or   al,al	; fin de chaîne à copier ?
jz   FinChaine
stosb
jmp CopyChaine
FinChaine:
ret
 
end Start

Très bonne soirée !!!

[Kannagi]

2) Il faut lancer le test plusieurs fois pour obtenir des valeurs stables ce qui confirme bien la thèse selon laquelle les résultats dépendent du contexte du moment.

J'ai fait un long paragraphe qui explique justement pourquoi (l'impossibilité de connaître l'état de la pipeline) et forcément cette pipeline change selon le contexte , de plus ça dépend de la mémoire cache si on veut tester toujours avec un cache miss alors il faut penser a faire un clflush !

Je serais intéressé par des résultats obtenus sur des processeurs plus performants.

Cela confirme au moins un truc que je craignais , les CPU moderne optimise vraiment mal la pipeline (mais bon d'un coté je doute qu'il puisse prédire énormément d'instruction à l'avance), triste on arrivait a faire '1cycle/instruction' au début du millénaire

[chrtophe]

Cela confirme au moins un truc que je craignais , les CPU moderne optimise vraiment mal la pipeline (mais bon d'un coté je doute qu'il puisse prédire énormément d'instruction à l'avance), triste on arrivait a faire '1cycle/instructino' au début du millénaire

Peut-être aussi du aux types d'instructions utilisées. Je suis pas sûr que mixer l'utilisation de registres 16 bits et 32 bits soit optimum. Mais ce n'est qu'une présomption. Je n'ai pas testé.

[Invité]

Dans les séquences décrites précédemment, j'ai changé arbitrairement tous les registres 16 bits en 32 bits et là, le résultat est net :

La durée d'exécution est quasiment divisée par 2 ! Quoique... une plus forte dispersion des résultats est observée dans le cas du "tout 32 bits"
Attention donc aux risques de généralisation.

Kannagi, pourrais-tu m'expliquer comment coder l'instruction clflush ? La doc Intel fait apparaître un opérande dont je n'arrive pas à voir à quoi il correspond.
Le fonctionnement interne des process d'optimisation des processeurs modernes m'est totalement étranger. Le peu que j'ai vu jusqu'à présent me fait douter de l'intérêt que j'ai eu à m'offrir un i7 alors qu'un i5 eût été largement satisfaisant (je voulais absolument disposer des instructions de cryptographie AES-NI qui sont également implémentées sur le i5). Les fabricants de processeurs, c'est finalement un peu comme les vendeurs de bagnoles : on te fait miroiter des consos de rêve très en-dessous de la réalité !

Ci-dessous, la dernière version du source :

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
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
;================================================================
;                   CyclesHorloge2.asm
; Programme de comptage de durée d'exécution (registres 32 bits)
;----------------------------------------------------------------
.386
.model flat,stdcall
option casemap:none
include \masm32\include\windows.inc
include \masm32\include\user32.inc
include \masm32\include\kernel32.inc
includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib
 
.data
MsgBoxCaption	db "Nombre de cycles d'horloge",0
 
MemoTime1		dd 0
MemoTime2		dd 0
 
Sequence1		db 'La Séquence1 :',9,'mov eax,[ebx]',13,10,9,9,'mov edx,[ebx+2]',13,10,'nécessite ',0
 
CyclesH			db " cycles",0
 
 
Sequence2		db 13,10,13,10,'La Séquence2 :',9,'mov edx,[ebx]',13,10,9,9,'mov eax,edx',13,10,9,9,'shr edx,16',13,10,'nécessite ',0
BufferAscii		db 512 dup(?)
 
.code
Start:
;==== Test Séquence 1
db 0Fh, 31h	; instruction RDTSC (n'existe pas sur cette version de MASM)
mov esi,eax	; mémo partie basse du compteur
;---- Séquence 1 répétée 8 fois
mov  eax,[ebx]		; 1
mov  edx,[ebx+2]
mov  eax,[ebx]		; 2
mov  edx,[ebx+2]
mov  eax,[ebx]		; 3
mov  edx,[ebx+2]
mov  eax,[ebx]		; 4
mov  edx,[ebx+2]
mov  eax,[ebx]		; 5
mov  edx,[ebx+2]
mov  eax,[ebx]		; 6
mov  edx,[ebx+2]
mov  eax,[ebx]		; 7
mov  edx,[ebx+2]
mov  eax,[ebx]		; 8
mov  edx,[ebx+2]
 
db 0Fh, 31h	; instruction RDTSC
sub  eax,esi
shr  eax,3			; équivaut à une division par 8
mov  MemoTime1,eax
 
;==== Test Séquence 2
db 0Fh, 31h	; instruction RDTSC (n'existe pas sur cette version de MASM)
mov esi,eax	; mémo partie basse du compteur
;---- Séquence 2 répétée 8 fois
mov  edx,[ebx]		; 1
mov  eax,edx
shr  edx,16
mov  edx,[ebx]		; 2
mov  eax,edx
shr  edx,16
mov  edx,[ebx]		; 3
mov  eax,edx
shr  edx,16
mov  edx,[ebx]		; 4
mov  eax,edx
shr  edx,16
mov  edx,[ebx]		; 5
mov  eax,edx
shr  edx,16
mov  edx,[ebx]		; 6
mov  eax,edx
shr  edx,16
mov  edx,[ebx]		; 7
mov  eax,edx
shr  edx,16
mov  edx,[ebx]		; 8
mov  eax,edx
shr  edx,16
 
db 0Fh, 31h	; instruction RDTSC
sub  eax,esi
shr  eax,3			; équivaut à une division par 8
mov  MemoTime2,eax
 
mov  esi,offset Sequence1
mov  edi,offset BufferAscii
call CopyChaine
 
mov  eax,MemoTime1
call ConvertAscii
 
mov  esi,offset CyclesH
call CopyChaine
 
mov  esi,offset Sequence2
call CopyChaine
 
mov  eax,MemoTime2
call ConvertAscii
 
mov  esi,offset CyclesH
call CopyChaine
 
xor  al,al		; un zéro pour terminer la chaîne
stosb
 
;------------ Boîte de message d'affichage des résultats -------------
invoke MessageBoxA, NULL, addr BufferAscii, addr MsgBoxCaption, MB_OK
 
;----------------------- Sortie du programme -------------------------
 
invoke ExitProcess, NULL
 
;================================================================================
;        Conversion valeur binaire format Word en chaîne ASCII dans le Buffer
;--------------------------------------------------------------------------------
; A l'entrée : 	EAX contient la valeur binaire à transformer en chaîne ASCII
;				EDI pointe le buffer recevant la chaîne ASII
ConvertAscii:
push ebx
push ecx
push edx
mov  ebx,10
xor  ecx,ecx
 
;--- Divisions par 10 successives pour obtenir un résultat affichable
BcleAscii:
xor  edx,edx ; edx = 0 (car c'est la partie haute du dividende)
div  ebx		; division par 10 de EDX:EAX
push edx		; on stocke le reste en pile
inc  ecx		; on compte le nombre d'empilages
or eax,eax		; si le quotient est nul, on arrête
jnz  BcleAscii
 
;--- Restitution de la pile dans le buffer
BcleBuffer:
pop  eax
add  al,30h	; conversion en ASCII
stosb
loop BcleBuffer
 
pop  edx
pop  ecx
pop  ebx
ret
;================================================================================
;               Copie d'une chaîne ASCIIZ
;--------------------------------------------------------------------------------
; A l'entrée : 	ESI pointe la chaîne à copier
;				EDI pointe l'emplacement accueillant la chaîne à copier
; NE COPIE PAS LE ZERO DE FIN !!!!
CopyChaine:
lodsb
or   al,al	; fin de chaîne à copier ?
jz   FinChaine
stosb
jmp CopyChaine
FinChaine:
ret
 
end Start

[chrtophe]

Donc mon postulat semble fondé.

Il faut penser aussi que les compilateurs pensent optimisation lors de la génération de code, ils n'utiliseront pas forcément les mêmes instructions que nous.

Je pense aussi qu'il doit être parfois plus efficace d'utiliser des codes utilisant plus de cycles mais bien pipelinés.

Le peu que j'ai vu jusqu'à présent me fait douter de l'intérêt que j'ai eu à m'offrir un i7 alors qu'un i5 eût été largement satisfaisant

Je dirais que ça dépend de ce que tu fais.

[Kannagi]

@Asmou
Pour le code : "clflush 0(%eax)" (ça marche avec gcc) , je dirait que en syntaxe intel ça donne ça : "clflush 0(eax)"

Normal que le fonctionnement interne des processeurs t'es étranger , sur un X86 ces fonctionnalités sont effectivement cacher au programmeur (d’où la difficulté d'avoir trouvé les failles meltdown et spectre).
De plus comme je l'avait précédemment dit les processeurs moderne essaye de simuler une exécution comme les anciens processeurs (ça veut dire de manière séquentiel d'un point de vu du code) , ce qui je comprend peut sembler assez théorique comme explication, on est passé du M68000 au x86 et le x86 quand il est venu avec une pipeline et superscalaire , ben on a pas vu la différence (de même que l'ajout de la mémoire cache).
Du coup même pour moi je ne voyais pas tant la différence que ça entre du M68000 et du x86 (appart pour les mnémoniques) et pas de dif entre un x86-16/32 bits avec ou sans pipeline.

Si je tiens tant a le souligner , c'est que c'est une info assez rare même sur ce forum (pourtant ça fait 20 ans que les processeurs sont pipeliné ) , et on parle toujours des instructions processeurs comme s'il faisait un taux fixe en cycle (tel instruction fait 3 cycle , l'autre fait 7 cycle ect ).
Pour être exact une instruction fera entre 1 et x cycles (x étant le nombre de cycle indiqué chez la doc ) et comme le dit chrtophe cela dépend plus de la pipeline une instruction longue mais avec peu de dépendance aura plus de chance d'avoir un taux de cycle faible.
Pour ma part heureusement que mon vagabondage sur les consoles de 5-6 générations m'ont permis de rassembler les puzzles ! (vu que j'avais une incompréhension total avec un CPU moderne x86 et ce que j'observais sur ces anciennes machines).

J’espère que mon petit HS sera utile

[Guesset]

Bonjour,

C'est un sujet intéressant et assez prise de tête. La recherche de performances devient assez rapidement dépendante du CPU cible et c'est une poursuite sans fin. Les livres (disponibles en PDF) d'Agner Fog sont très intéressants sur ces sujets.

Je partage l'avis que laisser le CPU appliquer seul le "out of order" facilite la vie mais n'est pas optimal car le CPU travaille avec une courte vue. Je l'aide avec l’entre-laçage de codes indépendants. Ça marche mais la lecture du code devient assez pénible.

Les optimisations des compilateurs doivent systématiquement être activées mais il ne faut pas croire au père noël. Ils font du bon travail mais, pour diverses raisons (notamment de compatibilité), ils utilisent un jeu restreint de fonctions assembleurs et laissent une large place à l'optimisation manuelle au moins pour quelques % et souvent quelques x*100%.

Bien sûr il ne faut optimiser qu'à bon escient : cela n'a, par exemple, aucun intérêt de faire passer un temps de réponse utilisateur de 1/100s à 1/1000s (sauf si on doit servir quelques milliers d'utilisateurs ).

Le problème des tests est difficile à résoudre (voire impossible). Éviter déjà que le système interrompre notre programme parce qu'il estime avoir quelque chose de plus prioritaire à faire est très délicat (passer en priorité temps réel ?). La technique statistique est assez efficace et finalement représentative de la réalité d'un environnement opérationnel. J'attends cependant quelques temps après le lancement pour activer les tests afin d'éviter d'avoir une surcharge de perturbations imputables aux sauvegardes que lance la plupart des EDI à l'activation du programme (et qui, avec les caches du système d'exploitation, ont un effet retard). Enfin je me méfie des coûts fixes extrinsèques (coûts de boucles, coûts d'appel etc.) notamment pour les fonctions très courtes. Tester une boucle quasi vide n'est pas si simple pour estimer ces coûts fixes car, si les mécanismes d'optimisations du compilateur détecte que c'est une boucle et des affectations pour rire, ils les suppriment et nos résultats deviennent assez vite fantaisistes.

Bref il y a du travail.

Salutations