Intel présente un prototype de processeur x86 octatétracontacœur

Posté par (page perso) . Modéré par tuiu pol.
Tags : aucun
24
4
déc.
2009
Matériel
Le projet TeraScale d'Intel vient d'atteindre une nouvelle étape : un prototype de microprocesseur x86 à 48 cœurs. Intel cite comme possibilités d'utilisation l'informatique nébuleuse, où un grand nombre de processeurs sont rassemblés en un même endroits pour mutualiser leur utilisation, ou encore la vision par ordinateur.

TeraScale, un terrain d'expérimentation dans la voie des processeurs massivement multicœurs, avait déjà conduit à la réalisation de Polaris, un processeur octacontacœur (80), mais avec de petits cœurs au jeu d'instruction réduit. Cette fois, grâce à la gravure en 45 nm et à une technologie de haute permittivité (high-k), ce sont bien des cœurs x86 complets qui sont gravés sur une puce de la taille d'un timbre.

Comme chaque cœur gère son état individuellement et peut même s'éteindre, la puce consomme, selon son utilisation, entre 25 et 125 watts. Les cœurs sont regroupés par paires reliées entre elles par un réseau maillé dont chaque lien fonctionne à 64 Gio/s.

Contrairement aux processeurs actuels, la puce n'utilise pas de mécanisme de cohérence de cache, car la communication entre les cœurs repose sur le passage de messages. Le fondeur a présenté une machine basée sur cette puce fonctionnant sous Linux et Windows. Une telle machine peut se voir dotée de plusieurs puces à 48 cœurs et d'un maximum de 64 Gio de mémoire vive. À quoi une telle puissance pourrait-elle bien servir ? En informatique, jusqu'à présent, les utilisations ont suivi les ressources disponibles, et les bi- ou quadricœurs actuels sont facilement saturés par un gros jeu, un montage vidéo, ou une compression de fichiers en arrière-plan pendant une séance de moulage. Pourtant, même si l'on se moque aujourd'hui de ceux qui pensaient hier qu'un Mio de RAM suffirait à tous, il n'est pas facile de trouver une justification à un processeur à quarante-huit cœurs. Intel, qui garde à l'esprit que les descendants de son prototype seront un jour à vendre, prend donc les devants en citant quelques cas d'utilisation. Le premier concerne l'informatique nébuleuse, où un centre de calcul propose l'accès à ses immenses ressources pour le stockage ou le calcul. Avec une puce massivement multicœurs, on peut remplacer plusieurs lames par un seul processeur consommant au plus 125 watts. L'économie d'énergie et d'espace est évidente. C'est aussi la porte ouverte à la mise en place de petits nuages chez qui en veut.

Intel cite aussi une autre direction : le calcul massif sur une machine personnelle. De même que nos PC ont monté en puissance pour prendre en charge nos moniteurs à la résolution toujours plus élevés et nos interfaces pleines de gadgets, ils pourraient demain permettre l'utilisation d'interfaces homme-machine évoluées. L'utilisateur pourrait ainsi être plongé dans un monde virtuel qui réagirait à ses mouvements, calculant son état en temps réel grâce à sa puissance de calcul.

Le fondeur n'oublie pas de donner des pistes concernant une question importante : comment programmer une machine pareille ? En effet, le développeur confronté à une telle puce se trouve démuni s'il n'a pas des outils suffisamment puissants pour exploiter pleinement la puissance de calcul disponible, tout en restant simples et proches de l'existant. En lien avec TeraScale, Intel propose ses blocs de construction de processus légers (Threading Building Blocks), une bibliothèque de patrons C++ pour développer facilement des applications massivement parallèles. Des expériences ont également été menées avec Hadoop, un environnement de programmation distribuée en Java, qui permet par exemple de diviser un calcul en tâches à répartir selon le principe MapReduce.

