RE : RE : RE : [SOS] phénomène étrange dans mon scheduler tous simple...

[Romain LABBE]

Salut Daniel,

Parfaite cette explication, tres simple tres clair.
Je vois un peu mieux ou situer ces caches dans la pyramide.

Est-ce que tu aurais un ordre de grandeur du nombre de threads (si
simple) qu'il est possible de faire tourner sur un OS standard ou sur
SOS ?

Merci pour ces explications.

Romain

> -----Message d'origine-----
> De : sos-bounces at the-doors.enix.org 
> [mailto:sos-bounces at the-doors.enix.org] De la part de Daniel Lezcano
> Envoyé : mardi 22 novembre 2005 11:34
> À : SOS mailing-list
> Objet : Re: RE : RE : [SOS] phénomène étrange dans mon 
> scheduler tous simple...
> 
> 
> Romain LABBE wrote:
> 
> >Salutc Daniel,
> >
> >1000 Merci our ta reponce...
> >
> >Je ne sais pas vraiement ce que c'est ce probléme de cache, 
> Apparament 
> >ce serait ce que David m'expliquait juste avant... Ca ca à pas l'air 
> >facile à debbuger....arf...
> >  
> >
> Le processeur accede aux informations de la memoire en essayant 
> successivement de trouver l'information dans differents 
> "etages" de memoires. Tu trouves 2 etages avant la memoire, appeles 
> "cache" de premier et de second niveau.
> Le cache de premier niveau est integre au processeur, c'est ce qu'on 
> appelle le "L1 cache". En general, la taille varie selon les 
> processeur de 128Ko a 512Ko, c'est notamment l'une des 
> differences entre 
> les P4 et les Celerons.
> Le cache de second niveau est integre a la carte mere, c'est ce qu'on 
> appelle le "L2 cache". La taille varie de 2Mo a 8 Mo voire
> 16 Mo.
> 
> Lorsqu'une donnee est accedee a la memoire, elle est 
> sauvegardee dans le 
> cache L2 puis dans le cache L1, quand le processeur accede
> a nouveau a cette donnee, il va regarder si elle est dans le 
> cache L1, 
> si elle n'est pas trouvee, il regarde dans le cache L2 puis 
> dans la memoire. Dans un programme, si tu as une boucle qui 
> accede a des donnees en 
> memoire, elles finissent dans le cache.
> 
> Le cache L1 est tres rapide mais tres cher donc il y en a pas 
> beaucoup, 
> le cache L2 est un peu moins rapide mais beaucoup plus rapide 
> que la memoire mais reste aussi chere, etc... Le resultat, 
> c'est que en general le calcul de la taille du cache permet 
> d'avoir 98 % de chance d'avoir les donnees accedees en 
> memoire dans le 
> cache.
> Derriere tout ca, il y a une puce qui calcul les statistiques sur les 
> acces en memoire et qui garde les donnees les plus souvent 
> accedees dans 
> le cache.
> 
> Sans cache, les perfs des processeurs seraient 10 a 50 fois 
> inferieurs a 
> ce qui tu peux avoir avec.
> 
> Pour en revenir a ton probleme, il y a des applications qui ont une 
> maniere d'acceder a la memoire qui fait que les donnees sont toujours 
> degagees du
> cache. Par exemple tu as un thread avec une boucle qui lit 2 Mo en 
> memoire. Tout va bien, ca speede, c'est genial.
> Sur ce, tu decides de creer un autre thread qui fait la meme 
> chose mais 
> qui lit 2 Mo mais ailleurs que le precedent thread. A chaque 
> scheduling, 
> ton
> thread va recharger le cache avec ses donnees en expulsant celles du 
> thread precedent.
> 
> Y'a qu'un moyen de verifier cela, c'est d'instrumenter ton 
> appli et de 
> recuperer les statistiques de la puce. Il y a une valeur qui 
> s'appelle 
> "cache miss",
> si elle augmente lorsque tu augmentes le nombre de threads 
> alors c'est 
> un probleme de cache.
> 
> Cependant, je ne pense pas que ce soit le probleme de ton appli...
> 
> ps : aujourd'hui il existe un cache double: un pour les donnees et un 
> pour les instructions.
> 
>     - Daniel
> 
> 
> _______________________________________________
> Sos mailing list
> Sos at the-doors.enix.org 
> http://the-doors.enix.org/cgi-> bin/mailman/listinfo/sos
>