Journal L'architecture des micro-processeurs et des caches mémoires

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
24
23
jan.
2015

Une présentation en Anglais et sous format PDF :

L'architectures des micro-processeurs modernes et notamment des mémoires caches

Ce document de l'université Friedrich-Alexander d'Erlangen-Nuremberg a été réalisée par :

(apparemment, réalisée en 2013 et présentée en juin 2014…)

Personnellement, les pages les plus importantes, dont je changerai un peu beaucoup l'ordre de la présentation :

  • page 32 Historique des processeurs de 2005 à 2012
  • page 43 L’architecture UMA (Uniform Memory Access)
  • page 44 Le successeur NUMA (Non-Uniform Memory Access)
  • page 45 ccNUMA, cc (cache coherent) pour souligner la complexe syncronisation des caches
  • page 24 Comparaison des processeurs Intel et AMD (anciennes générations)
  • page 23 Ces différences techniques reflètent aussi des gestions différents des caches

Sinon, Jean-Max Reymond nous avais fournis un lien intéressant :

C'est l'évolution des latences d'accès à la mémoire entre 1990 et 2020 (prediction), donc voici un aperçu en prenant en compte la remarque de bobo38, les valeurs qui "n'évoluent plus vraiment à partir de ~2005" :

            ½ ns        L1 cache
            3 ns        Branch mispredict
            4 ns        L2 cache
           17 ns        Mutex lock/unlock
          100 ns        Main memory (RAM)
        2 000 ns (2µs)  1KB Zippy-compress

Et les valeurs prévues pour 2020 :

       16 000 ns (16µs) SSD random read
      500 000 ns (½ms)  Round trip in datacenter 
    2 000 000 ns (2ms)  HDD random read (seek)

D'autres liens pour ce journal marque-page avec d'autres valeurs complémentaires :

  • # L'Évolution n'est pas étonnante

    Posté par  (site web personnel) . Évalué à 10.

    Dans les liens que tu postes, certains semblent s'étonner que ça n'évolue plus du côté de la baisse de la latence.
    C'est normal, la latence du processeur et de ses caches est directement lié à la fréquence de fonctionnement du processeur (et oui, avec 3 GHz on retombe sur les 0.33 ns du cycle CPU) qui depuis une dizaine d'années plafonne entre 1 et 4 GHz suivant le modèle. On pourrait aller plus haut mais très difficilement, ça consomme plus, ça chauffe plus, les hautes fréquences ne sont pas sans problèmes à gérer, etc.

    Pour la RAM, de mémoire il est possible de faire mieux mais cette technologie serait bien plus chère à taille de RAM constante. Or nos besoins évoluant, la quantité de RAM semble plus importante que son temps d'accès sauf pour quelques besoins assez spécifiques.

    Merci pour ces liens, au moins je saurais où trouvé certains chiffres et explications pertinents sur le sujet. :)

  • # Quand on s'intéresse a l'architecture des CPU

    Posté par  . Évalué à 7.

    Un projet de CPU (pour le moment à l'état de 'slideware') qui est très intéressant c'est l'architecture Mill.
    Ce qui est très intéressant c'est la quantité d'innovation qu'ils apportent, même si ça rend le projet compliqué à comprendre (comment ça il y a deux 'instruction pointer'? et les instructions sont décodés dans les deux sens??), mais c'est du 100% propriétaire.

    A l'opposé il y a le RISC-V qui a l'avantage d'être libre, mais qui a l'inconvénient d'être très, très conservateur: grosso-modo une pale copie du MIPS qui n'a même pas de 'trap on overflow' sur les instructions entières que le MIPS a..

  • # En rapport...

    Posté par  (Mastodon) . Évalué à 9.

    https://lwn.net/Articles/629155/

    « As network adapters get faster, the time between packets (i.e. the time the kernel has to process each packet) gets smaller. With current 10Gb adapters, there are 1,230ns between two 1538-byte packets… »

    Un article très intéressant sur les interactions entre les réseaux à très haut débit et la gestion bas niveau de la mémoire dans la kernelle Linux, avec des commentaires bien pointus.

  • # Une autre présentation de la même Université

    Posté par  (site web personnel) . Évalué à 4.

    Cette présentation (en Anglais) de 2012 donne des recommandations OpenMP intéressantes aux développeurs (asm/C/C++), c'est un peu la suite par rapport au document de ce journal.

    http://moodle.rrze.uni-erlangen.de/moodle/pluginfile.php/6814/mod_resource/content/0/Part5-Multicore.pdf

    Au programme :

    • Rappel de l'architecture des mémoires caches
    • Optimisation de code avec graph de perf à l'appui
    • Optimisation d'algo imbriqués enroulés (loop fusion, blocking)
    • OpenMP et différentes optimisations comme "outer parallel"
    • OpenMP, les compilos, les alternatives, et les algos
    • ccNUMA "La page mémoire est mappée dans la mémoire locale du processeur l'ayant touchée"
    • C++ et comment éviter de toucher (écrire) la mémoire en train d'être allouée
    • C++ et la bonne localité de la donnée avec new placement
    • Le fonctionnement du Simultaneous multithreading (SMT), avantages, impacts..

    Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)

  • # bizarre de se faire citer…

    Posté par  . Évalué à 3. Dernière modification le 23 janvier 2015 à 22:13.

    …je l'avais oublié ce commentaire :) et l'article en question également

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.