Pour le moment, cette puce reste un prototype. Intel compte en produire une centaine pour que des grosses entreprises ou des laboratoires de recherches puissent jouer conduire des expériences dessus.
  • # Utile aussi pour la virtualisation

    Posté par (page perso) . Évalué à 2.

    Moi j'y vois aussi un intérêt pour la virtualisation, une machine physique remplaçant des dizaines de serveurs traditionnels. On est en plein dedans actuellement. Une machine virtuelle par cœur c'est quand même mieux que de devoir partager les ressources CPU de plusieurs machines sur un même cœur. Avec une deuxième machine physique pour le failsafe et c'est parti.
  • # et le kernel dans tout ça ??

    Posté par . Évalué à 9.

    Je ne me suis jamais penchée sur la programmation en parallèle et encore moins sur la programmation de Kernel mais quand même il y a quelque chose qui me dérange mais je sais pas ce que c'est.
    Ma blonditude y est surement pour quelque chose.
    Ah si, ça me revient: Est-ce que vous pensez/croyez que nos Kernels Linux, BSD (et autres systèmes exotiques) monolithiques sont adaptés à ce genre de matériel ??

    Je viens de prendre mon pied intellectuel à lire l'excellente dépêche de Patrick_g et j'ai lu que l'ordonnanceur du noyau a été récemment changé pour des questions de performance.

    Du coup je me pose la question suivante: est-ce que l'architecture de ces Kernels ne sont-ils pas à revoir voire de passer à un système multikernel ??
    A l'instar de Barrel Fish de Microsoft.

    J'ai aussi récemment lu la libération de Grand Central Dispatch, une autre stratégie pour ce problème épineux je suppose.

    S'il y a des experts des noyaux parmi vous, pouvez-vous m'expliquer s'il vous plait. Mais avec des mots simples s'il vous plait, je suis blonde.
    • [^] # Re: et le kernel dans tout ça ??

      Posté par (page perso) . Évalué à 10.

      Sous quel noyau tournent la majorité des super-calculateurs de la mort ? Linux. Donc ça doit être adapté, je pense…
      • [^] # Re: et le kernel dans tout ça ??

        Posté par . Évalué à 6.

        On peut aussi préciser qu'il tourne avec quelques milliers de processeurs.

        "La première sécurité est la liberté"

        • [^] # Re: et le kernel dans tout ça ??

          Posté par . Évalué à 3.

          C'est certain, à l'échelle des super-calculateurs d'aujourd'hui, pas de problème, mais si dans un avenir proche on a, non pas 250k cores, mais un ou plusieurs ordres de grandeurs au dessus, on peut à juste titre se poser la question : est-ce que des améliorations sont prévues, envisageables, ou nécessaires ?

          Mais faire une révolution et casser le coté monolithique du noyau, ça me semble peu probable, vous en pensez quoi ?
          • [^] # Re: et le kernel dans tout ça ??

            Posté par . Évalué à 2.

            Que passer de 100 cores à 100 000 000, cela pose les mêmes problèmes qui existe peu à 4 coeurs. En gros, linux maintient un maximum de structure local à chaque coeur pour éviter tout transfert de mémoire entre coeur.

            "La première sécurité est la liberté"

            • [^] # Re: et le kernel dans tout ça ??

              Posté par . Évalué à 4.

              en théorie oui mais en pratique il y aura sans doute un paradigme de programmation à changer pour passer de "je rend multitache mes threads (je gère mes 10-20-50 threads)" à "je fais des tout petit jobs que je balance dans la grille (100 000 "jobs")"

              Mon avis ils veulent à court terme rendre caduc les GPU et tout mettre sur une seule puce. One chip to rules them all!
              • [^] # Re: et le kernel dans tout ça ??

                Posté par (page perso) . Évalué à 2.

                Mon avis ils veulent à court terme rendre caduc les GPU

                Ça, c'est clair, et c'est officiel. C'est l'objectif du projet Larrabee. En gros, la différence avec la puce dont je parle dans la dépêche est que ça reste une architecture multicœur classique, avec une hiérarchie de caches. Ils vont aussi ajouter de nouvelles instructions. Voir : http://software.intel.com/en-us/articles/larrabee/
              • [^] # Re: et le kernel dans tout ça ??

                Posté par . Évalué à 3.

                Quand on voit comment est fait les GPU, cela ressemble un peu à ça : une cohereance mémoire minimum controler par logiciel.

                Quand on voit Fermi de Nvidia, c'est en gros un cpu qui gère 32 threads en même temps avec 32 unité de calcul !

                "La première sécurité est la liberté"

        • [^] # Re: et le kernel dans tout ça ??

          Posté par . Évalué à 3.

          Et que la quantité de mémoire vive a été repoussée à des limites... qui devraient les laisser tranquill pour un bon moment :p Tout comme au niveau FS par ailleurs ...

          Mais c'est vrai que moi aussi, à lire cette dépêche passionnante, et faisant une jolie suite à celle de Patrick_G sur le dernier noyau, m'a également fait penser à Grand Central Dispatch. Mais là, peut être, il ne s'agit plus de noyau mais de 'conservatisme' pour faciliter l'écriture d'applications au dessus tout en permettant de 'jouer' avec ces fonctionalités noyau-matériel.

          ?
        • [^] # Re: et le kernel dans tout ça ??

          Posté par . Évalué à 10.

          On peut aussi préciser qu'il tourne avec quelques milliers de processeurs.
          http://xkcd.com/619/

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: et le kernel dans tout ça ??

        Posté par (page perso) . Évalué à 5.

        pas si simple...

        il me semble que les archi HTPC sont à base de milliers de board multi processeurs reliés par des liens très haut débit et des technos dédié, mais ou fonctionne une instance logicielle minimaliste, avec un ordonnanceur central qui dispatche...

        en gros, un kernel (optimisé toussa bien sur) par board, donc qui n'aurait à gérer que quelques processeurs multicores (soit quelquechose de relativement classique maintenant)

        mais peut être que j'ai fumé et qu'il y a un kernel pour tout le bousin. Mais j'en serai étonné

        si quelqu'un connait bien ça, bashages ou plussoiement bienvenus :)
        • [^] # Re: et le kernel dans tout ça ??

          Posté par (page perso) . Évalué à 3.

          Effectivement, il y a généralement plusieurs noeuds (avec chacun une instance de l'OS qui tourne) dans un calculateur. L'OS n'a donc pas à gérer des centaines de milliers de coeurs.

          A ma connaissance, la plus grosse machine Linux (ie. avec un seul OS) comporte 1024 ou 2048 coeurs (dans la gamme Altix de chez SGI).
          • [^] # Re: et le kernel dans tout ça ??

            Posté par (page perso) . Évalué à 0.

            je crois que tu te trompes (de deux ordres de grandeur)
            - http://www.top500.org/list/2009/11/100 montre en premier 1 Oak Ridge National Laboratory United States Jaguar - Cray XT5-HE Opteron Six Core 2.6 GHz / 2009 Cray Inc.
            avec 224162 coeurs
            - et le détail donne http://www.top500.org/system/10184 Linux au hasard...

            donc, bon, les annonces Intel avec 48 coeurs, ou ce que tu donnes avec 2048 coeurs... c'est 100 fois plus avec des résultats concrets
            Je te renvoie à la dépêche récurrente de patrick_g (tous les 6 mois) sur le top 500 http://linuxfr.org//2009/11/16/26162.html 5 serveurs windows dans le top 500 parfois ce 1% fait plaisir (ils doivent être super content chez microsoft...).
            • [^] # Re: et le kernel dans tout ça ??

              Posté par (page perso) . Évalué à 4.


              je crois que tu te trompes (de deux ordres de grandeur)


              Non, François a raison et Jaguar n'utilise pas une seule instance du kernel pour les 224162 coeurs. Les noeuds utilisent un version légère du noyau linux (CNL, Compute Node Linux), mais il existe aussi des noyaux spécifiques comme Catamount, utilisé entre autre sur RedStorm (http://www.top500.org/system/10364 , mais l'OS reporté est Linux).

              Ensuite, les problématiques pour l'ordonnancement (entre autres) sont assez différentes à l'échelle d'un gros calculateur : les ressources sont en général exclusives, l'ordonnancement est statique (et est calculé par un gestionnaire de tâches, pas directement par le kernel, à part sur les noeuds où en général l'exécution est très statique).

              Les données du top500 ne sont pas forcément si triviales que ça à exploiter, la plupart des OS étant pas mal modifiés.

              D'autre part, si ça t'intéresse, même dans le cas d'un gros noeud de quelques milliers de coeurs, en général la mémoire est assez décentralisée (une barrette est associée à une puce en gros), ainsi la gestion de l'accès mémoire avec 48 coeurs à la même mémoire est un problème différent et assez récent.
              • [^] # Re: et le kernel dans tout ça ??

                Posté par (page perso) . Évalué à 7.

                A ma connaissance, les plus grosses machine SMP (Un seul OS) sont SGI. D'ailleurs, SGI a travaillé pour que Linux marche bien avec plus de 1024 coeur.

                En gros, la gamme Altix 4700 plafonnait vers le 2048 coeurs Itanium (officiellement 1024 je crois).

                La nouvelle gamme Altix UV (ultraViolet) va aller bien plus loin avec les nouveaux processeurs Nehalem EX. Pour que cela marche, SGI a développé une puce pour avoir un bus NUMA a 15Go/s, puce qui gère de manière matérielle aussi une partie de la tuyauterie des messages MPI. Ce bus leur permet d'avoir une latence faible entre deux coeurs même éloignés or la latence est un paramètre important...

                La plupart des machines du TOP 500 ne sont pas si passionnante que cela car les utilisateurs n'ont pas 100% de la machine. Avoir un gros cluster dont tu ne peux avoir plus de 20% des capacités, c'est comme si tu avais une machine 5 fois plus petite ! Bref, ces gros clusters centralisent la gestion mais leur puissance en chiffre ne correspond pas du tout à la puissance pratique utilisable par un utilisateur.

                En parallèle du top 500, il faudrait un top 500 des résultats de plusieurs VRAI calcul, du type un calcul d'écoulement d'un avion gros porteur sur par exemple fluent, un calcul moléculaire... Bref, choisir par exemple 6 applications industrielles et 6 cas tests et comparer tout cela.

                J'aimerais bien voir comment se comporte fluent sur 100% des noeuds de la machine Jaguar ? J'avoue que je ne crois pas qu'il fonctionne si bien que cela. Au final, le TOP 500 compare de plus en plus celui qui a le plus gros data-center mais pas réellement la plus grosse machine.
                • [^] # Re: et le kernel dans tout ça ??

                  Posté par . Évalué à 4.

                  Les Altix UV seront limitées à 256 sockets Nehalem EX en cache-cohérent, soit 2048 coeurs (4096 threads). On peut mettre plus de sockets (jusqu'à 4096 je crois) mais on perd la cohérence de cache.
                  • [^] # Re: et le kernel dans tout ça ??

                    Posté par (page perso) . Évalué à 2.

                    Par curiosité, quelqu'un sait-il comment fonctionnent les Cray XMT ?
                    Sur la page de Cray (http://www.cray.com/CustomEngineering/KnowledgeManagement/Cr(...) ) il est écrit : The Cray XMT utilizes the MTK Operating system, a monolithic OS that provides a global shared memory view of the system. .
                    Cette machine permet de la programmation par threads, chaque processeur pouvant en exécuter 128, et la machine pouvant avoir 8024 procs, donc elle correspond peut être au contexte un gros OS pour tout gérer (enfin pour la partie calcul).
                    • [^] # Re: et le kernel dans tout ça ??

                      Posté par . Évalué à 5.

                      Le peu que j'en sais:
                      * l'interconnect mémoire est très mauvais donc il est hyper important de ne pas faire d'accès aux mémoires distantes
                      * il n'y a pas de MMU, les process ont chacun un bout de la memoire physique, et ca permet notamment des optimisations cracra pour les comms MPI intra-noeud
                      • [^] # Re: et le kernel dans tout ça ??

                        Posté par . Évalué à 2.

                        Pas de mmu sur une machine qui est monoprocess, cela n'est pas choquant, non ?

                        "La première sécurité est la liberté"

                      • [^] # Re: et le kernel dans tout ça ??

                        Posté par (page perso) . Évalué à 2.

                        il n'y a pas de MMU, les process ont chacun un bout de la memoire physique, et ca permet notamment des optimisations cracra pour les comms MPI intra-noeud
                        T'es sûr qu'on parle de même machine ? Car les exemples d'utilisations que j'ai vu n'utilisaient pas vraiment MPI ...

                        Sinon pour l'interconnect, les expériences que j'ai vu scaler plutôt bien dans le cas où les accès mémoires étaient imprévisibles (genre parcours sur des graphes sans structures a priori).
      • [^] # Re: et le kernel dans tout ça ??

        Posté par (page perso) . Évalué à 5.

        Un Linux fortement modifié, quand même. Dans le cas de BlueGene, par exemple, c'est un noyal monoprocessus (!) avec un gestionnaire de mémoire adapté, sans pagination (re-!). Alors certes ça reste du Linux, mais pour autant, on ne peut pas télécharger la dernière archive sur kernel.com et obtenir directement un fonctionnement efficace sur un supercalculateur à 64k nœuds. Voir : https://asc.llnl.gov/computing_resources/bluegenel/pdf/softw(...)
    • [^] # Re: et le kernel dans tout ça ??

      Posté par . Évalué à 3.

      Les kernel thread sont là pour déporté les tâches noyaux sur plusieurs processeurs.
    • [^] # Re: et le kernel dans tout ça ??

      Posté par (page perso) . Évalué à 4.

      NUMA: http://fr.wikipedia.org/wiki/NUMA

      je sais qu'il y a du WIP chez NetBSD, j'imagine que les autres kernels font de même
      • [^] # Re: et le kernel dans tout ça ??

        Posté par . Évalué à 4.

        Y a au moins AIX, Darwin, HP-UX, Linux, OSF, Solaris, et Windows qui ont une connaissance des noeuds NUMA. Pour les autres, y a pas encore le support dans hwloc, donc je sais pas :)
  • # programmation concurrente

    Posté par . Évalué à 4.

    Je sens que nous aurons de quoi nous amuser avec des langages comme clojure sur de telles machines ;)
    • [^] # Re: programmation concurrente

      Posté par (page perso) . Évalué à 3.

      Je pense que le Google-Go est aussi adapte pour ce genre de processeurs:
      certaines constructions du langage permettent de gerer le massivement multi-thread
      (ce qu'ils appallent les goroutines).
      De l'ordre de 100 000 par coeurs d'apres la video ou Rob Pike fait son speach de
      presentation du langage.
  • # Intel Marketing

    Posté par (page perso) . Évalué à 8.

    Un truc qui est assez bizarre avec cette annonce d'Intel c'est que c'est présenté comme révolutionnaire alors que Tilera fait ça depuis un certain temps.
    Et dans le cas de Tilera ce n'est pas un prototype de recherche qui va être produit à 100 exemplaires...c'est un vrai produit disponible à la vente !

    La famille Tile64: http://www.tilera.com/products/TILE64.php
    On retrouve bien un multi-core (64 coeurs en réseau 8x8).
    Chaque coeur relié aux autres par un réseau qui passe des message et chaque coeur qui peut faire tourner un OS.
    C'est basé sur le jeu d'instruction MIPS et la fréquence max est de 866 MHz (c'est gravé en 90 nm).

    Y'a eu aussi récemment l'annonce du successeur avec la famille TileGx qui sortira en 2010: http://www.tilera.com/products/TILE-Gx.php
    Là on peut monter jusqu'à 100 coeurs 64 bits (réseau 10x10) et la fréquence grimpe à 1,5 GHz (gravure en 40 nm).

    Pourquoi est-ce qu'on fait tout un foin pour le proto d'Intel ? Mystère.
    • [^] # Re: Intel Marketing

      Posté par . Évalué à 1.

      Je n'ai pas lu tes liens, mais est-ce que le Tile64 possède des cœurs capables de se couper s'ils ne sont pas utilisés ?

      Du coup, je trouve que 25 W en utilisation normale (comprendre bureautique) tout en conservant une telle réserve de puissance pour des besoins ponctuels (comme de l'encodage), je trouve que c'est de l'innovation.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Intel Marketing

        Posté par . Évalué à 10.

        Je n'ai pas lu tes liens, mais est-ce que le Tile64 possède des cœurs capables de se couper s'ils ne sont pas utilisés ?

        Eh bien lis les et tu verras que à 700MHz, la puce Tile64 ne consomme que 22 W tous cœurs actifs, et que chaque cœur peut plonger dans un mode endormi.
    • [^] # Re: Intel Marketing

      Posté par (page perso) . Évalué à 9.

      C'est présenté comme révolutionnaire… par Intel. Comme c'est une entreprise américaine, elle fait de la pub à l'américaine. Mais il n'est pas du tout anodin qu'elle prenne cette voie. Je ne connais personne [à part peut-être quelques Chinois, qui ont des Loongson à vendre] qui pense que, demain, nous aurons tous des multicœurs MIPS dans nos machines (je ne parle pas des lecteurs de Blu-Ray et autres vidéo hyper-haute-définition-et-son-Dolby-99.42, mais des machines qui servent à effacer les verrues de tonton Henry sur les photos de vacances et à mouler sur la tribune via Wave). Et il n'y a rien d'étonnant à ce que des architectures réservées aux professionnels soient différentes de celles que l'on trouve au supermarché, c'était déjà le cas du temps de la Connection Machine et ça l'est toujours à l'époque des Blue Gene. En revanche, Intel a bien l'air de vouloir vendre ça au grand public, à plus ou moins long terme, même si ça a l'air d'être plutôt plus. Ça s'inscrit dans le cadre de la vision de l'avenir que j'ai entendu un ingénieur d'Intel présenter en conférence : pour lui, il y aura de plus en plus de cœurs, et trouver à les employer n'est pas un problème [comprendre : c'est surtout une tâche pour le département marketing]. Il y a donc une réelle différence de perspective.

      Pourquoi est-ce qu'on fait tout un foin pour le proto d'Intel ?

      Sur Linuxfr ? Parce que j'ai écrit une dépêche dessus alors que personne ne l'a fait pour d'autres puces, comme celles de Tilera, qui le mériteraient tout autant. Si quelqu'un veut s'y coller…
      • [^] # Re: Intel Marketing

        Posté par (page perso) . Évalué à 4.

        >>> Sur Linuxfr ? Parce que j'ai écrit une dépêche dessus alors que personne ne l'a fait pour d'autres puces

        Je ne critiquais certainement pas ta news qui est très bonne. C'est juste que le net bruisse d'exclamations émerveillées au sujet du proto d'Intel alors que les Tile font le même truc. Je trouve que c'est une belle réussite du département marketing d'Intel.
        • [^] # Re: Intel Marketing

          Posté par . Évalué à 2.

          Est-ce que tu es sûr que les Tile ont une cohérence mémoire ? Dans un soc habituel il n'y en a pas, et c'est assez horrible à gérer. C'est un défi en soi.

          "La première sécurité est la liberté"

          • [^] # Re: Intel Marketing

            Posté par (page perso) . Évalué à 3.

            >>> Est-ce que tu es sûr que les Tile ont une cohérence mémoire ?

            Ben c'est ce qui est marqué sur les docs en tout cas.
            Y'a même tout un bla-bla marketing sans trop de détails techniques au sujet de leur techno DDC : "Tilera's DDC™ (Dynamic Distributed Cache) system for fully coherent cache across the tile array enables scalable performance for threaded and shared memory applications."
            • [^] # Re: Intel Marketing

              Posté par . Évalué à 2.

              Cool. Dans les omap, il n'y a pas de cohérence, donc pour causer entre le dsp et le cpu, c'est "un peu lent"...

              "La première sécurité est la liberté"

    • [^] # Re: Intel Marketing

      Posté par (page perso) . Évalué à 1.

      Ça s'achète où ce genre de processeurs ? Et la carte mère tant qu'à faire. Je n'ai rien trouvé sur Google, ni sur le site du fondeur.

      Je me doute qu'il me faudrait quelques siècles de paie pour m'offrir un tel jouet :D
  • # cohérence de cache

    Posté par . Évalué à 2.

    Y a un truc qui me gène dans la news, en effet il est dit :

    la puce n'utilise pas de mécanisme de cohérence de cache, car la communication entre les cœurs repose sur le passage de messages

    Arrêtez moi si je me trompe mais, autant que je sache, la gestion de la cohérence de cache fonctionne déjà sur le passage de message, enfin plutôt sur de la diffusion de message invalidant les copies d'une données qui vient d'être modifiée dans le cache d'un CPU en particulier.

    Il y a aussi l'autre approche qui consiste à faire du broadcast.

    Donc je ne comprends pas bien ce que veut dire l'auteur de la news ?

    Enfin, s'il n'y a pas de mécanisme de cohérence de cache au niveau hardware et qu'on reporte ça chez le programmeur via les API précitées, n'y a t-il pas un risque d'overhead conséquent ?
    • [^] # Re: cohérence de cache

      Posté par (page perso) . Évalué à 6.

      Dans une architecture multicœur traditionnelle, il y a un gros cache, avec une hiérarchie de niveaux. Plus c'est bas, plus c'est petit, rapide et privé (le L1 est pour un seul cœur, le L2 est généralement partagé entre deux cœurs, etc). Le processeur, globalement, a la charge de maintenir une cohérence globale dans tout ça. Ainsi, si un cœur A lit un mot de la mémoire vive qu'un autre cœur B vient d'écrire, il obtient bien la donnée que B a écrite, même si cette donnée est encore dans le cache et n'a pas été envoyée au contrôleur de RAM. Le maintien de la cohérence est très coûteux et ne passe pas bien à l'échelle : ça marche pour quatre cœurs (et aussi pour un peu plus que ça quand même), mais difficilement pour 48.

      Le principe, ici, est donc de laisser tomber la cohérence de cache. Chaque cœur a son propre cache et s'occupe lui-même de communiquer avec les autres cœurs et avec la mémoire. L'avantage est de se débarrasser d'un système qui coûtait cher, l'inconvénient est… l'absence de cohérence. Une telle puce n'est pas faite pour être programmée de façon parallèle (tout le monde tape en même temps dans la même mémoire partagée), mais plutôt de façon répartie : chacun est dans son petit espace, et quand on veut communiquer, on s'envoie des messages. Alors oui, bien évidemment, si on veut faire de la programmation parallèle avec, il y a un surcoût important. Ce n'est pas étonnant, parce que l'architecture n'est pas faite pour ça.
      • [^] # Re: cohérence de cache<

        Posté par . Évalué à 3.

        donc l'intérêt de cette puce réside surtout dans les possibilités de virtualisation et/ou micro-partionnement et enfin dans l'économie d'énergie réalisée par l'économie d'échelle.
        • [^] # Re: cohérence de cache<

          Posté par . Évalué à 5.

          L'intérêt est aussi dans le parallélisme. Tous les GPU fonctionnent comme ça.

          "La première sécurité est la liberté"

          • [^] # Re: cohérence de cache<

            Posté par . Évalué à 3.

            ah oui parallélisme mais sans concurrence :)
            • [^] # Re: cohérence de cache<

              Posté par . Évalué à 5.

              Si mais de façon bizarre, en gros, tu as interdiction de modifier, tu lis des trucs commun, et tu écris ailleurs. Beaucoup d'algos peuvent se faire comme ça. En gros, cela ressemble à un filtre shell :)

              "La première sécurité est la liberté"

              • [^] # Re: cohérence de cache<

                Posté par . Évalué à 6.

                Ou à un algorithme dans un langage de programmation fonctionnelle.. Je vois venir l'heure de gloire de DPH (Data Parallel Haskell) !

                --
                Jedaï
            • [^] # Re: cohérence de cache<

              Posté par . Évalué à 4.

              On peut faire du parallélisme avec de la concurrence sans cohérence de cache. Faut juste faire de la synchronisation explicite. On a fait ça pendant des années dans les machine non-CC NUMA.
  • # Conséquences en crypto ?

    Posté par (page perso) . Évalué à 5.

    Étant donné que ça va augmenter considérablement la puissance de calcul (et surtout la démocratiser), je serais curieux de savoir quelles vont être les conséquences dans le domaine de la cryptanalyse (notamment les attaques de type "force brute") sur les fonctions de chiffrement et de hachage. Est-ce que ça va avoir des retombées sur les données chiffrées avec SSL, PGP, etc. ?

    Si quelqu'un a des estimations quantitatives notamment sur les algorithmes les plus utilisés (MD5, SHA-*, RSA, etc.), ça serait très intéressant.
    • [^] # Re: Conséquences en crypto ?

      Posté par . Évalué à 3.

      Un article de septembre, publié ici même, devrait t'apporter quelques éléments de réponse :
      http://linuxfr.org/2009/07/26/25767.html
    • [^] # Re: Conséquences en crypto ?

      Posté par . Évalué à 9.

      Normalement les algorithmes cryptographiques sont dimensionnés pour des capacités de calcul inatteignables avant plusieurs dizaines d'années selon la loi de Moore.

      Il est relativement facile de dimensionner les algorithmes face à des attaques par force brute : par exemple dans le cas des algorithmes symétriques, augmenter la taille de la clef d'un bit nécessite de doubler la puissance de calcul pour la trouver. Quand on sait que la puissance de calcul pour un même prix double tous les 18 mois environ, qu'un PC actuel quadricœur tourne à 4*2GHz = 2^35 opérations par seconde (en majorant un chiffrement par un cycle ce qui est un ordre de grandeur cohérent même face à certaines implémentations spécialisées type bitslice & co), soit "35 bits".
      Une puce telle que celle qui est présentée ici ne permet de réaliser finalement que 48/4 = 12 fois plus de calcul par seconde, soit moins de "39 bits". On ne gagne en fait pas un facteur si grand que ça : remplacer tous les processeurs quadri-cœurs par des processeurs 48 cœurs revient à diminuer la sécurité des clefs actuelles de 4 bits, ce qui est peu finalement (les recommandations minimales sont à 128 bits actuellement, et les plus gros calculs réalisés par le monde académique font au maximum 2^60 opérations). Sans compter que ces processeurs sont loin d'être sortis, il y a des chances que leur sortie soit prévisible par la loi de Moore...

      Le gros intérêt d'augmenter la puissance de calcul est plutôt pour les attaques dictionnaires de mot de passe : par rapport à une clef cryptographique dimensionnée pour tenir longtemps, un mot de passe est généralement choisi pour être le plus simple possible modulo les exigences de ce casse-pieds d'administrateur... qui ne peut pas non plus imposer à chacun de retenir des mots de passe aléatoires...

Suivre le flux des commentaires

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