Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Affichage des résultats 1 à 17 sur 17
  1. #1
    Bonjour,

    Je fais pas mal de tests sur processeurs Intel (Itanium 2 et Core 2). Avec certains collègues nous nous sommes aperçus de comportements un peu bizarres sur ces processeurs, à savoir : on effectue certains calculs (calcul matriciel, produits scalaires, multiplication de vecteurs par des constantes, etc). Rien que de très normal dans ma branche. Sauf que sur un Itanium 2 Montecito qui a son dernier niveau de cache (L3) à 12 Mo, on commence à avoir un grand nombre de défauts de cache autour de 6-8 Mo. J'ai à ma disposition des versions précédentes du processeur (Madison 3 Mo et 9Mo), et le même comportement peut être constaté sur la version à 9 Mo de cache L3 : ça fuit à partir de 6-8 Mo.

    Diagnostic : Intel a rajouté plein de cache sur Itanium 2, mais a oublié (entre autres) d'augmenter la taille des entrées du TLB des données (DTLB niveau 2). C'est une énorme bourde, à laquelle un représentant d'Intel a répondu « no comment » quand un de mes collègues leur a fait remarquer. On pense aussi que certains effets étranges liés au paradoxe des anniversaires fait que les caches de données sont mal exploités (en gros, plutôt que prendre une ligne de cache « vierge », à cause des numéros d'adresse, on se retrouve à écraser une ligne de cache encore utile potentiellement).

    Bon, sur canardplus, parler Itanium 2, c'est pas trop intéressant. Mais si je vous dis que sur Core 2 Duo je trouve à peu près le même comportement ? Voici ce que je mesure.

    Sur un Xeon Woodcrest (5130) avec 4 Mo de cache, je fuis (défauts de cache en L2) vers 2 Mo. L'hypothèse du paradoxe des anniversaires tient toujours, mais par contre, je n'ai aucune idée de ce qui se passe du côté des TLB du core 2. En cherchant bien sur le net, on finit par voir que le TLB niveau 1 sur C2D fait 256 entrées (256 * 4k = 1Mo, ce qui est loin d'être suffisant pour adresser 4 Mo de cache), mais il semblerait que la taille du TLB de niveau 2 soit inconnue (je suppose qu'elle existe, même si elle est sans doute commune aux deux coeurs d'un même processeur C2D).

    Donc voici mes questions :

    - Quelqu'un sait-il quelle est la taille du L2D TLB ?
    - Mis à part ces deux hypothèses -- TLB trop petit pour adresser toute la mémoire, et adresses trop similaires (en fait, il s'agit des LSB des adresses) et qui finissent par écraser des lignes de cache utiles -- auriez-vous une hypothèse ?

    Je trouve que le problème est assez sérieux, étant donné que pour le moment on paie quand même 2 Mo de cache le plus souvent mal exploités non pas à cause des programmeurs (pour une fois ) mais des constructeurs ...

  2. #2
    Ce qui se Passe sur C2D est un probleme lie a la politique de remplacement dans le L2 qui n'est pas "true LRU" ni meme "pseudo LRU" comme c'est le cas habituellement.

    En gros tu as 16 voies mais le LRU fonctionne sur 2 paires de 8 voies et effectue un random pour choisir la bonne paire. Au final avec certains patterns d'acces tu auras l impression d avoir un cache de 2M, si tu augmente la taille de tes donnees et plot un graph des latences tu n'auras pas une marche prononcee a 4M mais un debut d'augmentation progressive a 2M et qui finit doucement aux alentours de 5 ou 6M.

    Sur les C2D Penryn le probleme demarre aussi a 2M car le random est fait entre triplets de 8 voies LRU.

    Le resultat est que tu payes pour 4M ou 6M de cache et tu auras des worloads plus petits qui ne tiennent pas parfaitement et des workloads plus gros qui tiendront mieux que tu ne l'esperes.

    Aucune idee de ce qui se passe sur les Itaniums, mais sur les C2D si ta limite est 2M c'est exactement le probleme que je decris et n'a rien a voir avec les TLBs.
    fefe - Dillon Y'Bon

  3. #3
    Citation Envoyé par fefe Voir le message
    Ce qui se Passe sur C2D est un probleme lie a la politique de remplacement dans le L2 qui n'est pas "true LRU" ni meme "pseudo LRU" comme c'est le cas habituellement.

    En gros tu as 16 voies mais le LRU fonctionne sur 2 paires de 8 voies et effectue un random pour choisir la bonne paire. Au final avec certains patterns d'acces tu auras l impression d avoir un cache de 2M, si tu augmente la taille de tes donnees et plot un graph des latences tu n'auras pas une marche prononcee a 4M mais un debut d'augmentation progressive a 2M et qui finit doucement aux alentours de 5 ou 6M.

    Aucune idee de ce qui se passe sur les Itaniums, mais sur les C2D si ta limite est 2M c'est exactement le probleme que je decris et n'a rien a voir avec les TLBs.
    Merci beaucoup pour cette réponse. Nous tablions sur un problème potentiel de TLB car en utilisant des huge pages (donc 4Mo ou 2Mo sur Core 2) le problème disparaissait de lui-même. Comme je bosse sur des codes plutôt réguliers (codes scientifiques ou multimedia) l'effet était directement visible...

  4. #4
    Les PTE sont caches dans le L2, donc si tu as un probleme de TLB tu payeras un acces au L2 pour recharger la page, mais pas un acces memoire. Si tu peux mesurer la latence de tes acces, si c'est un probleme de capacite des TLBs tu auras des acces a 2x latence L2, mais pas avec la latence de la memoire. Sur du code regulier ou tu accede a chaque page sequentiellement et completement (page de 4Ko) payer 2x latence L2 pour le premier acces est generalement invisible (si cette page a deja ete accedee).

    Par contre a premiere vue je ne vois pas pourquoi utiliser des large pages aurait change qq chose. Sur C2D (Merom) tu as 256 entrees dans ta TLB, soit 1Mo de couvert en pages de 4Ko donc si tu as une baisse de perf liee au manque de TLBs tu le verras apparaitre a 1Mo pas 2Mo (les large pages tu as 32 entrees donc effectivement tu couvres plus que la taille du L2).

    D'ailleurs en general pour les algos reguliers c'est une bonne idee de blocker l'algo pour les 2 niveaux de TLB et les 2 niveaux de cache (le premier niveau de TLB couvre la taille du cache L1 de donnees sur C2D donc possible de l'ignorer).

    Le meilleur moyen d'evaluer si c'est le probleme que j'ai liste cis dessus est de plotter la performance en fonction de la taille de vos donnees (ou de la taille des donnees pour lesquelles vos boucles sont blockees).
    fefe - Dillon Y'Bon

  5. #5
    Citation Envoyé par fefe Voir le message
    Sur du code regulier ou tu accede a chaque page sequentiellement et completement (page de 4Ko) payer 2x latence L2 pour le premier acces est generalement invisible (si cette page a deja ete accedee).
    Au fait dans ce cas-là, est-ce qu'on a du prefetching L2->L1 pour les données? Ou est-ce que ça ne vaut pas le coup vu la latence du L2?

  6. #6
    Le niveau 1 de DTLB est-il vraiment le niveau 1 ? Parce que si oui, ça veut dire 256 comparateurs actifs sur chaque accès mémoire, donc problème de conso et de timing, non ?

    Par ailleurs, il me semblait avoir lu que le nombre de pages de 2 Mo était bien plus faible que 32. Ma mémoire me joue des tours ?

  7. #7
    Citation Envoyé par Møgluglu Voir le message
    Au fait dans ce cas-là, est-ce qu'on a du prefetching L2->L1 pour les données? Ou est-ce que ça ne vaut pas le coup vu la latence du L2?
    Dans ces cas la tu payes effectivement la latence du L1, mais avec la bande passante du L2, donc suivant la quantite de calculs que tu fais ca sera visible ou non (l'acces au L2 est de 14 cycles sur cette machine, donc il est possible que ton algo voie 28 cycles sur 256 iterations, ou non mais a priori ca ne sera pas plus de 10% d'impact sur un algo avec tres peu de calculs par load)

    Citation Envoyé par newbie06 Voir le message
    Le niveau 1 de DTLB est-il vraiment le niveau 1 ? Parce que si oui, ça veut dire 256 comparateurs actifs sur chaque accès mémoire, donc problème de conso et de timing, non ?

    Par ailleurs, il me semblait avoir lu que le nombre de pages de 2 Mo était bien plus faible que 32. Ma mémoire me joue des tours ?
    Tu as 16 entrees de "L0 TLB" et 256 de "L1". la L0 lest la pour la conso et le timing, la L1 pour la capacite avec une penalite en perf limite invisible a l'utilisation.
    Dernière modification par fefe ; 19/07/2008 à 07h45. Motif: Fusion automatique
    fefe - Dillon Y'Bon

  8. #8
    Citation Envoyé par fefe Voir le message
    En gros tu as 16 voies mais le LRU fonctionne sur 2 paires de 8 voies et effectue un random pour choisir la bonne paire.
    si ça venait pas de toi je le croirais pas

  9. #9
    Citation Envoyé par Franck@x86 Voir le message
    si ça venait pas de toi je le croirais pas
    Pourquoi pas?
    Franchement le nombre d'heuristiques compliquées pourries que j'ai vues qu'étaient pas meilleures que de l'aléatoire...
    Sleeping all day, sitting up all night
    Poncing fags that's all right
    We're on the dole and we're proud of it
    We're ready for 5 More Years

  10. #10
    J'avoue que ça m'a surpris aussi :D

  11. #11
    Vous savez LRU dans un cache partage par plusieurs CPUs c'est une mauvaise politique de remplacement (surtout compare a la qualite de LRU quand on a un seul thread). En effet la partition du cache devient quasi proportionelle a la frequence d'acces au cache. En ayant un peu de random la performance est meilleure qu'un vrai LRU lorsque un des threads stream sur des donnees qui ne tiennent pas dans le cache tres vite, et un autre accede de temps en temps ses donnees qui elles tiennent dans le cache (si par chance l'autre thread ne les a pas virees entre temps).
    fefe - Dillon Y'Bon

  12. #12
    Stochastique, les amis!
    Sleeping all day, sitting up all night
    Poncing fags that's all right
    We're on the dole and we're proud of it
    We're ready for 5 More Years

  13. #13
    Voici agrandi 5 millions de fois le contrôleur du futur cache 36-voies (enfin 37 ...) du prochain CPU Intel :


  14. #14
    J'ai une table de roulette?

  15. #15
    Citation Envoyé par ylyad Voir le message
    J'ai une table de roulette?
    Voui, un random sur 37 valeurs, quoi

  16. #16
    Manque Pair L2, Passe Impair L1!
    Sleeping all day, sitting up all night
    Poncing fags that's all right
    We're on the dole and we're proud of it
    We're ready for 5 More Years

  17. #17
    Citation Envoyé par Alexko Voir le message
    Voui, un random sur 37 valeurs, quoi
    Oops...

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •