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

[Christophe]

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é.