J'ai posté le journal au cas où quelqu'un aurait eu une réponse indépendante de l'implémentation exacte du code, par exemple « les instructions atomiques indiquent au processeur ce que tu veux faire, et donc il ne se trompe pas dans ses prédictions ». D'ailleurs, ce genre de truc serait bien possible, car Intel cite dans sa documentation sur PAUSE, une instruction qui ne fait rien :
Improves the performance of spin-wait loops. When executing a “spin-wait loop,” processors will suffer a severe performance penalty when exiting the loop because it detects a possible memory order violation. The PAUSE
instruction provides a hint to the processor that the code sequence is a spin-wait loop. The processor uses this hint to avoid the memory order violation in most situations, which greatly improves processor performance. For this
reason, it is recommended that a PAUSE instruction be placed in all spin-wait loops.
L'emphase est de moi. Certaines instructions qui semblent donc ralentir le code peuvent l'accélérer.
Maintenant, je me rend bien compte que le problème peut être beaucoup plus proche de mon code que ce que je pensais (le but du journal était grosso-modo de dire « un machin qui prenait 3 ms en prend maintenant 1,6 alors que j'ai ajouté des instructions atomiques »). D'ailleurs, en corrigeant un bug, j'ai modifié une ligne de code qui n'est jamais exécutée par mon benchmark (ni dans la partie écriture, ni dans la lecture), et il a accéléré.
Si ça se trouve, c'est donc simplement une histoire d'alignement de code, qui entre peut-être en conflit de ligne de cache avec mes données. Si mon benchmark passe son temps à accéder à un certain endroit de la base de donnée, en vidant la ligne de cache qui contenait justement les instructions pour effectuer cet accès, alors il est lent. Peut-être qu'ajouter ces instructions a simplement décalé une partie de code ou un accès au donnée, et le conflit n'a plus lieu.
En tous cas, ce serait chouette que ce genre de phénomène soit documenté pour qu'un compilateur puisse choisir où il place ses fonctions pour qu'elles ne soient pas évincées du cache.
[^] # Re: y'a trop peu d'infos pour t'aider.
Posté par steckdenis . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
J'ai posté le journal au cas où quelqu'un aurait eu une réponse indépendante de l'implémentation exacte du code, par exemple « les instructions atomiques indiquent au processeur ce que tu veux faire, et donc il ne se trompe pas dans ses prédictions ». D'ailleurs, ce genre de truc serait bien possible, car Intel cite dans sa documentation sur PAUSE, une instruction qui ne fait rien :
L'emphase est de moi. Certaines instructions qui semblent donc ralentir le code peuvent l'accélérer.
Maintenant, je me rend bien compte que le problème peut être beaucoup plus proche de mon code que ce que je pensais (le but du journal était grosso-modo de dire « un machin qui prenait 3 ms en prend maintenant 1,6 alors que j'ai ajouté des instructions atomiques »). D'ailleurs, en corrigeant un bug, j'ai modifié une ligne de code qui n'est jamais exécutée par mon benchmark (ni dans la partie écriture, ni dans la lecture), et il a accéléré.
Si ça se trouve, c'est donc simplement une histoire d'alignement de code, qui entre peut-être en conflit de ligne de cache avec mes données. Si mon benchmark passe son temps à accéder à un certain endroit de la base de donnée, en vidant la ligne de cache qui contenait justement les instructions pour effectuer cet accès, alors il est lent. Peut-être qu'ajouter ces instructions a simplement décalé une partie de code ou un accès au donnée, et le conflit n'a plus lieu.
En tous cas, ce serait chouette que ce genre de phénomène soit documenté pour qu'un compilateur puisse choisir où il place ses fonctions pour qu'elles ne soient pas évincées du cache.