:nono-4636:
:nono-4636:
Hum... pas tout à fait. En fait pour moi c'est une histoire de cache CPU, et en particulier du cache d'instruction (Level 1 si j ne me plante pas). Hyuux! utilise le paradoxe de la dichotomie de Zénon, qui n'est qu'une simple suite géométrique. Au niveau programmation, une suite géométrique n'est qu'une boucle courte d'instructions. Ici, c'est cette boucle qui est utilisée :
Code:
[C++]
long double pival(0);
for(int n = 0; n < 1e7; n++){
pival += (1e50 / (1 * pow(2,n+1)));
}Ce genre de boucle tient intégralement dans le cache CPU. C'est à dire que la valeur initiale de mon pival (0) va être tirée de la RAM puis stockée dans le cache CPU, comme toute donnée. Mais comme la boucle utilisée tient intégralement dans le cache CPU, l'ordinateur ne va pas à chaque tour écrire la nouvelle valeur dans la RAM puis la relire :nono-4636: Il va l'écrire et la relire dans son cache. Ce n'est qu'à la fin de la boucle que le résultat final sera remis dans la RAM.
Dans un programme monothread comme SPI, cela n'aurait aucune espèce d'importance puisqu'il faut attendre la fin d'une boucle pour en entamer une autre. La différence entre Hyuux! et SPI est principalement due au fait que Hyuux! est multithread. A chaque passe (test), 20 threads sont créés et chacun calcule la boucle ci-dessus. Au début un thread est attribué à chaque cœur, puis s'il reste encore des threads (ce qui est le cas, nous n'avons pas 20 cœurs sur nos CPU), ils sont soit assignés à des cœurs si la taille du cache d'instruction le permet, soit mis en attente que ce cache se libère pour s'y mettre.
Et c'est là qu'est la différence entre ton processeur et celui des autres hexacores Intel que j'ai vu jusqu'à présent : tu as deux fois plus de cache d'instruction qu'eux. Le cœur peut donc traiter deux fois plus de threads en même temps, ce qui se traduit par un temps d'exécution du bench a peu près deux fois moins long.
Dernière édition:
, 