Les microbenchmark ne veulent pas dire grand chose.
J'avais fait une étude de pire cas pour un code pour avion. Quand on fait un microbenchmark (temps d’exécution d'une fonction, au lieu du soft entier), il peut y avoir une différence d'un ordre de grandeur entre un cache 'chaud' et un cache 'froid'. Le cache est vraiment chaud à partir de 3 itérations du même code (cela se voit si on trace une courbe de temps vs numéro d'itération), un cache froid est obtenu en manipulant une grande quantité de donné qui n'a rien à voir avec le 1er code (il faudrait aussi tenir compte d'une grande quantité de code pour les miss du cache instructions).
La réalité est située entre ces 2 extrêmes. L'optimisation proposée ici, peut consommer tellement de mémoire que le taux de miss peut monter en flèche, et détruire tout intérêt pour la méthode.
Vu les vitesses des CPU par rapport au bus mémoire, dans le cas multithread, il faut faire en sorte que chaque cpu ne touche qu'à ses seuls données. Linux 2.4 avait du mal à passer à 4 cpu, Linux 2.6 peut monter à 256 cpu et plus, surtout car chaque processeur dispose de ces données en privés.
# attention au microbenchmark
Posté par Nicolas Boulay (site web personnel) . En réponse au journal OpenJDK 8, JEP 142 & False Sharing. Évalué à 5.
Les microbenchmark ne veulent pas dire grand chose.
J'avais fait une étude de pire cas pour un code pour avion. Quand on fait un microbenchmark (temps d’exécution d'une fonction, au lieu du soft entier), il peut y avoir une différence d'un ordre de grandeur entre un cache 'chaud' et un cache 'froid'. Le cache est vraiment chaud à partir de 3 itérations du même code (cela se voit si on trace une courbe de temps vs numéro d'itération), un cache froid est obtenu en manipulant une grande quantité de donné qui n'a rien à voir avec le 1er code (il faudrait aussi tenir compte d'une grande quantité de code pour les miss du cache instructions).
La réalité est située entre ces 2 extrêmes. L'optimisation proposée ici, peut consommer tellement de mémoire que le taux de miss peut monter en flèche, et détruire tout intérêt pour la méthode.
Vu les vitesses des CPU par rapport au bus mémoire, dans le cas multithread, il faut faire en sorte que chaque cpu ne touche qu'à ses seuls données. Linux 2.4 avait du mal à passer à 4 cpu, Linux 2.6 peut monter à 256 cpu et plus, surtout car chaque processeur dispose de ces données en privés.
"La première sécurité est la liberté"