Jouons un peu avec le cache et l'architecture des processeurs

Jouons un peu avec le cache et l'architecture des processeurs

Bonjour tous.

Comme j'ai vu que dans le topic "Performances" on commenait aller titiller de la seconde et de la milliseconde j'ouvre ce topic pour que l'on puisse partager nos expriences avec le cache et l'architecture des processeurs. Je ne sais pas si cela aura beaucoup de succs, mais pour moi un tel concours est l'occasion rve pour partager nos "techniques" d'optimisation/astuces/observations au niveau de la bonne utilisation de l'architecture des processeurs lors de la conception mme des programmes : comment maximiser les performances des boucles, comment utiliser au mieux l'inlining, les templates, les classes, la librairie standard ... et le cache des processeurs ? Bref, benchmarkons ensemble...

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Pour ouvrir le topic, voici un premier lment de rflexion :

1) Profiter du cache
Pour ceux qui s'intressent un peu l'architecture des processeurs, il y
a un premier truc sur lequel on peut jouer pour maximiser les perfs :
tirer parti des temps d'accs des diffrents cache processeur. Les
processeurs qui nous intressent ici sont des "Intel Xeon CPU
X7560 @ 2.27GHz (= 64 Hyperthread)". Si l'on va un peu chercher dans
la doc, on peut voir cela :
- cache L1 : 32KB/core (Instructions) et 16KB/core (Data) : Latence = 4 cycles
- cache L2 : 256KB/core : Latence = 12 cycles
- cache L3 : 24MB partags sur tous les cores : Latence = 26-31 cycles

La premire chose de base savoir c'est que le temps d'accs au cache est des centaines de fois plus faible que le temps d'accs la mmoire vive (qui est lui-mme des milliers de fois plus faible que le temps d'accs au disque dur). Du coup, il faut en profiter. Le meilleur moyen d'en profiter serait de coder en assembleur pour optimiser l'utilisation du cache L1 et L2 dans les zones du programmes trs consommatrices en temps de calcul. Mais ce n'est pas vraiment pratique. Du coup on fait confiance au compilateur ... mais ce genre de techniques d'optimisation ne fait pas toujours parti de ses prrogatives.

Dans la pratique, c'est cause du cache que des compilations en -Os (optimisation pour la taille) tournent parfois plus vite que des compilations en -O2 (optimisation pour la vitesse). En effet, si grce au -Os on conomise de prcieuses instructions en assembleur et que l'on parvient faire rentrer "une partie entire" en cache, alors cela va s'excuter beaucoup plus vite...

En consquence, il existe des astuces et des styles de programmation permettant de profiter cela. Mais tonnamment, la bibliographie sur le sujet est assez faible. Ici : http://www.research.scea.com/research/pdfs/GDC2003_Memory_Optimization_18Mar03.pdf, un exemple qui a quelques annes maintenant.

Mes connaissances sur le sujet s'arrtent peu prs l. Aussi si un ingnieur de chez Intel passe par l et a des documents/ressources permettant de mieux comprendre comment fonctionne concrtement le cache face aux instructions en assembleur, je suis preneur...

Pour exploiter le cache, je m'astreint 2 rgles que je considre tombant sous le sens :
- Les donnes de la tache excute par le Thread < taille du L1, si pas possible infrieur au L2
- Les donnes ne doivent pas tre des pointeurs partags avec d'autres Threads

Aprs pour le C, il existe le mot clef register qui permet de spcifier qu'une variable est suceptible d'etre utilis souvent donc mise en cache. Cependant les compilateurs d'aujourd'hui sont bien plus mme d'optimiser la rpartition des variables. Ca peut se dduire facilement partir d'analyse statique du code.

A moins de connaitre parfaitement la conversion du code C en assembleur, donc le fonctionnement interne de son compilateur, je ne crois pas ce genre d'optimisation. Notre cerveau est limit dans le nombre de variables qu'il peut considrer sur un problme (autour de 5).

Si il y'a des ressources ce sujet je suis preneur galement.

Pour le coup, rien ne t'empche de partager des donnes entre tes diffrents threads. Je le fais souvent tant que c'est dans une section ou je ne fais que des lectures sur les donnes partages. Ce sont les critures qui vont marquer ton cache comme tant invalide. Aprs le problme c'est ne pas faire d'critures dans la mme ligne de cache que tes donnes partages pour viter le "false sharing".

Leave a Comment

Please sign in to add a comment. Not a member? Join today