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 Laurent Cligny (site web personnel) . Évalué à 2.
[^] # Re: Utile aussi pour la virtualisation
Posté par FantastIX . Évalué à 10.
[^] # Re: Utile aussi pour la virtualisation
Posté par Gniarf . Évalué à 10.
et puis en fait je suis sûr qu'il y a un buisness à se faire avec des cartes accélératrices Firefox qu'on pourrait brancher sur un port PCI-E...
[^] # Re: Utile aussi pour la virtualisation
Posté par THR4K . Évalué à 3.
THRAK (def.) : 1) A sudden and precise impact moving from intention, direction and commitment, in service of an aim. 2) 117 guitars almost striking the same chord simultaneously.
[^] # Re: Utile aussi pour la virtualisation
Posté par gemegik . Évalué à 3.
[^] # Re: Utile aussi pour la virtualisation
Posté par ʭ ☯ . Évalué à 6.
J'ai au taf un beau (et pas libre) Vmware Esxi avec un Xeon 4core et 4GB de RAM, on y virtualise 10 serveurs sans problème de CPU (occupé à 10% d'un core en moyenne.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Utile aussi pour la virtualisation
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
"La première sécurité est la liberté"
[^] # Re: Utile aussi pour la virtualisation
Posté par galactikboulay . Évalué à 3.
[^] # Re: Utile aussi pour la virtualisation
Posté par Tom Sheldon . Évalué à 3.
[^] # Re: Utile aussi pour la virtualisation
Posté par galactikboulay . Évalué à 3.
[^] # Re: Utile aussi pour la virtualisation
Posté par BAud (site web personnel) . Évalué à 3.
[^] # Re: Utile aussi pour la virtualisation
Posté par galactikboulay . Évalué à 7.
La page de mergemem est a priori celle-ci: http://www.complang.tuwien.ac.at/ulrich/mergemem/
[^] # Re: Utile aussi pour la virtualisation
Posté par Victor STINNER (site web personnel) . Évalué à 5.
http://linuxfr.org/2009/12/03/26207.html#ksm
# et le kernel dans tout ça ??
Posté par turanga leela . Évalué à 9.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
[^] # Re: et le kernel dans tout ça ??
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
"La première sécurité est la liberté"
[^] # Re: et le kernel dans tout ça ??
Posté par let antibarbie = xp <- xp - 1 . Évalué à 3.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: et le kernel dans tout ça ??
Posté par Stibb . Évalué à 4.
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 ɹǝıʌıʃO . Évalué à 2.
Ç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 Nicolas Boulay (site web personnel) . Évalué à 3.
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 bubar🦥 (Mastodon) . Évalué à 3.
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 Grunt . Évalué à 10.
http://xkcd.com/619/
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: et le kernel dans tout ça ??
Posté par zecrazytux (site web personnel) . Évalué à 5.
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 François Trahay (site web personnel) . Évalué à 3.
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 BAud (site web personnel) . Évalué à 0.
- 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 Cédric Chevalier (site web personnel) . É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 Sytoka Modon (site web personnel) . Évalué à 7.
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 Brice Goglin . Évalué à 4.
[^] # Re: et le kernel dans tout ça ??
Posté par Cédric Chevalier (site web personnel) . Évalué à 2.
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 Brice Goglin . Évalué à 5.
* 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 Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: et le kernel dans tout ça ??
Posté par Cédric Chevalier (site web personnel) . Évalué à 2.
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 ɹǝıʌıʃO . Évalué à 5.
[^] # Re: et le kernel dans tout ça ??
Posté par psychoslave__ (site web personnel) . Évalué à 3.
[^] # Re: et le kernel dans tout ça ??
Posté par Stibb . Évalué à 3.
[^] # Re: et le kernel dans tout ça ??
Posté par zecrazytux (site web personnel) . Évalué à 4.
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 Brice Goglin . Évalué à 4.
# programmation concurrente
Posté par Camille_B . Évalué à 4.
[^] # Re: programmation concurrente
Posté par zaurus (site web personnel) . Évalué à 3.
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 patrick_g (site web personnel) . Évalué à 8.
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 zebra3 . Évalué à 1.
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 khivapia . Évalué à 10.
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 ɹǝıʌıʃO . Évalué à 9.
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 patrick_g (site web personnel) . Évalué à 4.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Intel Marketing
Posté par patrick_g (site web personnel) . Évalué à 3.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Intel Marketing
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
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 Dabowl_92 . Évalué à 2.
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 ɹǝıʌıʃO . Évalué à 6.
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 Dabowl_92 . Évalué à 3.
[^] # Re: cohérence de cache<
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
"La première sécurité est la liberté"
[^] # Re: cohérence de cache<
Posté par Dabowl_92 . Évalué à 3.
[^] # Re: cohérence de cache<
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
"La première sécurité est la liberté"
[^] # Re: cohérence de cache<
Posté par Chaddaï Fouché . Évalué à 6.
--
Jedaï
[^] # Re: cohérence de cache<
Posté par Brice Goglin . Évalué à 4.
# Conséquences en crypto ?
Posté par davux (site web personnel) . Évalué à 5.
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 Nonolapéro . Évalué à 3.
http://linuxfr.org/2009/07/26/25767.html
[^] # Re: Conséquences en crypto ?
Posté par khivapia . Évalué à 9.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.