Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81

Posté par mordicusetcubitus le 08 janvier 2014 à 21:13. Édité par Davy Defaud, palm123, ZeroHeure, tuiu pol, Nÿco et claudex. Modéré par claudex. Licence CC By‑SA.

Étiquettes :

jan.

2014

Quand je regarde les ordinateurs de compétition que nous utilisons aujourd’hui et ceux avec lesquels j’ai découvert l’informatique, j’ai l’impression de voir l’évolution de la vie sur terre — qui a commencé il y a environ 3,5 milliards d’années avec l’apparition des premières bactéries, pour arriver jusqu’à l’homme plus ou moins évolué que nous sommes aujourd’hui — ramenée à une soixaine d’années si l’on part du transistor jusqu’aux processeurs les plus avancés d’aujourd’hui, parmi lesquels le processeur MPPA MANYCORE de Kalray.

Sommaire

Nostalgie

Mon premier ordinateur fut un ZX81. C’était un ordinateur familial équipé d’un processeur Z80A cadencé à 3,25 MHz, gérant lui‐même la vidéo et équipé d’un [kibioctet] de mémoire. On pouvait lui clipser au dos une extension mémoire de 16 Kio plus grosse qu’une boîte d’allumettes, qui sautait dès que l’on appuyait trop fort sur les touches, et qu’il fallait scotcher solidement pour ne pas perdre son travail de longues heures de recopie des programmes d’Hebdogiciel…

À la même époque il y avait aussi l’Oric Atmos, le ZX Spectrum, les MSX, l’Atari ST et l’Amiga, ainsi que ce bon vieux TO8 avec son processeur 6809E de Motorola tournant à 1 MHz. Quelle folie ! C’était le bon temps ! Tout était possible, et chacun rivalisait de génie pour exhiber les performances de sa machine dans des demoparties, où tout se codait en assembleur !

Hélas, ils n’ont pas résisté à la venue de l’espèce dominante, les 8086, qui a exterminé tous ces petits mammifères en moins d’une décennie seulement. Et le mastodonte a grossi et connu plus de mutations génétiques que les Pokémons d’évolutions : 286, 386, 486, 586 ou Pentium. Puis, il est passé d’un code génétique 32 bits et d’une architecture CISC à un code 64 bits et une architecture mi‐CISC/RISC, tout en se mutant en un animal à plusieurs têtes/cerveaux pour devenir un processeur multi‐cœur et multi‐thread, et enfin arriver à son stade actuel de l’évolution : le i<chiffre>, actuellement i7 3000, avec 6 cœurs à 2 fils d’exécution (threads) chacun.

Pour en revenir au ZX81 et tous ses amis, c’est intéressant d’observer la puissance de calcul gagnée depuis cette époque glorieuse. Quand j’ai fait mon stage universitaire en 1992, un de mes camarades venait d’acheter un 286 tournant à 16 MHz, équipé de 2 Mio de mémoire vive et d’un disque dur de 200 Mio. J’utilisais encore mon TO8 et me suis exclamé ahuri : « Mais que vas‐tu faire de toute cette puissance ?! »
Aujourd’hui, nous serions bien en peine d’installer un système d’exploitation récent sur une telle machine… En trente ans, l’évolution informatique a été fulgurante :

la fréquence des processeurs a grimpé d’un facteur mille, pour passer du mégahertz (MHz) au gigahertz (GHz) ;
la mémoire vive se mesure aujourd’hui en gibioctets (Gio), comparée aux kibioctets (Kio) de l’époque, le facteur de multiplication est de l’ordre du million (2²⁰ = 1 048 576) ;
les capacités de stockage sont passées du kilooctet (cassette, disquette) au téraoctet (To), soit un facteur d’un milliard de fois plus grand ;
les processeurs sont maintenant multicœurs et multithreads : 2, 4, 8, 16, 32 et maintenant 256 avec les processeurs Kalray.

Si l’on part sur une moyenne de quatre cycles par instruction pour un processeur à 4 MHz, nous avions dans les années 80 une puissance d’environ 1 MIPS pour nos ordinateurs familiaux. C’était déjà pas mal. Bien sûr, je parle d’instructions machine, pas de FLOPS. Là, ce devait être bien moindre.

Le MPPA-256 de Kalray c’est aujourd’hui plus de 460 milliards d’opérations par seconde (460 GIPS) et 230 GFLOPS (simple précision), 256 cœurs VLIW (à longues instructions), organisés en 16 blocs de 16 cœurs, supportant jusqu’à 128 Gio de RAM et d’une consommation moyenne de 5 W. Pour comparaison, un Intel i7 980X a une performance d’environ 90 GFLOPS, pour une consommation de 130 W.

C’est impressionnant, c’en est même renversant !

Sur le papier le MPPA-256, c’est :

une consommation 10 fois moindre que les processeurs multicœurs classiques (un Intel Core i7 consomme typiquement 130 W) ;
une puissance de calcul 4 fois supérieure à la meilleure puce d’Intel (l’Itanium ou le i7-980X) ;
un temps de développement 3 fois plus court que pour les systèmes ASIC ou FPGA (par l’utilisation de langages standard, comme le C ou le C++, et des interfaces de programmation (API) de type POSIX).

Mais entre le discours commercial et la réalité, il y a souvent des marches importantes. Rappelez‐vous du processeur Crusoe de Transmeta qui annonçait de fabuleuses performances à basse consommation, mais qui s’est avéré au final être très en dessous du discours marketing. Mais l’histoire de Transmeta est un peu plus compliquée que cela, nous y reviendrons plus tard.

Dans la pratique le MPPA-256, c’est :

Parfois un peu moins bien, parfois beaucoup mieux.

En fait, tout dépend du contexte d’utilisation. Le processeur Kalray s’illustre dans tous les domaines utilisant des algorithmes massivement parallélisables :

le chiffrement, la cryptographie ;
la vidéo ;
l’imagerie ;
le traitement du signal ;
l’informatique en nuage, les centres de données ;
les supercalculateurs/HPC ;
le contrôle industriel…

Bien qu’il offre une force de calcul impressionnante avec ses 230 GFLOPS, il ne détrône pas les meneurs du marché dans ce domaine, comme le Xeon X2650. Si vous cherchez la force de calcul brute, ce n’est pas forcément le meilleur choix. Mais là où il excelle, c’est dans le rapport performance/consommation électrique ou il envoie du lourd, du très très lourd !

Des faits ! Des faits ! Avec des chiffres !

Voilà, voilà, ils arrivent.

L’encodage vidéo

Qu’il est loin le temps ou l’on mettait des heures à télécharger des vidéos en 320 × 200 sur le Web avec son modem 56k. Aujourd’hui, la vidéo est partout sur Internet (WebTV, streaming, publicité…). Les formats ont évolué et les vidéos en HD deviennent le standard du moment. Les algorithmes d’encodage se prêtent particulièrement bien à la parallélisation. Les tests d’encodage de vidéos du MPPA-256 sont particulièrement éloquents : A performances égales avec une puce Itanium sur l’encodage de vidéos au format HEVC la consommation électrique est 20 fois moindre ! C’est YouTube et Dailymotion qui vont être contents !

L’imagerie et le traitement du signal

Les algorithmes de traitement de l’image ou du signal, utilisant notamment des transformées de Fourier se prêtent, eux aussi, particulièrement bien à la parallélisation. Les secteurs de la surveillance vidéo, du contrôle de qualité, de l’imagerie médicale, de la géophysique et bien d’autres sont particulièrement concernés par ces problématiques.

Dans le cadre de l’imagerie médicale, les cas d’études réalisés montrent qu’en remplaçant des processeurs graphiques ou des multi‐cœurs massifs par le MPPA-256, un gain d’un facteur 4 en consommation énergétique était obtenu. Cette avancée permet de développer des appareils médicaux mobiles pouvant être embarqués dans des véhicules, alors que ces moyens de diagnostic n’étaient disponibles que dans des cabinets de médecins spécialisés.

Le cloud computing, le big data et les fermes de serveurs

Avec l’avènement des sites à volumétrie gigantesque (Google, Yahoo, Amazon, Facebook, Twitter, LinkedIn, Dailymotion, eBay, Wikipédia…) sont nés le big data et le cloud computing ; quant aux fermes de serveurs, elles sont devenues gargantuesques.

En 2011, Google possédait un parc de 900 000 serveurs.

Début 2013, OVH a ouvert le plus grand centre de données au monde, avec une capacité de 360 000 serveurs.

Le fort degré de parallélisme du MPPA-256 s’adapte très bien à ces environnements, d’une part, par la puissance de calcul qu’il offre, d’autre part, par les fabuleuses économies réalisées en matière de consommation électrique. Nous y reviendrons dans quelques instants, mais la consommation électrique est, selon moi, la clef qui fera de ce processeur un KILLER-PROC !

Les performances énergétiques du MPPA sont particulièrement mesurables dans le cadre de systèmes sur une puce (SoC). Dans le cas d’ordinateurs classiques, comme un PC de bureau, remplacer votre processeur par le MPPA-256 ne permettra pas de mesurer un véritable avantage énergétique : il sera masqué par la consommation des autres composants.

Les supercalculateurs

Les supercalculateurs sont toujours plus puissants. Le dernier record date de novembre 2013[ 2013), le Tianhe-2, équipé de plus de 3 millions de cœurs d’Intel Xeon, avec une puissance de calcul de 33,8 pétaFLOPS pour une consommation de 18 MW, vraisemblablement.
Les processeurs multicœurs d’aujourd’hui ont beaucoup de mal à dépasser les 8 cœurs, car la complexité de l’unité de ré‐ordonnancement des instructions croît avec le carré du nombre de cœurs gérés.
Pour combler cela, le processeur Itanium utilise une technologie différente, l’EPIC, qui supprime cet ordonnanceur, très adapté à la programmation parallèle. Les meilleurs Itanium ne dépassent cependant pas 8 cœurs.
Avec 256 cœurs dans son MPPA, Kalray réalise un véritable tour de force !

Quand on parle de supercalculateurs, il y a deux éléments importants à prendre en compte dans leur conception :

la consommation électrique de l’ensemble et la qualité de la régularité de la puissance de l’alimentation de l’ensemble des machines impliquées ;
la distance occupée entre les éléments composant le supercalculateur : l’information ne peut se déplacer plus vite que la lumière. Aussi, si la distance entre les éléments dépasse plusieurs mètres, des temps de latence de l’ordre de la dizaine de nanoseconde peuvent apparaître et atténuer les performances.

Concernant le premier point, le MPPA-256 se positionne particulièrement bien, puisqu’il ne consomme que 5 à 10 W. Il va clairement vous faire économiser de l’énergie !

Concernant le second point, si l’on caricature la puissance d’un superordinateur à son nombre de cœurs, avec 256 cœurs sur une même puce, à nombre de cœurs égal, une seule puce MPPA suffit là où il faudrait 32 processeurs à 8 cœurs. On diminue donc la taille du système par 32 et d’autant les risques de latence. Enfin, cela reste une caricature, mais c’est un facteur qui a une réelle importance.

Au dernier salon du Super Computing qui s’est déroulé à Denver dans le Colorado (SC13), Kalray a démontré une efficacité énergétique de 25 GFLOPS/W sur des exemples de calcul intensif de type multiplications de matrices ou FFT.

Si l’on compare ses performances au classement Green500 list de novembre 2013, autrement dit, au top 500 des supercalculateurs ayant le meilleur ratio puissance/consommation, la tête d’affiche est tenue par le TSUBAME-KFC de l’institut de technologie de Tokyo, avec 4,5 GFLOPS/W.

Avec 25 GFLOPS/W, le MPPA-256 de Kalray battrait d’un facteur 5 ce dernier. Autrement dit, à consommation égale, il aurait une puissance de calcul 5 fois supérieure, ou, à puissance de calcul égale, il consommerait 5 fois moins… Cela laisse rêveur.

Pourquoi Kalray peut réussir là où Transmeta a échoué

Aujourd’hui, l’énergie est un véritable enjeu économique et environnemental. Nous en consommons de plus en plus et elle coûte de plus en plus cher, quelle que soit sa forme : électricité, carburant, gaz…

Elle est l’objet d’une guerre économique, de défis scientifiques et de problèmes politiques.

Du côté de l’informatique nous ne sommes pas épargnés par ce besoin : « les TIC pèsent, avec 1 500 TWh d’électricité consommée par an, pour 10 % de la production mondiale. Soit la production de l’Allemagne et du Japon ».

Ce problème se constate aujourd’hui facilement chez les prestataires disposant d’énormes fermes de serveurs :

OVH investit dans sa propre « usine d’éoliennes » ;
Google aurait consommé en 2011 0,01 % de la production électrique mondiale. Les dirigeants de Google devraient peut‐être penser à appeler les radios qui proposent de payer la facture de votre choix dans leurs émissions du matin…

Avec une consommation réduite d’un facteur 10 sur les architectures classiques, le processeur Kalray vient clairement bouleverser le jeu, et offre une solution particulièrement à propos concernant un besoin de plus en plus crucial pour ce type d’entreprises. L’ignorer serait économiquement dangereux.

Vous allez me dire : « OK, sur la consommation électrique il décoiffe. Mais pourquoi réussirait‐il là où Transmeta a échoué ? »
Transmeta a échoué pour, à mon humble avis, ces 3 raisons principales :

leur premier processeur souffrait de problèmes de performances, ce qui les a amenés à fabriquer l’Efficeon ;
ils avaient choisi d’émuler le jeu d’instructions x86, par une technique dite de « code morphing » qui s’avérait apporter énormément de complexité à leur produit et nuisait, au final, à son efficacité ;
le marché n’était pas prêt.

Kalray n’a pas ces problèmes :

le processeur déchire grave de la mort qui tue en termes de performances, et surtout de ratio performances/consommation énergétique ;
Kalray a une architecture sans complexité ajoutée : le processeur n’essaie pas d’émuler les x86 et fonctionne avec son propre jeu d’instructions, en natif. La chaîne de compilation MPPA ACCESSCORE de Kalray permet de porter et exécuter efficacement une application écrite en C sur l’architecture MPPA MANYCORE. Tout programmeur préfère rester au niveau C et ne pas se plonger dans l’écriture en assembleur spécifique à un processeur ;
le marché est carrément mûr. Au début des années 2000, Jean‐Louis Gassée, fondateur de BeOS, disait que l’avenir était dans les applications de type « Internet Appliance », ce qui l’avait même amené à renommer son système d’exploitation BeIA. Aujourd’hui, nous observons qu’il avait clairement raison. Nous retrouvons ce type d’applications connectées un peu partout : dans les voitures, dans votre frigo, dans votre téléphone… Ces applications souvent embarquées nécessitent des consommations réduites. Enfin, les problèmes de consommation et d’alimentation électrique des grands centres de données n’ont jamais été si importants et problématiques qu’aujourd’hui.

Les processeurs Kalray répondent parfaitement au double problème énergétique des grands centres de données, à savoir la fin de la course à l’optimisation de l’infrastructure (PUE en anglais — Power Usage Effectiveness). Les grands centres de calcul optimisés ont atteint un PUE proche de 1,15, grâce aux efforts visant à réduire toute la consommation électrique « périphérique » comme la chaîne de conversion depuis la haute tension, la climatisation et le refroidissement.

De plus, étant à la limite de la puissance énergétique que les fournisseurs d’électricité peuvent délivrer, l’économie d’énergie va devoir maintenant s’attaquer au cœur du problème : l’efficacité énergétique des nœuds de calcul eux‐mêmes.

En demeurant avec l’architecture constante basée sur x86, la loi de Moore implique une multiplication par 2 tous les 2 ans de la performance, et donc de la consommation électrique. Or, les plus grands centres de données consomment aujourd’hui près de 18 MW et sont dans l’incapacité d’augmenter la capacité de leurs lignes électriques.

La solution MPPA de Kalray apporte une réponse commune à ces deux événements combinés rencontrés dans le monde des supercalculateurs, avec une efficacité énergétique 10 fois supérieure à ce qui ce fait de mieux aujourd’hui.
Enfin, les processeurs Kalray tournent sur GNU/Linux. Ils possèdes tous les atouts pour séduire les constructeurs de supercalculateurs et les exploitants des fermes de serveurs. Une version 64 cœurs encore plus économe pourrait aussi faire fonctionner un smartphone, c’est une voie qui reste à exploiter par Kalray.

Bien que la société ne fait pas encore beaucoup parler d’elle, contrairement à Transmeta qui a su lancer un énorme Buzz avant d’afficher son produit, elle bénéficie déjà de nombreux partenariats avec des industriels dans de nombreux domaines (aéronautique, automobile, recherche, audiovisuel, industrie…).
Parmi ceux‐ci, nous pouvons citer Renault, Thales, Digigram, l’Inria, ATEME…
Les projets menés avec ces industriels lui permettent actuellement de valider les capacités de son processeur avant un lancement en fanfare et, surtout, lui assurent les premiers revenus pour développer ce qui pourrait bien s’avérer être le prochain processeur de la décennie à venir.

En informatique, rien n’est jamais acquis. Beaucoup pensaient que Microsoft et Intel domineraient éternellement le monde de la micro‐informatique, mais Microsoft a clairement manqué la marche des smartphones au profit d’Apple et de Google, ce qui, quelque part, fait la part belle à Linux.
Intel a su mieux réagir sur ce marché, mais s’est quand même bien fait damer le pion par ARM.
Pourtant, ARM a longtemps vécu dans l’ombre d’Intel et AMD en fonctionnant essentiellement sur les systèmes embarqués nécessitant une faible consommation électrique.

C’est clairement cette course énergétique qui a conféré à cette société le succès qu’elle connaît aujourd’hui avec les appareils mobiles. C’est cette même quête de l’énergie qui a toutes les chances de faire décoller les processeurs MPPA de Kalray.

Les risques

Mais rien n’est jamais acquis et la vie n’est jamais toute rose pour personne.

Kalray doit encore séduire les constructeurs et industriels. Les évaluations en cours devraient continuer de confirmer ses bonnes performances.
Kalray reste jeune, et même s’il sait faire tourner Linux, il ne fait pas encore tourner de distributions comme Debian ou Ubuntu. Pour gagner le cœur des grands acteurs de l’Internet, ce dernier point doit être résolu. Mais cela ne devrait pas longtemps être un obstacle avec l’arrivée de Marta Rybczynska dans leur équipe, laquelle achève d’amener Linux sur la voie des processeurs massivement parallèles.

Il ne suffit pas d’avoir le plus beau pedigree pour réussir. BeOS et NextStep n’ont pas su survivre aux licences EULA et à l’agressivité commerciale de Microsoft. AMD n’a jamais réussi à vraiment tenir tête à Intel, même s’il a su survivre jusqu’ici, la société est très mal portante.

Alors, pourquoi Kalray pourrait vraiment réussir ?
Parce que l’efficacité énergétique de ce nouveau processeur amène une réelle rupture technologique qui trouvera un double écho. Dans le monde des grands centres de données qui sont dans le mur énergétique aujourd’hui, et dans le monde de l’embarqué, car il rend aujourd’hui réalisables des applications qui étaient impossibles auparavant, car demandant une forte puissance de calcul pour un budget consommation restreint.

Lorsque des centres comme ceux d’OVH ou Google auront compris qu’avec cette puce ils pourront avoir 10 fois plus de machines à consommation égale, ou consommer 10 fois moins pour la même puissance de calcul, leurs calculs seront vite faits : « Business is money ! »

Les processeurs MPPA-256 sont aussi, et avant tout, une alternative aux coûteuses solutions spécialisées FPGA et ASIC actuellement utilisées dans les projets industriels ayant besoin d’une grande puissance de calcul. Ils diminuent la complexité de programmation de ce type de puces qui demandent plusieurs mois de développement en ramenant ce délai à quelques semaines : « Time is money ! »

Les processeurs Kalray tiennent apparemment clairement leurs engagements, et aucun autre processeur du marché ne rivalise aujourd’hui avec leur rendement en termes de puissance/consommation électrique. Et, contrairement aux projets en cours de leurs concurrents, les MPPA-256 sont opérationnels et disponibles dès maintenant sur le marché.

Ceux qui les utiliseront massivement économiseront massivement leur argent et, dans des marchés hautement concurrentiels, l’argent fait loi. Ailleurs aussi, d’ailleurs. Mais, là, carrément !

Question force de production, Kalray a sous‐traité la fabrication de ses processeurs au numéro un mondial TSMC. Les problèmes d’approvisionnement ne devraient pas se présenter.

Enfin, la société n’en est qu’à ses débuts et planche déjà sur un MPPA à 1 024 cœurs après l’avoir déjà démontré au dernier SuperComputing Show à Denver, en novembre 2013. De quoi durer face à la concurrence et aux besoins toujours croissants en puissance de calcul de nos chers ingénieurs.

Et l’ordinateur du futur ?…

Pour ceux qui, comme moi, rêvent un peu trop à voix haute et s’intéressent aux avancées de la science et de l’industrie, voyez ce que le futur nous prépare :

Tout d’abord, dans un futur presque immédiat, nous devrions voir la fusion des systèmes hôtes smartphones, tablettes et ordinateurs portables à l’instar du PadFone d’Asus ou des nouveaux portables dont l’écran se détache comme celui d’une tablette.

Tous les ordinateurs auront donc au moins une carte SIM intégrée avec téléphonie mobile 4G, et, du coup, la fibre optique se généralisera pour tenter de concurrencer la 4G. Nostradamus a parlé ! Mais, cela, c’est déjà en cours.

Bien sûr, ces ordinateurs seront entièrement personnalisables sur le principe du Phonebloks. Tous les écrans seront tactiles et même pliables comme des feuilles de papier.

Les batteries de nos téléphones seront produites par des bactéries en impression 3D. Ils seront d’ailleurs équipés d’un mini panneau photovoltaïque ayant un rendement important et leur conférant une autonomie quasi‐illimitée.

Ils seront équipés de détecteurs en tout genre, comme la radioactivité, le cancer, microscope, laser…
Ils pourront être pilotés par télépathie et nous transmettre des informations sensorielles.
Bien sûr, ils se localiseront grâce au système de positionnement par satellites Galileo, avec une précision inférieure au millimètre. Si, si, il va arriver, un jour…

Ils n’utiliseront plus le silicium, mais des composés carbonés comme le graphène. Ils stockeront des pétaoctets de données dans des mémoires à base de quartz…
Et, ils seront quantiques…

De plus, ils auront des verres incassables de chez Afflelou ou tomberont toujours du bon côté.

Pour finir, je tiens à préciser que, malgré mon engouement notoire pour cette belle technologie qu’est le MPPA-256, je ne travaille pas pour Kalray. Ce qui n’empêche pas que je sois totalement partial sur ce sujet. Normal, le MPPA-256 c’est un catalyseur d’économies : c’est bon pour les affaires, et c’est bon pour la planète !

Aller plus loin

Kalray (1292 clics)

# Pour comparer les performances

Posté par Jean-Max Reymond (site web personnel) le 08 janvier 2014 à 21:21. Évalué à 10.

un lien sympa pour comparer les performances et prendre un grand coup de vieux: http://www.eecs.berkeley.edu/~rcs/research/interactive_latency.html
- [^] # Re: Pour comparer les performances
  
  Posté par abgech le 09 janvier 2014 à 07:49. Évalué à 8. Dernière modification le 09 janvier 2014 à 07:52.
  
  Pour prendre un énorme coup de vieux, référence au premier ordinateur qui a vu mes débuts hésitants de programmation : https://en.wikipedia.org/wiki/IBM_1620 .
  En Fortran déjà à l'époque ! Puis j'ai appris l'assembler (qui s'appelait le SPS), et je suis tombé dans la marmite à un point tel que, même à la retraite aujourd'hui, je commets encore passablement de lignes en C.
  
  Il y a un groupe de vieux nostalgiques dans mon genre ( à l'époque, l'informatique, c'était le Far West, il fallait tout inventer) qui s'amusent à simuler la 1620 (on disait la et pas le) : http://www.jowsey.com/java/sim1620/.
  Je ne sais pas ce qui me retient de me joindre à eux (peut-être java, MDR), parce que, je me souviens encore très bien du SPS et du fonctionnement interne du CPU.
  En cours d'exécution du programme, on pouvait, pour débugger, aller, par un bouton hardware, d'instruction en instruction, voire pas à pas à l'intérieur des différents cycles machine (lecture, décodage, exécution) tout en examinant l'état des registres internes. Bref, le pied intégral pour les bidouilleurs.
  
  Et ne parlons pas des codes instructions que l'on modifiait par programme, sans compter les adresses contenues dans une instruction modifiée par une autre (ha, la joie des switch directement programmés dans le code machine).
  On peut toujours le faire dans les architectures modernes, mais, je ne sais pas pourquoi, ce genre de technique a très mauvaise presse (MDR). Sans doute, mais c'est une mauvaise raison, parce que cela rend un programme incompréhensible, particulièrement tordu et totalement illisible, dont la maintenance est impossible que par un autre que celui qui l'a écrit (et encore) ?
  - [^] # Re: Pour comparer les performances
    
    Posté par Nicolas Boulay (site web personnel) le 09 janvier 2014 à 09:47. Évalué à 6.
    
    "On peut toujours le faire dans les architectures modernes, mais, je ne sais pas pourquoi, ce genre de technique a très mauvaise presse (MDR). Sans doute, mais c'est une mauvaise raison, parce que cela rend un programme incompréhensible, particulièrement tordu et totalement illisible, dont la maintenance est impossible que par un autre que celui qui l'a écrit (et encore) ?"
    
    Les caches data et code étant séparé, ce genre de bidouille est très peu performante. Pour des raisons de sécurité, on déteste que des données deviennent du code exécutable.
    
    "La première sécurité est la liberté"
    - [^] # Re: Pour comparer les performances
      
      Posté par PLuG le 09 janvier 2014 à 18:22. Évalué à 8.
      
      Je me souviens de "protections" de logiciels qui utilisaient cette particularité.
      une instruction venait modifier une adresse de saut quelques octets plus loin (très près) ce qui en temps normal n'avait pas d'effet puisque cette adresse de saut avait déjà été décodée par le prefetch du processeur…
      en cas de tentative de debug et d'execution pas par pas de ce morceau de code, le prefetch ne se fait pas, l'adresse de saut se modifie … et on ne comprends plus rien :-)
      
      mais je vois que même wikipedia en parle : http://en.wikipedia.org/wiki/Prefetch_input_queue
      citation:
      
      x86 example code
      code_starts_here: mov eax, ahead mov [eax], 0x9090 ahead: jmp near to_the_end ; Some other code to_the_end:
      
      _This self-modifying program will overwrite the jmp to_the_end with two NOPs (which is encoded as 0x9090). The jump jmp near to_the_end is assembled into two bytes of machine code, so the two NOPs will just overwrite this jump and nothing else. (That is, the jump is replaced with a do-nothing-code.)
      
      Because the machine code of the jump is already read into the PIQ, and probably also already executed by the processor (superscalar processors execute several instructions at once, but they "pretend" that they don't because of the need for backward compatibility), the change of the code will not have any change of the execution flow.
      _
    - [^] # Re: Pour comparer les performances
      
      Posté par abgech le 10 janvier 2014 à 19:08. Évalué à 1.
      
      Je crois, Nicolas Boulay, que tu n'as strictement aucun sens de l'humour et du deuxième degré !
- [^] # Re: Pour comparer les performances
  
  Posté par bobo38 le 09 janvier 2014 à 20:59. Évalué à 2.
  
  …Merci pour le lien !
  
  Marrant les chiffres n'évoluent plus vraiment à partir de ~2005…
# Et les cartes graphiques ?

Posté par flan (site web personnel) le 08 janvier 2014 à 21:39. Évalué à 6.

Quand on me parle de « manycore », je pense en tout premier lieu aux cartes graphiques (ou leurs dérivées). Pour le coup, 256 cœurs, c'est plutôt ridicule pour une carte de calcul moderne. Les dernières Tesla ont par exemple pas loin de 3 000 cœurs.

Très grossièrement, les processeurs type Xeon sont « moyennement » bons partout. Les processeurs type Tesla sont excellents sur certains problèmes, très mauvais sur d'autres.
- [^] # Re: Et les cartes graphiques ?
  
  Posté par linette le 08 janvier 2014 à 21:44. Évalué à 0. Dernière modification le 08 janvier 2014 à 21:45.
  
  Pour les cartes graphiques cela ne resoud pas le probleme de la consommation qui la est vraiment l'avancée technique majeure avec ce processeur
  - [^] # Re: Et les cartes graphiques ?
    
    Posté par flan (site web personnel) le 08 janvier 2014 à 21:50. Évalué à 3. Dernière modification le 08 janvier 2014 à 21:52.
    
    Peut-on avoir des chiffres précis ? En GFlops/W, par exemple. Ça donnerait des indications sur ce que ça vaut vraiment.
    En gros, on parle d'en gros 15-20 GFlops/W pour une Tesla moderne, alors que ça prend en compte les 6 Go de RAM.
    - [^] # Re: Et les cartes graphiques ?
      
      Posté par claudex le 08 janvier 2014 à 21:53. Évalué à 4.
      
      On peut se baser sur les supercalculateurs qui embarquent des cartes graphiques. Ils contiennent aussi des CPU mais je ne suis pas sûr qu'il soit trivial de s'en passer http://www.green500.org/lists/green201311
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
    - [^] # Re: Et les cartes graphiques ?
      
      Posté par glisse le 08 janvier 2014 à 22:50. Évalué à 4.
      
      La news dit 25GFlops/W pour le MPPA256. Mais bon oui c'est un GPU sans tous les bloques annexes (encodeur hdmi, vga, texture unit, …) et avec un controlleur mémoire beaucoup plus simple que pour les GPU. A mon avis c'est là où il économise en énergie. Les larges caches des GPUs et leur hiérarchie complexe coûtent énormément en énergie.
      
      Bon après je trouve l'article vraiment naif sur l'utilisation des many core, pour vraiment tirer partie des avantages many core ils faut vraiment penser ses algorithmes différemment. Il y a beaucoup d'exemple qui montre des facteur 100 ie l'implémentation usuel rapide pour CPU qu'on fait tourner sur un many core en s'en remettant au compilateur pour extraire le parallélisme et une implémentation conçu pour le multi-core avec l'algorithme repensé pour.
      
      Ce problème d'extraction du parallélisme est empiré par les VLIW (very long instruction word) qui compliquent énormément la tache du compilateur.
      
      Bref mis à part la consomation énergétique je ne suis pas du tout impressionné par ce MPPA256 qui a par ailleurs une memory bandwidth bien inférieur à celle des GPU desktop.
      - [^] # Re: Et les cartes graphiques ?
        
        Posté par flan (site web personnel) le 08 janvier 2014 à 23:04. Évalué à 1.
        
        Pour les GPU, la consommation prend en compte celle de la RAM (et 6 Go de RAM, ça doit bien faire dans les 20 ou 30 W, c'est loin d'être négligeable).
        Et pour les cartes de type Tesla, les blocs annexes ont été supprimés à mon avis (certaines n'ont de toute façon pas de sortie graphique).
        
        Pour le reste, je suis d'accord avec toi.
        
        [^] # Re: Et les cartes graphiques ?
        
        Posté par glisse le 08 janvier 2014 à 23:12. Évalué à 1.
        
        Au temps que je sache les bloques annexes ne sont pas supprimé totalement sur les tesla et il y a une légére perte à cause de celà. Et oui la GDDR5 est très énergievore, pour du 6Go je dirait plutôt de l'ordre 60W de consommation (un ingénieur hw m'avait dis multiplie par 10 grosso merdo).
  - [^] # Re: Et les cartes graphiques ?
    
    Posté par karteum59 le 09 janvier 2014 à 00:55. Évalué à 7. Dernière modification le 09 janvier 2014 à 00:59.
    
    Sur le papier le MPPA 256 c'est (…)
    
    Sauf que chacun de ces cores n'est en aucun cas comparable à un core i7. En particulier, ils sont plutôt mauvais pour le traitement out-of-order.
    Note que ce que fait Kalray me semble assez proche de ce que fait Adapteva/Parallela http://www.adapteva.com/
    
    Pour les cartes graphiques cela ne resoud pas le probleme de la consommation qui la est vraiment l'avancée technique majeure avec ce processeur
    
    pas encore
    
    Mais ça progresse très vite ! (et il me semble assez possible que ça réduise significativement l'espace économique qui sera laissé aux Kalray et Adapteva…)
    - [^] # Re: Et les cartes graphiques ?
      
      Posté par karteum59 le 09 janvier 2014 à 01:17. Évalué à 10. Dernière modification le 09 janvier 2014 à 01:17.
      
      les TIC pèsent, avec 1 500 teraWatt-heure d'électricité consommée par an, pour 10 % de la production mondiale. Soit la production de l'Allemagne et du Japon
      
      Par ailleurs en parlant de consommation, il parait bon de rappeler que l'utilisation d'une machine pèse très peu par rapport à ce que nécessite sa fabrication. Donc le meilleur moyen de consommer moins, c'est d'utiliser nos machines longtemps (même si elles sont grosses, obsolètes et energivores !)
      - [^] # Re: Et les cartes graphiques ?
        
        Posté par Maclag le 09 janvier 2014 à 03:55. Évalué à 10.
        
        Un peu comme les bagnoles. Je me demande quand on verra des primes à la casse pour les consommateurs qui auraient l'outrecuidance de garder leurs téléphones trop longtemps?
        
        [^] # Re: Et les cartes graphiques ?
        
        Posté par karteum59 le 09 janvier 2014 à 15:46. Évalué à 10.
        
        Pour les bagnoles, je pense a priori (me corriger si je me trompe) que la répartition du bilan énergétique entre fabrication/utilisation est plus équilibrée. Du coup il pourrait être utile d'avoir une prime à la casse ciblée (+ augmentation de la TIPP progressive) pour remplacer les véhicules lourds/énergivores actuels par des mobylettes ou "2CV nouvelle version" qui consomment 1 à 2 litres au 100… (ça serait d'ailleurs peut-être plus urgent et plus utile à budget constant que déployer de nouvelles lignes de tram en grande banlieue, qui de toute façon n'entraineront qu'un report modal négligeable).
        
        [^] # Re: Et les cartes graphiques ?
        
        Posté par Maclag le 09 janvier 2014 à 21:34. Évalué à 5.
        
        J'ai lu il y a très longtemps (et évidemment je n'arrive pas à remettre la main dessus) que même en tenant compte des progrès en termes de consommation, et en supposant (à l'époque) qu'ils continueraient au même rythme, il faudrait rouler 400,000km avec sa voiture pour qu'il soit écologiquement rentable de la remplacer.
        
        Problème principal aujourd'hui (qui était déjà pas mal vrai quand j'ai lu l'article): la plupart des bagnoles ne tiennent plus 400,000km sans tomber en ruines.
        
        Maintenant, je pense que l'étude supposait que tu remplaces ta voiture par un modèle équivalent alors que toi tu proposes de pousser vers des petits modèles (ce qui a du sens, mais je ne crois pas qu'on verra ça de sitôt).
        
        [^] # Re: Et les cartes graphiques ?
        
        Posté par Dring le 10 janvier 2014 à 16:41. Évalué à 8.
        
        Ne tiennent ~~plus~~pas 400 000 bornes
        
        Les anciennes voitures n'étaient pas vraiment meilleures qu'aujourd'hui niveau résistance au temps. Les moteurs étaient certes plus simples, et faciles à entretenir. Il n'y avait pas d'électronique pour tomber en panne.
        
        Par contre, la rouille faisait son ouvrage, et parfois en 5 ans d'existence, pour un peu que tu aies roulé dans du sable ou du sel, tout le bas de ta caisse (voire plus) était raide mort, et tes sièges avaient tendance à vouloir partir tout seuls.
        
        Cas extrême : les alfa roméos. Mais même Renault, avant 1984/85, était une catastrophe de ce point de vue.
        
        Bref, attention à l'excès de "c'était mieux à vent".
        
        [^] # Re: Et les cartes graphiques ?
        
        Posté par Antoine le 15 janvier 2014 à 21:28. Évalué à 2.
        
        Il n'y a pas que la consommation énergétique, il y a aussi la pollution due aux gaz d'échappement (qui est censée être bien moindre aujourd'hui à puissance égale).
        
        [^] # Re: Et les cartes graphiques ?
        
        Posté par Antoine le 15 janvier 2014 à 21:27. Évalué à 2.
        
        Tant qu'il n'y a pas de constructeur français avec un poids économique important, peu de risques.
    - [^] # Re: Et les cartes graphiques ?
      
      Posté par black le 09 janvier 2014 à 19:36. Évalué à 2.
      
      Il ya une grande différence entre Kalray et Adapteva. Sur MPPA256 tous les cores sont de vrais processeurs qui peuvent le faire les opérations normales. Les exemples de l'assembleur sont sur
      http://events.linuxfoundation.org/sites/events/files/slides/Rybczynska_Going_Linux_on_Massive_Multicore.pdf slide 18.
- [^] # Re: Et les cartes graphiques ?
  
  Posté par Zylabon le 08 janvier 2014 à 21:57. Évalué à 10.
  
  Une carte graphique c'est pas un manycore, c'est une architecture SIMD, Simple Instruction Multiple Data. Très efficace pour traiter beaucoup de données mais toutes exactement de la même manière. C'est à dire sans même d’exécution conditionnelle.
  
  Le MPPA est un MIMD. Il peut traiter plusieurs données différentes en même temps, avec plusieurs traitement différents, plusieurs programmes différent même il me semble…
  
  les processeurs type Xeon sont « moyennement » bons partout.
  
  Non… Pour des algorithmes séquentiels on a pas mieux (à part le processeur ad-hoc).
  
  Please do not feed the trolls
  - [^] # Re: Et les cartes graphiques ?
    
    Posté par flan (site web personnel) le 08 janvier 2014 à 22:59. Évalué à 5.
    
    À ma connaissance, une CG moderne n'est plus un pur SIMD, c'est plutôt un SIMD « par blocs ».
    
    Pour les Xeon, j'ai mis des guillemets parce que justement ils peuvent être très bons, mais on pourra faire toujours mieux pour certains traitements (avec des ASIC, par exemple). Je voulais simplement dire qu'un Xeon moderne (ou équivalent) a en interne un peu de tout : du flottant, du SIMD flottant et entier avec le SSE , de l'entier, du chiffrement natif, pas mal de cache, … Bref, quelque soit le problème, tu auras toujours une partie du processeur qui ne servira à rien (donc processeur sous-optimal) mais tu auras aussi toujours la bonne instruction sous la main, et ce n'est pas le cas sur n'importe quel processeur.
    - [^] # Re: Et les cartes graphiques ?
      
      Posté par lasher le 09 janvier 2014 à 21:25. Évalué à 6.
      Ça dépend pas mal du constructeur. Les cartes Nvidia sont « SIMT » (Single Instruction, Multiple Threads), divisés en blocs de (par exemple) 32 threads. Il y a pas mal de limites (avec des contournements à la con pour les éviter). Par exemple, si j'ai le code d'un thread qui dit :
      
      if (condition) { // code } else { // code }
      
      Tous les threads d'un warp (d'un bloc) vont devoir passer par le if et le else. Donc même si un seul thread doit traiter le else, tous les autres threads doivent l'attendre. Le contournement est de récrire le code de cette manière (approximativement):
      
      if (condition) { // code } if (!condition) { // code }
      
      Ainsi on procède successivement à l'appel de deux if et là, ça marche. Oui, c'est couillon, mais c'est comme ça (ou en tout cas ça l'était jusqu'à il y a 2 ans …).
      
      Les GPU de Nvidia ont aussi des mécanismes qui favorisent les accès séquentiels à la mémoire (en gros, si les accès sont tous séquentiels en VRAM, alors la performance est maximale car en gros les données sont « cachées »; sinon, il faut effectuer une sorte d'opération de « gather/scatter », ce qui ralentit considérablement l'exécution des threads).
      
      Les GPU d'AMD/ATI sont légèrement différents. Il y a bien une séparation en blocs, mais cette fois on a plutôt affaire à des CPU « VLIW » (very long instruction word), chaque instruction longue pouvant traiter jusqu'à 4 « instructions courtes » (ou peut-être 5). Et là il s'agit plus d'un « vrai » mode SIMD.
      - [^] # Re: Et les cartes graphiques ?
        
        Posté par glisse le 10 janvier 2014 à 06:36. Évalué à 3.
        
        L'appelation SIMT de NVidia c'est plus du marketing qu'autre choses, c'est du SIMD au final comme sur AMD ou Intel mais pas du SIMD comme les extensions CPU ou les anciens SIMD des annees 90.
        
        Ton exemple est completement faut a moins que tu es eu a faire a un bug driver. Le GPU (AMD, Intel ou NVidia) utilise un mask pour savoir qu'elle thread sont actif. Quand il y a une branch les threads qui ne passe pas le test sont masque, oui les instructions de la branch vont s'executer pour les 32 threads mais les resultats ne seront jamais ecris ni dans les registres ni en memoire pour les threads qui n'ont pas passe le test (bref ca tourne dans le vide). De plus si aucun thread n'est actif alors les instructions sont completement ignores. Si tu veux comprendre comment marche plus finement tout ca l'emulateur open source de GPU AMD/NVidia implemente le meme algorithme (sans certains details/optimizations/tricks) http://multi2sim.org/ le manuel en particulier donne une description tres claire du fonctionnement des GPU AMD ou NVidia.
        
        Pour les acces memoire c'est comme ca pour tout les GPUs mais il faut vraiment avoir un programme qui fait des acces memoire massivement aleatoire pour voir les performances s'effondrer avec les acces memoire. Que ca soit NVidia ou AMD, le GPUs pour chaque groupe de thread va essayer de batcher ensemble les acces memoire (memory access coalescing). Il faut savoir que sur un GPU en general chaque acces a la VRAM retourne une grosse quantite de memoire (depends de la taille du bus) souvent > 256bits.
        
        AMD n'est plus VLIW depuis les HD77xx mais sinon ca marchait comme NVidia tu avais un groupe de 32thread qui executait la meme instruction VLIW pour chaque threads.
        
        [^] # Re: Et les cartes graphiques ?
        
        Posté par lasher le 10 janvier 2014 à 17:18. Évalué à 2.
        
        Mon exemple est tiré d'un papier de compilation pour GPU. Il est tout à fait possible que la façon dont j'ai simplifié/représenté le pseudo-code (de mémoire) ne déclenche pas ce comportement tel qu'écrit. Mais c'était réellement l'idée à 1000km d'altitude.
        
        Je suis en train de chercher le papier en question, et dès que je le retrouve, je viendrai donner les références ici.
        
        [^] # Re: Et les cartes graphiques ?
        
        Posté par lasher le 11 janvier 2014 à 22:51. Évalué à 2.
        
        Voilà, j'ai retrouvé le papier dont je parlais : A control-structure splitting optimization for GPGPU
        
        [^] # Re: Et les cartes graphiques ?
        
        Posté par glisse le 12 janvier 2014 à 00:19. Évalué à 0.
        
        Bon je n'ai pas pu accéder au pdf (saloperie de publication payante) mais j'ai trouvé une présentation qui semble référer à l'article http://www.cs.indiana.edu/~achauhan/Teaching/B629/2010-Fall/StudentPresns/GPUcompilation.pdf si j'en crois cette présentation la technique n'est pas de casser le if/else mais de faire deux kernel/shader/(le nom que vous aimé pour le programme GPU) l'un qui exécute pour ce qui est la partie if et l'autre pour la partie else.
        
        Bref le GPU marche bien comme je l'expliquai et dans certain cas ce genre d'optimization peut faire gagner en puissance mais bon c'est un genre de tradeoff difficilement évaluable et à mon avis cette astuce est utile que dans un cas nombre de cas limité.
        
        Il y a beaucoup d'autre optimisation qui serait contre productive sur CPU mais qui améliore les performances et la gestions des branches avec un GPU (la présentation au dessus en liste un certains nombre). Mais bon comme je le disais plus haut pour tout les architectures many core c'est avant tout l'algorithme qui doit être repensé et évité le plus possible les branchements fait partie de la liste des choses à faire.
        
        [^] # Re: Et les cartes graphiques ?
        
        Posté par cedric le 12 janvier 2014 à 03:38. Évalué à 3.
        
        C'est une évidence que la complexité de tes shader impacte les performances. Tout comme les optimisation qui suppriment les invariant des coeur de boucle et les dupliquent. Avec les shaders, il faut le faire a la main étant donné la barrière entre les deux compilateurs. C'est d'ailleurs un des grands inconvénients de ce modèles de rendu, surtout quand on sait qu'il faut limiter les changements de shaders pour maximiser les performances.
  - [^] # Re: Et les cartes graphiques ?
    
    Posté par glisse le 08 janvier 2014 à 23:06. Évalué à 8.
    
    Les GPU sont devenus beaucoup plus performant pour exécuter du code conditionnel et ils ont de nombreuses astuces pour gérer le control flow graph d'un programme (c'est d'ailleurs assez intéressant en soit). Par ailleurs il faut relativiser l'aspect SI (single instruction) du SIMD sur les GPUs. Sur un GPU tu as des groupes de thread (32 thread forme un groupe est courant) qui exécute la même instruction sur des données différentes. Mais a tout instant t tu as N groupes différent de thread qui sont en vie au même moment chacun de ces groupes pouvant exécuter un programme différent. Autrement dis tu as un programme A et un programme B chacune avec 32 thread à un cycle donné le GPU va soit executer le group de thread A soit le group de thread B (il y a un scheduler qui décide). En général sur un GPU moderne tu peux avoir >256 programmes différent qui s'executent en même temps (les unités SIMD sont groupées en bloque eux même regrouper en plus gros bloque et la granularité du scheduler dépend du design du GPU).
    
    Par ailleurs, jusqu'à récement (jusqu'aux radeon HD6xxx) AMD était plus proche d'un design MIMD que d'un design SIMD en un sens, mais l'expérience du GPGPU leur à montrer que ce n'était pas le design le plus approprié mais qu'au contraire des unités SIMD plus simple sont au finale plus performante pour le GPGPU.
    
    Dans tous les cas l'aspect VLIW est vraiment horrible et les GPU récent sont de plus en plus multi-task et la prochaine génération sera capable de créer de nouveau groupes de thread directement depuis un thread en cour d'exécution.
    - [^] # Re: Et les cartes graphiques ?
      
      Posté par khivapia le 09 janvier 2014 à 16:48. Évalué à 3.
      
      le GPU va soit executer le group de thread A soit le group de thread B (il y a un scheduler qui décide)
      En gros ça passe son temps à faire des context switch ? C'est pas pénalisant pour les performances justement ?
      
      Dans le cas des CPU, avoir plus de threads que de cœurs n'est généralement utile que pour optimiser un code limité par la bande passante du bus mémoire en la saturant (plein de threads faisant plein d'accès mémoire pour maximiser la bande passante utilisée, avec changement de thread sur cache miss), sinon ça limite fortement l'utilisation des cache.
      - [^] # Re: Et les cartes graphiques ?
        
        Posté par khivapia le 09 janvier 2014 à 16:54. Évalué à 2.
        
        Ou alors c'est utile parce que justement les GPU ont une grosse bande passante mémoire ?
        
        [^] # Re: Et les cartes graphiques ?
        
        Posté par Nicolas Boulay (site web personnel) le 09 janvier 2014 à 16:58. Évalué à 3.
        
        De mémoire, un bloc de calcul de Fermi avait 132 000 registres. Chaque thread en utilise une partie, il n'y a pas de copie au switch, comme pour les cpu multithread mais en plus souple.
        
        "La première sécurité est la liberté"
      - [^] # Re: Et les cartes graphiques ?
        
        Posté par glisse le 09 janvier 2014 à 19:26. Évalué à 7.
        
        Le context switch sur GPU a aucun cout. Chaque group de calcul du GPU est associe avec une memoire local qui est diviser entre les registres et les variables local memory (dans opencl). ie le programme A va avoir ses register N register entre [0..N] dans cette memoire et le programme B va avoir ses M registres entre [N..N+M]. Dans les descriptions de GPU c'est la register file le nom de la memoire en general (toujours un acteur pour trouver un nouveau plus hyper pour le marketing). Donc il n'y a aucune copie avec la memoire externe. Tout se passe en memoire interne ultra-rapide (charge depuis un registre de cette memoire prend un tick de clock sur tous les GPU que je connais).
        
        En faite la plus part interleave l'execution des different programmes (A et B dans mon exemple) ie au tick de clock t l'instruction de A est decode, au tick t+1, l'instruction de B est decode, au tick t+2 l'instruction de A qui a etait decode commence sont execution, au tick t+3 c'est celle de B qui commence ….
        
        Et oui, contrairement au CPU, pour maximiser l'utiliser d'un GPU tu veux plus de thread que de coeur en general tu en veux 16, 32, 64, … fois plus que de coeurs. C'est ce qui permet de cacher la latence des access memoire (ca et les caches enormes qui existe dans le GPU).
# et sinon ?

Posté par Anonyme le 08 janvier 2014 à 22:00. Évalué à 2.

linux tourne dessus ? ou pas
- [^] # Re: et sinon ?
  
  Posté par claudex le 08 janvier 2014 à 22:03. Évalué à 3.
  
  Enfin, Kalray tourne sur Linux.
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: et sinon ?
    
    Posté par Kerro le 09 janvier 2014 à 17:17. Évalué à 6.
    
    Un processeur qui tourne sur un OS, c'est un émulateur physique ?
    - [^] # Re: et sinon ?
      
      Posté par Renault (site web personnel) le 09 janvier 2014 à 18:20. Évalué à 1.
      
      Un émulateur logiciel c'est exactement ça, un processeur définit logiciellement (et donc virtuel) qui tourne sur un OS existant.
- [^] # Re: et sinon ?
  
  Posté par NeoX le 08 janvier 2014 à 22:10. Évalué à 2.
  
  bientot ;)
- [^] # Re: et sinon ?
  
  Posté par Zylabon le 08 janvier 2014 à 22:10. Évalué à 2.
  
  Les driver Linux existent (je sais même pas si yen a d'autres).
  
  Et il me semble qu'il y a un petit linux hyper modifié qui tourne dessus aussi. (pour faire les IO, l'ordonnancement… tout ça).
  
  Please do not feed the trolls
- [^] # Re: et sinon ?
  
  Posté par Marc (site web personnel) le 08 janvier 2014 à 22:14. Évalué à 6.
  
  http://www.kalray.eu/news-7/news/kalray-at-embedded-linux-conference-europe-2013-24-25-oct
# Dispo?

Posté par alpha_one_x86 (site web personnel) le 08 janvier 2014 à 22:09. Évalué à 2.

Quel sont les disponibilités? Compatible avec gcc et donc il peu y avoir un linux dessus? Car ARM ne me géne pas, (RPI, cubox-i), mais ça serai mieux si cette architecture serai accessible, si possible avec un port PCIe.

Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
- [^] # Re: Dispo?
  
  Posté par Xx+xX le 08 janvier 2014 à 23:24. Évalué à 3. Dernière modification le 08 janvier 2014 à 23:26.
  - le compilo est (basé sur) gcc
  - il y a du PCIe
  - pour porter Linux dessus, c'est en cours (cf le lien de la présentation de Marta au LinuxCON plus haut)
# Intelligence artificielle

Posté par Tonio (site web personnel) le 08 janvier 2014 à 22:22. Évalué à 1.

Bonsoir,

Es que ce type de CPU pourrait-être intéressant pour l'IA?

Il parait qu'il faut beaucoup de CPU/CORE?
Sur les KALRAY, on peut monter jusqu'à 1024 CORE, ce qui pourrait faire un bon système et pas trop gourmand?
- [^] # Re: Intelligence artificielle
  
  Posté par rewind (Mastodon) le 09 janvier 2014 à 00:02. Évalué à 10.
  
  Es que ce type de CPU pourrait-être intéressant pour l'IA?
  
  Ça dépend, est-ce que tu utilises le paradigme Evenja ?
  - [^] # Re: Intelligence artificielle
    
    Posté par Alex G. le 09 janvier 2014 à 10:03. Évalué à 6.
    
    Avec Evenja tu n'as même pas besoin de CPU, ce qui importe c'est le Quoi Où et Quand :-P
    - [^] # Re: Intelligence artificielle
      
      Posté par liberforce (site web personnel) le 09 janvier 2014 à 17:02. Évalué à 4.
      
      L'utilisation d'Evenja te garantit une partouze entre 1024 chats, ce n'est pas négligeable…
- [^] # Re: Intelligence artificielle
  
  Posté par Victor le 09 janvier 2014 à 11:42. Évalué à 5.
  
  Bah si on regarde du coté de tout ce qui est IA distribué, genre systèmes multi-agents, voire systèmes à acteurs, et bien je dirai que oui : on a des tonnes de trucs qui bossent en parallèle et se coordonne ensemble (sans pour autant partager trop d'info, i.e. pas vraiment d'info globalement accessible et passée à tous).
  
  Ça veut dire qu'on peut avoir 256 trucs qui s'exécutent vraiment en parallèle sans s'attendre trop les uns les autres.
  
  Je pense aussi à la prog fonctionnelle qui commence sérieusement à décoller en terme de parallélisation (voir par exemple tout les travaux chez Scala sur la parallélisation du traitement des collections de données, entre autres).
# je comprend pas tout

Posté par NeoX le 08 janvier 2014 à 22:30. Évalué à 4. Dernière modification le 08 janvier 2014 à 22:45.

http://www.kalray.eu/products/mppa-board/mppa-board-emb01/

ce serait une carte mere Kalray, avec une carte fille X86
du coup l'OS je le met ou ?
- [^] # Re: je comprend pas tout
  
  Posté par Xx+xX le 08 janvier 2014 à 23:13. Évalué à 1.
  
  Aujourd'hui, tu mets l'OS sur le x86.
- [^] # Re: je comprend pas tout
  
  Posté par hervé Couvelard le 09 janvier 2014 à 21:48. Évalué à -2.
  
  du coup l'OS je le met ou ?
  
  DTC ?
  
  désolé ~~~~~{}
# Correction

Posté par xcomcmdr le 08 janvier 2014 à 22:44. Évalué à 6.

Amiga s'écrit avec une majuscule.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
- [^] # Re: Correction
  
  Posté par ariasuni le 09 janvier 2014 à 00:13. Évalué à 10.
  C’est tout ce que tu as repéré? :p
  
  Bien sur
  
  À remplacer par «Bien sûr» car sûr → sûrement et sûr ≠ sur (3 fois dans la dépêche).
  
  Le marché est carrément mur.
  
  «Mur» est le nom commun, c’est «mûr» l’adjectif…
  
  Les processeurs sont maintenant multicœurs et multithreads […] un processeur multicores/multithreads […] les processeurs multicore classiques
  
  Ça serait bien de toujours utiliser multicœur ou multicore mais pas les deux. Et si on veut vraiment pinailler, on pourrait dire que threads peut se traduire par tâche, donc multithreads = multitâche.
  
  réduite d'un facteur x10
  
  Réduite d’un facteur 10
  
  Pour finir, ils auront des verres incassables de chez Afflelou ou tomberont toujours du bon côté
  
  Le point à la fin de la phrase.
  
  Ainsi que:
  - l’utilisation de - au lieu de — pour les césures;
  - l’auteur a écrit plusieurs fois virgule suivi de points de suspension, or on ne place pas de virgule avant ces derniers;
  - tout le long, l’auteur écrit «Watt» ou «watt», sans raison apparente,
  - les élément d’une liste se terminent par un point virgule (d’après Wikipédia), avec un point pour le dernier élement. Ici certaines phrases qui sont des éléments de listes ne comportent même pas de point à la fin pour terminer la phrase;
  - le même genre d’inconsistance avec «Flops/W», «Gflop/Watt», etc.
  (j’ai vraiment fait mon pinailleur là, mais quand je suis lancé… :P)
  
  Écrit en Bépo selon l’orthographe de 1990
  - [^] # Re: Correction
    
    Posté par ZeroHeure le 09 janvier 2014 à 11:46. Évalué à 2.
    
    Orthographe corrigé, merci!
    
    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
  - [^] # Re: Correction
    
    Posté par Nicolas Casanova le 09 janvier 2014 à 12:32. Évalué à 5.
```
le même genre d’inconsistance avec «Flops/W», «Gflop/Watt», etc.
```
    Incohérence, pas inconsistance qui est un anglicisme dans ce contexte. (À pinailleur, pinailleur et demi.)
    - [^] # Re: Correction
      
      Posté par Maclag le 09 janvier 2014 à 14:12. Évalué à 7.
      
      C'est exact.
      
      "Incohérence", c'est quand un élément va à l'encontre d'un autre.
      "Inconsistance", c'est comme la pâte brisée que j'ai faite ce midi… (oh ça va, hein! ça arrive à tout le monde d'avoir la main un peu lourde au moment de verser l'eau…)
- [^] # Re: Correction
  
  Posté par TheBreton le 10 janvier 2014 à 10:49. Évalué à 2.
  
  C'est un scandale que les Amstrad de l'époque (464,664 et 6128) ne soit pas évoqué alors qu'utilisant des Z80 aussi (il manque aussi les Alice, les C64 puis C128)
  des ordinausore très populaires en leur temps sic!
  - [^] # Re: Correction
    
    Posté par mordicusetcubitus le 10 janvier 2014 à 17:41. Évalué à 2.
    Oui, désolé pour ces petites fautes qui traînent notamment dans la notation des unités de mesures et la ponctuation.
    
    J'avais initialement écrit l'article avec Open Office.
    J'ai galéré pour le basculer en mode Wiki/REST pour Linux Fr : après plusieurs tentatives infructueuses j'ai finalement exporté en HTML et tout modifié avec emacs et les expressions régulières. Mais j'ai laissé quelques coquilles.
    
    J'ai relu l'article plus de 10 fois (vu sa longueur) pour éviter ces coquilles, mais à la fin je crois que je ne voyais plus rien.
    
    Pour l'amstrad 464/664/6128 et le commodore C64/164 c'est vrai que c'est un oubli impardonnable.
    
    D'autant plus que j'adorais le jeu Renegade sur Amstrad 664 ou tu pouvais attraper les boss par les épaules et leur …
    
    Voici donc pour combler ces lacunes:
    - Amstrad CPC
    - Commodore 64
    Ah ah ! Quand je regarde la vidéo de Renegade du lien ci-dessus, je me demande comment nous avons pu adorer ces jeux en regard de la qualité visuelle de ceux d'aujourd'hui !
    Mais c'était le bon temps !
    - [^] # Re: Correction
      
      Posté par Benoît Sibaud (site web personnel) le 10 janvier 2014 à 18:43. Évalué à 6.
      
      Ah ah ! Quand je regarde la vidéo de Renegade du lien ci-dessus, je me demande comment nous avons pu adorer ces jeux en regard de la qualité visuelle de ceux d'aujourd'hui !
      Mais c'était le bon temps !
      
      Avant c'était du bel ouvrage, du pixel taillé au burin et peint à la main par des petits artisans. Chaque son était produit les rares cloches disponibles produites par un forgeron du coin. Sans parler des lutins à l'intérieur qui devaient lire au fur et à mesure les cassettes et disquettes qui défilaient à des rythmes insoutenables. 4 pixels c'était un ennemi, 32 pixels une fresque, 128 pixels une panorama sur l'horizon. Les équipes c'étaient camaïeu de vert foncé contre camaïeu de vert clair sur Amstrad (sauf pour les riches qui avaient jusqu'à 16 couleurs, différentes en plus). Ah Gryzor (avec déjà des vues en fausse 3D), Discology (l'outil de copie qui ne veut pas se copier sauf si tu lui demandes gentiment), LMPTDVDLJQSTDS !
    - [^] # Re: Correction
      
      Posté par Antoine le 11 janvier 2014 à 00:14. Évalué à 2.
      
      Quand je regarde la vidéo de Renegade du lien ci-dessus, je me demande comment nous avons pu adorer ces jeux en regard de la qualité visuelle de ceux d'aujourd'hui !
      
      C'est un peu débile comme remarque, il y a d'excellents jeux indépendants aujourd'hui dont la "qualité visuelle" (sic) est assez rudimentaire. Exemple au hasard : http://thelettervsixtim.es/
# Et les compilateurs?

Posté par reno le 08 janvier 2014 à 22:54. Évalué à 7.

Les VLIW ce n'est pas nouveau, ils ont 2 gros problèmes:
- d'un processeur a l'autre, on perd la compatibilité binaire.
- les compilateurs fonctionnent bien que pour du code scientifique très régulier, pas pour du code "normal": c'est la raison principale pour laquelle l'Itanium (qui est une sorte de VLIW) s'est planté en beauté..

D'ailleur sur le sujet, certains réfléchissent beaucoup, cf l'architecture "Mill CPU" qui est un projet de VLIW, mais qui n'existe que sur le papier actuellement:
http://www.reddit.com/r/programming/search?q=mill+cpu&restrict_sr=on&sort=relevance&t=all
- [^] # Re: Et les compilateurs?
  
  Posté par Zylabon le 09 janvier 2014 à 01:24. Évalué à 1.
  - d'un processeur a l'autre, on perd la compatibilité binaire.
  Ça c'est un problème du logiciel privateur, pas libre.
  - les compilateurs fonctionnent bien que pour du code scientifique très régulier, pas pour du code "normal"
  Avec quel genre de code « normal » on a besoin de performances ?
  - c'est la raison principale pour laquelle l'Itanium (qui est une sorte de VLIW) s'est planté en beauté..
  L'autre hypothèse c'est que c'était la première génération compatible *86 à ne pas offrir de performance supérieure à la génération précédente (la faute à un simulateur plus lourd et une fréquence de travail plus basse). Encore un problème du logiciel privateur…
  
  Aujourd'hui, les processeurs sont obligés d'extraire le parallélisme entre les instructions, dynamiquement alors que ça pourrait mieux être fait de manière statique. Et que les transistors qui font ces calculs pourraient surement être utilisés plus utilement.
  
  Please do not feed the trolls
  - [^] # Re: Et les compilateurs?
    
    Posté par Nicolas Boulay (site web personnel) le 09 janvier 2014 à 09:57. Évalué à 3.
    
    "Ça c'est un problème du logiciel privateur, pas libre."
    
    Tu plaisantes ? Tu connais beaucoup de distribution linux qui supporte "plein" de version de cpu ?
    
    "Avec quel genre de code « normal » on a besoin de performances ?"
    
    compilateur, base de donné, serveur, interface graphique, navigateur internet….
    
    "Aujourd'hui, les processeurs sont obligés d'extraire le parallélisme entre les instructions, dynamiquement alors que ça pourrait mieux être fait de manière statique. "
    
    Le compilo d'Itanium prouve que c'est faux. De plus, pour avoir de bonnes perf, l'itanium a besoin d'un cache code énorme au contraire du x86.
    
    "La première sécurité est la liberté"
    - [^] # Re: Et les compilateurs?
      
      Posté par Zylabon le 09 janvier 2014 à 13:39. Évalué à 2.
      Tu plaisantes ? Tu connais beaucoup de distribution linux qui supporte "plein" de version de cpu ?
      
      Oui. cf http://distrowatch.com :
      
      Debian (armel, armhf, i386, ia64, mips, mipsel, powerpc, s390, s390x, sparc, x86_64)
      
      Fedora (armhfp, i686, powerpc, s390x, ppc64, x86_64)
      
      REHL (i386, ia64, powerpc, s390, s390x, x86_64)
      
      Gentoo (i486, i586, i686, x86_64, alpha, arm, hppa, mips, powerpc, ppc64, sparc64)
      
      Et accessoirement…
      
      FreeBSD (arm, armel, i386, ia64, mips, mipsel, sparc64, pc98, powerpc, powerpc64, ps3, x86_64, xbox)
      
      OpenBSD (alpha, x86_64, hppa, i386, m68k, powerpc, mips, sparc32, sparc64, vax)
      
      Parce que du code C correct est hyper portable. C'est facile à faire. La compatibilité binaire c'est un problème de logiciel privateur.
      
      "Avec quel genre de code « normal » on a besoin de performances ?"
      
      compilateur, base de donné, serveur, interface graphique, navigateur internet….
      
      On doit pas avoir la même définition de « besoin de performances », ni de « code « normal » ».
      - compilateur : des perfs pour quoi faire ?
      - base de donnée : c'est surtout une question d'architecture logicielle
      - serveur : idem
      - navigateur internet… le truc qui doit juste télécharger quelques kilos et les afficher ? S'il est lent c'est qu'il a un problème d'architecture logicielle. Un meilleur compilo n'y changerait pas grand chose. Et pour afficher les images, ce sont des algo « scientifiques hyper réguliers » super parallelisables.
      
      Le compilo d'Itanium prouve que c'est faux. De plus, pour avoir de bonnes perf, l'itanium a besoin d'un cache code énorme au contraire du x86.
      
      Le mauvais support d'une technologie qui s'est cassé la gueule ne prouve pas grand chose, à part que les devs ne sont pas stupide. Pour l'histoire du cache, ce n'est pas un argument, juste un fait. De plus, l'itanium à un nom qui commence par un i, contrairement à l'x86.
      
      Please do not feed the trolls
      - [^] # Re: Et les compilateurs?
        
        Posté par Nicolas Boulay (site web personnel) le 09 janvier 2014 à 14:35. Évalué à 1.
        
        "Parce que du code C correct est hyper portable. C'est facile à faire. La compatibilité binaire c'est un problème de logiciel privateur."
        
        Et tu crois franchement qu'une seul des ses distributions va décider de faire un port pour ton cpu tout beau tout neuf ?! Quand au C hyper portable, je rappelle qu'il peut y avoir des problèmes rien qu'entre les versions 32 et 64 bits sous x86.
        
        "- compilateur : des perfs pour quoi faire ?"
        
        Pour rien. Personne ne se plaind du temps de compilation de C++, et personne n'a créé go pour aider se coté là.
        
        "- navigateur internet… le truc qui doit juste télécharger quelques kilos et les afficher ? S'il est lent c'est qu'il a un problème d'architecture logicielle. Un meilleur compilo n'y changerait pas grand chose. Et pour afficher les images, ce sont des algo « scientifiques hyper réguliers » super parallelisables."
        
        Juste mdr. Regarde la taille du code source de Mozilla ! C'est plus gros que Linux.
        
        "Pour l'histoire du cache, ce n'est pas un argument, juste un fait."
        
        Tu n'as à alors rien compris au supposer avantage du vliw sur le superscalaire. Le but était de sauver du silicium pour mettre plus d'unité de calcul dans le même espace (ou budget de portes logiques). Si tu perds encore plus de place pour mettre du cache, c'est juste un gros failed.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Et les compilateurs?
        
        Posté par Zylabon le 09 janvier 2014 à 23:22. Évalué à 2.
        
        Et tu crois franchement qu'une seul des ses distributions va décider de faire un port pour ton cpu tout beau tout neuf ?! Quand au C hyper portable, je rappelle qu'il peut y avoir des problèmes rien qu'entre les versions 32 et 64 bits sous x86.
        
        Mon CPU ? De quoi tu parle ? Je ne comprend pas cette agressivité (à moins que ce ne soit du mépris ?).
        Si demain un intel ou AMD, ou nvidia sort un CPU patator, s'il en vend… alors oui, bien sûr que les distro feront l'effort. La boite en question payera pour ça même, parce que personne n’achète une machine sur laquelle ne tourne aucun système d'exploitation.
        
        Quand au C hyper portable
        
        Une petite aide à la lecture :
        
        Parce que du code C correct est hyper portable
        
        Je ne devrais pas m'abaisser à répondre… Citer l'autre aussi grossièrement c'est grotesque.
        
        Tu n'as à alors rien compris au supposé avantage du vliw sur le superscalaire. Le but était de sauver du silicium pour mettre plus d'unité de calcul dans le même espace (ou budget de portes logiques). Si tu perds encore plus de place pour mettre du cache, c'est juste un gros failed.
        
        Accuser l'autre de ne rien comprendre n'est pas un argument. Je suis juste pas convaincu par les arguments qualitatif. « Plus de ça, moins de ci, ergo : big fail » n'est pas un raisonnement valide.
        
        Considérant une toute nouvelle architecture, il faut la considérer dans son ensemble. Tu peux pas juste dire « celle là a besoin de plus de cache, ça va à l'encontre du but recherché, donc c'est de la merde ». Il faut aussi considérer le fait certaines parties seront plus simple et permettrons d'économiser, que l’accélération ne se fera pas au même endroit. (des registres à gogo avec avec les instructions qui arrivent 15 par 15 ça comptent pas ?). Non… j'dois être trop con.
        
        À bon entendeur, et je tacherais de ne plus trahir ma signature à l'avenir.
        
        Please do not feed the trolls
        
        [^] # Re: Et les compilateurs?
        
        Posté par Nicolas Boulay (site web personnel) le 09 janvier 2014 à 23:50. Évalué à 3.
        
        Les vliw ne sont pas nouveaux. L'itanium n'est pas nouveau, ni le dsp de TI, ni les gpus. Les gpu était des liv de 4 instructions qui sont passé à 2 voir moins.
        
        Un itanium coutait 12k€ pour battre un x86 en vitesse pure, le prix est évidement en rapport avec la taille de la puce.
        
        "Si demain un intel ou AMD, ou nvidia sort un CPU patator, s'il en vend… alors oui, bien sûr que les distro feront l'effort."
        
        Les versions autre que x86 sont limités.
        
        "Considérant une toute nouvelle architecture, il faut la considérer dans son ensemble."
        
        C'est pour ça que je parle des caches.
        
        "(des registres à gogo avec avec les instructions qui arrivent 15 par 15 ça comptent pas ?)."
        
        L'ipc moyen d'un code est de 3. Le nombre de load par instruction est pas loin de 1 pour 5 instructions, un load, cela peut prendre 100 cycles. Donc, un pipeline fixe de 15 instructions sera vide la plus part du temps.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Et les compilateurs?
        
        Posté par Sytoka Modon (site web personnel) le 10 janvier 2014 à 08:10. Évalué à 3.
        
        Je suis d'accord, l'Itanium s'est planté car trop cher et ils n'ont jamais sortis de 'PC' de bureau avec. Il en a été de même quelques années avant avec l'Alpha qui a eu des PC compatible mais pas longtemps et pas à un prix concurrentiel. Pas facile de faire un tarif face à la très très grande série qu'est le x86 !
        
        On le voit avec ARM qui y arrive lentement, non pas en jouant sur les PC, mais via les téléphones puis les tablettes ou la problématique est la consommation et ou les calculs en double précision ne sont pas important.
        
        [^] # Re: Et les compilateurs?
        
        Posté par groumly le 12 janvier 2014 à 07:31. Évalué à -2.
        
        À bon entendeur, et je tacherais de ne plus trahir ma signature à l'avenir.
        
        T'es au regime?
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Et les compilateurs?
        
        Posté par briaeros007 le 12 janvier 2014 à 10:29. Évalué à 3.
        
        je rappelle qu'il peut y avoir des problèmes rien qu'entre les versions 32 et 64 bits sous x86.
        
        LEs changements de tailles (d'adressage et de mots) est justement ce à quoi les programmes C sont les plus sensibles (avec les byte order, et les systèmes de protection/gestion de la mémoire), dut à leur coté très proche de la mémoire.
        
        Pour rien. Personne ne se plaind du temps de compilation de C++, et personne n'a créé go pour aider se coté là.
        
        Go je n'ai jamais testé. Mais le C n'est pas le C++
        Et il ya une différence entre une distrib généraliste où on est franchement dans le paradigme "compile once, run everytime", que dans du code plus proche des développeur où on est dans du "compile once, run once".
        Si on voulait jouer, on pourrait même parler d'optimisations avec des compilations qui s'adaptent au fonctionnement du programme ^{^{^{^}}}
        
        Juste mdr. Regarde la taille du code source de Mozilla ! C'est plus gros que Linux.
        
        En même temps il fait le café, (avec décodage vidéo, ….).
        
        Regarde le code source de lynx, c'est beaucoup plus petit ^{^}
        
        Tant je suis d'accord qu'un browser moderne ne fait pas qu'un arbre dom et afficher des images, tant il faut reconnaitre que les browsers actuels ont un peu le syndrome machine à gaz.
        Mon firefox là prend 780 Mo. La somme des pages ouverte en même temps, images comprise, ne doit pas dépasse 40Mo (et encore je suis gentil).
      - [^] # Re: Et les compilateurs?
        
        Posté par dinomasque le 09 janvier 2014 à 14:58. Évalué à 7.
        
        Parce que du code C correct est hyper portable. C'est facile à faire.
        
        LOL.
        
        Les hackers des projets sus-cités qui travaillent dur pour assurer un bon fonctionnement de leur OS sur toutes ces architectures apprécieront.
        
        Par ailleurs, en quoi compiler du code C "correct" libre est plus facile que compiler du code C "correct" pas libre ? C'est comme avec le bon chasseur et le mauvais chasseur ? Quid des Microsoft, Apple et autres qui y arrivent pourtant très bien avec leurs OS (au moins dans leurs labos) ?
        
        BeOS le faisait il y a 20 ans !
        
        [^] # Re: Et les compilateurs?
        
        Posté par Zylabon le 09 janvier 2014 à 23:04. Évalué à 0.
        
        Petite aide à la lecture :
        
        Tu plaisantes ? Tu connais beaucoup de distribution linux qui supporte "plein" de version de cpu ?
        
        [plein de distro linux qui supportent plein de versions de cpu]
        Parce que du code C correct est hyper portable. C'est facile à faire. La compatibilité binaire c'est un problème de logiciel privateur.
        
        Please do not feed the trolls
      - [^] # Re: Et les compilateurs?
        
        Posté par arnaudus le 09 janvier 2014 à 16:41. Évalué à 4.
        
        "Avec quel genre de code « normal » on a besoin de performances ?"
        
        Avec quel genre de code a-t-on besoin de plus de 640 kb de RAM?
        
        Sérieusement, avec à peu près tout, mais le plus gros argument, c'est l'utilisation de langages de haut-niveau. Un jour le C (pourquoi pas tous les langages compilés même, on est presque vendredi) deviendra probablement ce qu'est l'assembleur aujourd'hui. Je ne vois pas l'intérêt de coder un navigateur ou une suite bureautique dans un langage qui permet des fuites de mémoire ou des segmentation fault; et par ailleurs les navigateurs eux-mêmes deviennent des compilateurs de JavaScript.
        
        D'une manière générale, on peut aussi discuter du fait que ma micro-optimisation est nuisible (temps de développement passé à optimiser, plus la perte de temps pour gérer la perte de lisibilité et d'évolutivité du code). L'argument "il existe un moyen logiciel d'améliorer les performances" est aussi souvent en opposition avec la portabilité et l'évolutivité, qui sont des propriétés importantes des logiciels.
        
        [^] # Re: Et les compilateurs?
        
        Posté par alpha_one_x86 (site web personnel) le 09 janvier 2014 à 17:08. Évalué à 1.
        
        Pour moi, llvm est mieux optimisé, avant de parlé de passé sur du hardware optimisé. Par contre, oui, le compilateur ont besoin de performance, même si pas utilisé par l'utilisateur lamba. Pour que le dev n'attende pas sa machine, et que des optimisations plus lourdes soit activable.
        
        Coté navigateur, avec une veille machine tout est réactif, alors pourquoi parler d'optimisation hardware? Il faut que le rendu soit généré en 0.01ms au lieux de 1ms?
        
        Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
        
        [^] # Re: Et les compilateurs?
        
        Posté par arnaudus le 09 janvier 2014 à 18:02. Évalué à 3.
        
        Coté navigateur, avec une veille machine tout est réactif
        
        Sur du HTML bête et méchant, peut-être, mais quid des web-applis où le navigateur devient un compilateur/interpréteur?
        
        [^] # Re: Et les compilateurs?
        
        Posté par alpha_one_x86 (site web personnel) le 09 janvier 2014 à 18:48. Évalué à 1.
        
        As tu un exemple, car facebook, github, … et autre site avec beaucoup de javascript (sans javascript pourri), mon navigateur ne ram pas sur ma petit machine à 500MHz, ni sur mon vieux p3 à 500MHz…
        
        Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
        
        [^] # Re: Et les compilateurs?
        
        Posté par Kerro le 09 janvier 2014 à 19:38. Évalué à 5.
        
        Your mileage may vary.
        
        Le mien de navigateur, il freeze plusieurs secondes lorsque j'ouvre 4 onglets à la suite. Parfois même un seul onglet.
        2 cœurs, 8 Gio de mémoire (dont 3 Gio libres), pas de swap, Javascript désactivé avec NoScript.
        
        Même chose sur la machine d'à côté qui est sous Windows (même navigateur : Firefox à jour).
        
        [^] # Re: Et les compilateurs?
        
        Posté par alpha_one_x86 (site web personnel) le 09 janvier 2014 à 19:51. Évalué à 1.
        
        Moi chromium (donc chrome), avec des bon cflags. Mais si chez moi ça marche, c'est que le problème viens du coté logiciel, pas matériel.
        
        Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
        
        [^] # Re: Et les compilateurs?
        
        Posté par briaeros007 le 12 janvier 2014 à 10:34. Évalué à 6.
        
        même si on est revenu du temps du "tout flash"; il faut reconnaitre qu'un certain nombre de pages ont pris de l'embonpoint , tant au niveau taille, qu'au niveau complexité (css, javascript à tout vas, ajax récurrent)
        
        honnêtement 500 Mhz je ne sais pas comment tu fais. Moi avec mon 800 Mhz, avant que je change il y a quelques années, il commençait à souffrir quand même.
    - [^] # Re: Et les compilateurs?
      
      Posté par lasher le 09 janvier 2014 à 21:38. Évalué à 1.
      
      Hum, je suis d'accord avec tes réponses, mais je trouve le « problème » attribué aux VLIW un peu bizarre. Je veux dire, tant que le codage des instructions est le même (en gros, tant que ton VLIW prend le même nombre d'instructions dans une instruction longue), je ne vois pas en quoi il y a un problème de compatibilité binaire. Il y a eu au moins 3 versions de l'Itanium 2, et toutes ont été compatibles au niveau binaire.
      - [^] # Re: Et les compilateurs?
        
        Posté par reno le 09 janvier 2014 à 22:44. Évalué à 4.
        
        Les VLIWs classiques avaient un jeu d'instruction qui montrait directement le matériel pour optimiser l'utilisation du matériel: changement de techno == plus d'unité fonctionnelle --> changement de jeu d'instruction..
        
        L'Itanium n'est pas un VLIW classique de ce point de vue, il y a en effet la compatibilité binaire d'une version à l'autre..
  - [^] # Re: Et les compilateurs?
    
    Posté par dinomasque le 09 janvier 2014 à 12:17. Évalué à 4.
    
    Aujourd'hui, les processeurs sont obligés d'extraire le parallélisme entre les instructions, dynamiquement alors que ça pourrait mieux être fait de manière statique.
    
    Va dire ça à Sony et Microsoft qui ont remplacé leurs processeurs "in order" (c'est à dire nécessitant un ordonnancement statique des instructions à la compilation) par des processeurs "out of order" (c'est à dire embarquant l'usine à gaz permettant de re-distribuer dynamiquement les instructions à la volée) dans leurs consoles respectives.
    
    BeOS le faisait il y a 20 ans !
    - [^] # Re: Et les compilateurs?
      
      Posté par Zylabon le 09 janvier 2014 à 13:52. Évalué à 3. Dernière modification le 09 janvier 2014 à 13:53.
      
      Je vais préciser… Aujourd'hui les amd64 extraient tout le parallélisme entre les instructions à la volée (même si le compilo aide en séparant ce qui peut l'être).
      
      Une grande partie de ce boulot pourrait être fait en statique, une fois pour toute. La logique c'est « je ne sais pas quelles questions les étudiants vont me poser pendant le cours… donc je vais y aller les mains dans les poches ». Il s'agit juste de faire la part des choses entre ce qui peut être fait statiquement et le reste. Parce que faire dynamiquement un truc qui peut l'être avant, c'est stupide.
      
      Après, il y a aussi le problème portabilité des performances entre les processeurs compatibles. Pour ça il faut juste recompiler ce qui a besoin de l'être.
      
      Please do not feed the trolls
      - [^] # Re: Et les compilateurs?
        
        Posté par Nicolas Boulay (site web personnel) le 09 janvier 2014 à 14:37. Évalué à 4.
        
        "Une grande partie de ce boulot pourrait être fait en statique, une fois pour toute."
        
        C'est juste faux, complètement faux. Une grosse partie de l'information est situé dans les données, dynamiquement donc.
        
        "Parce que faire dynamiquement un truc qui peut l'être avant, c'est stupide."
        
        Tu crois que les compilo optimisant ne font rien ?!
        
        "La première sécurité est la liberté"
        
        [^] # Re: Et les compilateurs?
        
        Posté par lasher le 09 janvier 2014 à 22:09. Évalué à 8.
        
        Pour aller dans ton sens : je l'ai déjà dit ailleurs, mais les deux « gros » compilateurs pour Itanium 2 sont icc et gcc. Le premier a mis deux ou trois générations avant de générer du code ultra optimisé (à partir d'icc v9.1 en gros, le code devient vraiment bon, avec une bonne exploitation des techniques de pipeline logiciel, la if-conversion, etc.). Le deuxième (gcc donc) génère du code entre deux et dix fois plus lent qu'icc. Pourtant, le modèle machine est bien mieux décrit pour IA64 que pour x64 ou ia32 (c'est nécessaire, vu que le compilateur doit générer tout le code statiquement).
        
        Et en fait, si on regarde les techniques proposées pour accélérer le code sur VLIW, on trouve tout un tas de « contournements » de l'aspect statique pour la génération de code. On peut citer par exemple les techniques de « trace scheduling » (trop complexe à implémenter la plupart du temps) et surtout de « superblocks » et « hyperblocks ». L'idée derrière tout ça est de faire de la compilation guidée par profilage (profile guided optimization) :
        
        On compile une première version du binaire et on l'exécute sur un petit jeu d'entrées représentatives.
        
        Après avoir instrumenté l'exécution de ce mini-run, on recompile le code en y ajoutant des annotations.
        
        Durant la compilation, on va générer plusieurs versions du « chemin chaud » (hou, je préfère la V.O. : « hot path »), ou si on préfère un autre terme, du « chemin critique » en termes de temps passé à calculer. L'idée est de profiter des capacités de spéculation sur les données et sur le contrôle de l'Itanium pour statiquement prédire « prise » l'une ou l'autre branche d'un if/else. La plupart du temps, si le code n'est pas trop irrégulier niveau contrôle, la spéculation sera une chose positive. Pour les rares cas où ça ne l'est pas, on doit rebrancher sur le code original, et « rejouer » toute la partie de code qui avait été spéculée. Évidemment, si on ne se trompe que de temps en temps, le surcoût est négligeable. Si on a mal effectué le profilage, ou si le code est trop irrégulier (ce qui est le cas des codes type compression de donnée, dont le comportement dépend fortement des entrées par exemple), cette optimisation va ruiner les performances.
        
        La techniques des hyperblocks est similaire à celle des superblocks, mais rajoute en plus la if-conversion (et là, je renvoie à un truc que j'avais écrit cet été en promettant une suite pour « bientôt » — haha, la bonne blague).
        
        Bref, bien qu'il existe tout un tas de techniques de compilations pour statiquement utiliser au maximum les unités fonctionnelles d'un processeur (VLIW ou pas), ces dernières ont toutes des désavantages liés au fait qu'il faut faire du profilage de code sur tout un tas d'entrées différentes pour avoir une optimisation qui marche « au mieux » dans le cas moyen. Les gens de Firefox (ou Chrome, ou…) peuvent le faire en partie grâce aux informations remontées par les PC d'utilisateurs qui indiquent quel genre de pages ils visitent, etc., ce qui fait que les fermes de compilation peuvent prendre en compte ce genre de trucs, et effectuer de la PGO (profile-guided optimization). À moins de faire de même pour tous les softs utilisés (avec les risques liés à la vie privée que cela comporte, sans parler du flux constant d'information qui ira vers le net et qui accompagnera toute exécution de n'importe quel soft — y compris ls ? ;-) ), ça risque d'être un peu compliqué.
        
        [^] # Re: Et les compilateurs?
        
        Posté par briaeros007 le 12 janvier 2014 à 10:39. Évalué à 3.
        
        oui et non.
        
        Tous les logiciels n'ont pas besoin d'être optimisées sur tous leur chemins critique.
        Un compilateur vidéo n'a pas besoin d'être optimisé au niveau du décodage du format (ou si peu) et donc de tester tous les options possible et imaginable de format avec ratio.
        
        Il a besoin d'être optimisé sur le fonctionnement de l'encodeur. Et les options principales d'encodage (et des sources de vidéos suffisament variées pour être efficace partout) ça se trouve facilement.
        
        Il faut amha différencier l'aspect "coller à exactement ce que fait l'utilisateur", "utiliser des choses statistiquement représentatives", et "optimiser les parties importantes à optimiser".
      - [^] # Re: Et les compilateurs?
        
        Posté par reno le 09 janvier 2014 à 15:59. Évalué à 3.
        
        Une grande partie de ce boulot pourrait être fait en statique, une fois pour toute.
        
        Pas d'accord: un load ça peut être assez rapide (cache L1) ou très lent (RAM), et vu qu'il y a beaucoup de load, tu as au contraire une grande partie du boulot qui a une durée très imprévisible où les algos statique ont des problèmes..
      - [^] # Re: Et les compilateurs?
        
        Posté par khivapia le 09 janvier 2014 à 16:48. Évalué à 2.
        
        La réalité est plus complexe : avec le flag adapté, le compilateur s'adapte au décodeur du processeur de sorte qu'il puisse réordonner les instructions au mieux. Réciproquement, la conception du CPU est faite de sorte à équilibrer les différentes parties (entre décodage et réordonnancement, unités d'exécution, gestion des cache et de la mémoire, etc.), du coup le décodage n'est pas nécessairement le plus gourmand en matériel.
        
        Enfin réordonner les instructions au niveau hardware est de toutes façons nécessaire puisque les processeurs modernes ont maintenant plusieurs unités d'exécution au sein d'un même cœur.
        
        [^] # Re: Et les compilateurs?
        
        Posté par Nicolas Boulay (site web personnel) le 09 janvier 2014 à 17:12. Évalué à 2.
        
        "la conception du CPU est faite de sorte à équilibrer les différentes parties"
        
        Je ne sais pas si tu bosses dans le secteur (voir carrément pour ARM à Sophia), mais je ne comprends pas trop pourquoi, les concepteurs de CPU essayent seulement d'accélérer les codes existant de façon homogènes (sauf pour AES).
        
        On sait que peu de taches nécessitent vraiment de la puissance de calcul brute (crypto, compression, iDCT, 3D…). Un core dédié impose un driver, et une latence de communication, qu'une instruction spécialisée n'a pas. On devrait voir fleurir des trucs pour la compression et tout ce qui est lent. Mais cela reste très classique. La PS4 a fait un choix radicale : moins de cache interne, contre une bande passante mémoire de folie. Cela ne serait pas une possibilité ?
        
        On sait que la bande passante mémoire est limité, donc une unité de calcul qui éviterait des aller/retour serait assez précieuse.
        
        Sais-tu pourquoi la conception de cpu ARM reste si classique ? (peu d'instructions spécialisés, pas d'intégration du contrôleur mémoire dans le cpu, pas de multithread "massif" genre Buldozer AMD qui est presque la fusion de 2 cpus, ce qui donne beaucoup d'unité de calcul (théorique) à une application monothread).
        
        "La première sécurité est la liberté"
        
        [^] # Re: Et les compilateurs?
        
        Posté par khivapia le 10 janvier 2014 à 14:51. Évalué à 4.
        
        Euh non je ne travaille pas dans le secteur des CPU, mes connaissances dans le domaine viennent surtout des manuels d'optimisation d'Ulrich Drepper et d'Agner Fog et du suivi de l'architecture des CPU x86 pour l'optimisation.
        
        De ce que j'en vois, pour le HPC selon les calculs il y en a qui sont plutôt intensifs en calcul, d'autre en accès mémoire.
        
        Pour ceux qui sont intensifs en calculs, il est raisonnable d'équilibrer les différentes étapes (schématiquement, récupération des instructions, décodage, exécution (dans différentes unités) et utilisation des résultats).
        
        Pour ceux qui sont intensifs en mémoire, outre un peu de logique (comme le write-combining, éventuellement accessible par des instructions spécialisées pour les CPU) l'amélioration a essentiellement consisté à intégrer le contrôleur mémoire au sein du CPU, ce qui a occasionné une réduction des latences vers la mémoire (fréquence supérieure, proximité physique avec les cœurs) et une meilleure gestion des systèmes multi-sockets (plusieurs contrôleurs mémoire largement indépendants, chaque socket a son accès à sa mémoire).
        
        Pour l'amélioration des débits mémoire, il n'y a pas de grande révolution : amélioration de la fréquence de la mémoire, ou des générations qui doublent la quantité de données transmises par cycle d'horloge (largeur de bus notamment), au prix d'une augmentation de la latence en cycles), améliorations sur les cache du CPU.
        J'ai vu tourner certains codes pour CPU (pourtant bien chiadés) dont la performance était exactement proportionnelle à la fréquence mémoire, à CPU fixé, parce qu'ils dépendaient purement de la latence. Pour ces codes, la mémoire graphique serait mauvaise vu qu'elle a des timings assez élevés (bien qu'en débit mémoire elle puisse monter plus haut que la DDR). Dans une carte graphique, les latences mémoires sont moins importantes que pour un CPU vu que comme me l'a répondu Jérôme Glisse, on les masque avec du multithreading (ce qui est possible car un GPU fait beaucoup de calculs similaires)
        https://linuxfr.org/news/kalray-un-processeur-massivement-parallele-tres-impressionnant-qu-il-est-loin-le-temps-de-mon-zx81#comment-1511777
        
        Dans tous les cas, pour le code qui sera finalement exécuté et du point de vue du fondeur de CPU "généraliste", un déséquilibre entre les différentes unités d'exécution du CPU signifiera soit des performances moindres pour certains types de calculs purs, soit un investissement inutile dans l'optimisation d'une partie du CPU.
        
        Donc la PS4 semble idéale pour des jeux (traitement des textures il me semble) ou d'autres applications gourmandes en bande passante mémoire, mais serait mauvais pour un code qui souffrirait d'une mauvaise latence mémoire (on trouve des benchmarks qui montrent que la GDDR5 a une latence 8 fois pire que la DDR3 par exemple).
        
        Concernant ARM, j'imagine sans savoir qu'ils veulent rester aussi RISC que possible (en ajoutant des instructions SIMD cela dit) afin de diminuer les coûts de conception et le poids de l'histoire (support des vieilles instructions). Il me semble qu'ils tirent pas mal parti du fait que tout est intégré dans une seule puce. Mais de même que le CPU Jaguar de la PS4 est suffisant pour des applications de jeu mais n'est pas un processeur puissant pour le calcul pur, de même la cible de marché des ARM consiste en des applications où la capacité de calcul requise est faible (mais l'efficacité importante).
        Toutefois, il est possible que la simplicité des cœurs ARM facilite le regroupement de plusieurs cœurs sur une puce pour produire des processeurs hautes performances. Enfin j'imagine (complètement :-) que le développement des CPU x86, essentiellement par Intel, s'est fait plus dans l'optique "j'ai une base de code existante (Windows & applications), que doit-on améliorer dans le CPU pour le faire tourner plus vite ?" et un peu "à l'avenir, utilisez ces instructions spécifiques pour ces cas particuliers" (genre la vectorisation). ARM, d'un autre côté, c'est plutôt "tenez, voici un nouveau processeur, recompilez vos OS pour".
        
        [^] # Re: Et les compilateurs?
        
        Posté par Nicolas Boulay (site web personnel) le 10 janvier 2014 à 16:38. Évalué à 3.
        
        "Dans tous les cas, pour le code qui sera finalement exécuté et du point de vue du fondeur de CPU "généraliste", un déséquilibre entre les différentes unités d'exécution du CPU signifiera soit des performances moindres pour certains types de calculs purs, soit un investissement inutile dans l'optimisation d'une partie du CPU."
        
        Si on reste sur ARM, une instruction "zip" serait utile pour tous les navigateurs gérant mod_gzip, cela doit représenter du monde. Une iDCT permettrait d'ouvrir des JPEG ultra-rapidement (sans utiliser de bloc externe, c'est utiliser tout le temps avec la photo et le navigateur), etc…
        
        "La première sécurité est la liberté"
        
        [^] # Re: Et les compilateurs?
        
        Posté par briaeros007 le 12 janvier 2014 à 10:46. Évalué à 2.
        
        pour l'iDCT, ce n'est pas aussi utilisé dans l'encodage vidéo ?
        Si oui, je pense qu'il doit déjà y avoir des instructions dédié.
        
        Le problème des instructions dédiés, c'est qu'il faut coder pour. Soit le compilo est capable de le gérer, soit le dev de la lib/logiciel doit le gérer.
        
        [^] # Re: Et les compilateurs?
        
        Posté par Nicolas Boulay (site web personnel) le 12 janvier 2014 à 21:35. Évalué à 2.
        
        "Le problème des instructions dédiés, c'est qu'il faut coder pour. Soit le compilo est capable de le gérer, soit le dev de la lib/logiciel doit le gérer."
        
        Oui, mais c'est bien plus facile qu'un bloc externe qui demande un drivers en plus.
        
        "La première sécurité est la liberté"
  - [^] # Re: Et les compilateurs?
    
    Posté par oinkoink_daotter le 09 janvier 2014 à 23:05. Évalué à 3.
    c'est la raison principale pour laquelle l'Itanium (qui est une sorte de VLIW) s'est planté en beauté..
    
    L'autre hypothèse c'est que c'était la première génération compatible *86 à ne pas offrir de performance supérieure à la génération précédente (la faute à un simulateur plus lourd et une fréquence de travail plus basse). Encore un problème du logiciel privateur…
    Euh, l'itanium n'est pas compatible x86. Et puisqu'on parle de hardware, j'ai du mal à comprendre pourquoi tu parles de simulateur et de logiciel propriétaire ?
    - [^] # Re: Et les compilateurs?
      
      Posté par Zylabon le 09 janvier 2014 à 23:36. Évalué à 2.
      
      Méa culpa, je pensais qu'il l'était. Ça explique encore mieux pourquoi c'est plus lent avec le code x86.
      
      On parlait du fait qu'ils s'étaient cassé la gueule avec l'itanum, c'est pas qu'un problème hardware, mais aussi économique. Une partie de l'explication réside dans le fait que les industriels qui sont coincés sur x86 à cause logiciel privateur n'ont pas eu intérêt à passer à l'itanium car il aurait ralenti leur logiciels. Contrairement aux nouvelles générations x86 et amd64.
      
      Please do not feed the trolls
    - [^] # Re: Et les compilateurs?
      
      Posté par lasher le 10 janvier 2014 à 00:29. Évalué à 3.
      
      L'Itanium 1 (Merced) était compatible x86. Il y avait une couche d'émulation (très lente).
# NSA

Posté par ribwund le 09 janvier 2014 à 00:48. Évalué à 7.

Et l'utilisation qu'il faut mentionner. C'est l'analyse de flux multi Gb/s en temps réel. C'est l'architecture rêvé et je suis sur que la DCRI est content de sa solution made in France ;-)

http://www.kalray.eu/solutions/data-networking/ (dpi)

(Et on sait bien que certaines branches du cea sont dans la surveillance/antiterrorisme)
# Mouais

Posté par cedric le 09 janvier 2014 à 03:07. Évalué à 6.

Tous les ordinateurs auront donc au moins une carte SIM intégrée avec le support 4G et du coup la fibre optique se généralisera pour tenter de concurrencer la 4G. Nostradamus a parlé.

Hum, euh, hum, c'est bizarre, je dois vivre dans le futur. Ici tout le monde a la fibre et la 4G. Tu peux trouver du wifi gratuit a peu pres partout, meme les bus on une borne Wifi (Et aussi des TV avec de la pub entre deux arrets). Par contre, on fait plutot du tethering, vu qu'on a 5Go de limite mensuel sur nos forfaits 4G. Une fois les update automatique d'Android desactive, il y a de la marge pour consommer de la bande passante sur une seule SIM.

Ah, oui, je ne suis pas en France, ni dans le futur, mais juste en Coree !

Sinon j'ai du mal a voir comment pourront etre utiliser ce genre de CPU sur une utilisation de courante par tout le monde. La plus grosse contrainte sur la majeur partie des taches que l'on fait tous les jours, a part pour la cryptographie et la decompression video, c'est la bande passante memoire. Et meme si tu utilises de la compression a la volee, tu ne vas pas gagner tant que ca, sans compter que ca complexifie ton code pas mal. Pour du rendu 2D, la plus part des taches (a part le blend avec du smooth scaling) sont capable de saturer un unique core et la 3D est plus facilement gere par un GPU. On experimente actuellement la decompression RLE de glyph pour ameliorer les performances du rendu texte en software, et ca marche, mais un coeur unique est encore suffisant pour saturer la bande passante memoire. Et ca, c'est avec des infrastructure qui se parallelise bien.

Paralleliser le rendu et la manipulation d'une page web, sans augmenter les besoins de bande passante memoire, c'est un joli challenge. Je me demande comment Servo/Rust va s'en sortir de ce cote la. Mais pour le reste, si tu arrives a utiliser en parallele efficacement plus de 4 cores, je dis chapeau bas. Apres il y a probablement une possibilite, si tu arrives a faire tourner 4 coeurs a moins d'un tiers de la frequence d'un seul pour le meme resultat, peut etre que tu consommeras moins d'energie (du fait que la consomation est une loi en puissance cubique de la frequence). Mais pour l'instant aucun toolkit n'est capable de mettre en avant une tel infrastructure et on ne sait pas encore si au final, le cout de la parallelisation en logiciel (lock, queue, allocation memoire …) ne va pas augmenter la consomation d'energie quand on commence a utiliser plein de coeur. Et puis aussi, combien de coeur peut reussir a utiliser une application ? 2 sans souci, 4 probablement, 8 ce sera deja un challenge… alors 256 ! Donc ce n'est probablement pas une solution pour tout le monde.
- [^] # Re: Mouais
  
  Posté par Arthur Geek (site web personnel) le 09 janvier 2014 à 08:51. Évalué à 10.
  
  Et aussi des TV avec de la pub entre deux arrets
  
  Rien que pour ça je n'ai pas envie de te rejoindre dans le futur.
  
  Prochainement, je vous proposerai peut-être un commentaire constructif.
  - [^] # Re: Mouais
    
    Posté par rogo le 09 janvier 2014 à 10:49. Évalué à 3.
    
    Ce futur-là, on patauge déjà dedans. À Bruxelles, il y a deux ans, les panneaux publicitaires étaient animés et sonores (jusqu'à minuit). J'imagine qu'ils sévissent encore aujourd'hui. En France, les écrans pour films de pub se multiplient dans les grandes villes. D'ici peu, je parie que les écrans des trams lyonnais passeront autant de pub que les bus de Séoul.
- [^] # Re: Mouais
  
  Posté par Nicolas Boulay (site web personnel) le 09 janvier 2014 à 10:06. Évalué à 2.
  
  "Apres il y a probablement une possibilite, si tu arrives a faire tourner 4 coeurs a moins d'un tiers de la frequence d'un seul pour le meme resultat, peut etre que tu consommeras moins d'energie (du fait que la consomation est une loi en puissance cubique de la frequence)."
  
  Si tu baisses la fréquence, tu augmentes le temps pour une tache, alors tu peux baisser l'énergie par instruction pour le cpu, mais c'est rarement le cas pour le reste de la puce (cache et contrôleur mémoire). Ainsi une tache souvent plus vite faite à fond, qu'avec une fréquence de moitier. J'ai même lu une étude, ou il baissait la fréquence cpu ou celle du bus mémoire en fonction de la charge qui était cpu bound ou memory bound, il gagnait 10% de consommation.
  
  "Je me demande comment Servo/Rust va s'en sortir de ce cote la."
  
  Le plus simple de mon point de vue est de fournir un Mapreduce multicore efficace. Dans un langage fonctionnelle, on utilise tout les temps les map et fold, c'est donc un usage naturel. Le plus complexe sera de tenir compte de l'organisation mémoire des données pour éviter tout les problèmes de faux partage et de cohérence de cache.
  
  "La première sécurité est la liberté"
  - [^] # Re: Mouais
    
    Posté par cedric le 10 janvier 2014 à 02:52. Évalué à 5.
    
    Si tu baisses la fréquence, tu augmentes le temps pour une tache,
    
    Uniquement si tu as un seul coeur et que ta tache n'est pas divisible sur plusieurs coeurs !
    
    J'ai même lu une étude, ou il baissait la fréquence cpu ou celle du bus mémoire en fonction de la charge qui était cpu bound ou memory bound, il gagnait 10% de consommation.
    
    Etude mono-coeur probablement. Mais bon, il faut voir que le noyau et les applications ne communiquent aussi pas assez sur le sujet pour prendre une bonne decision. Si tu as des threads qui vont etre CPU bound, faut reveiller toutes tes cores le plus vite possible (Pas de warmup comme avec l'ordonnanceur classique de linux). Puis tu reajustes la frequence a la baisse en fonction de ton package de temperature et de l'utilisation reelle du CPU.
    
    Par contre, si tu as des threads IO bound, tu te reveilles tranquille avec un warmup. Meme avec la frequence la plus basse, tu vas avoir de tres bonne perfs (energie et temps pour le resultat) et tu augmentes progressivement jusqu'a ce que cela ne serve a rien. C'est la logique qui est globalement utilise par le noyau actuellement.
    
    Si tu as des threads memory bound, tu reveille un coeur a pleine frequence et tu ajustes progressivement si necessaire pour avoir le resultat qui maximise la bande passante et l'usage d'un coeur.
    
    Bon, ca c'est simple… Maintenant tu mixes des threads de toutes les categories dans le meme systeme et pour etre plus sympa tu ne dis pas qui fait quoi au kernel ! Bien entendu le resultat est globalement mauvais. C'est un des changements que j'aimerais bien voir arriver a un moment dans le kernel, la possibilite de dire si un thread est CPU, IO ou memory bound. Avec ca le scheduler pourrait prendre des decisions plus efficace pour eviter d'avoir des frame drop et une surconsomation d'energie. Par contre, c'est des problematiques bas niveau et il faut que toute la chaine coopere.
    
    Cela demande aussi de diviser tes taches intelligement en plusieurs thread pour que kernel puisse prendre la bonne decision de scheduling (globalement equilibre les taches entre les processeurs et ajuster la frequence a la volee).
    
    Sinon les processeurs que j'utilise sont parfaitement capable d'ajuster la frequence de toute la puce, sous systeme memoire inclue. Ca fait d'ailleur partie des points de mesure en premiere approximation de la consomation d'energie de deux logiciels qui font la meme chose. D'ailleurs ils ont des fonctions sympa, comme la possibilite de couper l'alimentation complete d'un banc de memoire pour sauver de l'energie. Ca veut dire qu'il faut bouger tout le monde pour ne pas perdre les donnees, mais c'est payant si ton soft est optimise pour ne pas utiliser trop de memoire et avoir des grandes periodes de veille
    
    La strategie etant d'attendre un peu, de signaler aux applications qu'on va partir en veille profonde donc qu'elles doivent vider leur cache et compresser leurs objets ou juste se succider. Puis on peut commencer a bouger les pages d'un banc a l'autre, probablement que l'utilisation de zswap peut aider dans ce scenario. Enfin on peut peut etre couper un banc memoire complet et partir en suspend. Sachant que en suspend, la memoire est le second point de consomation (derriere la radio), c'est une optimisation assez sympa, surtout sur les telephones qui passe leur temps en suspend dans la poche.
    - [^] # Re: Mouais
      
      Posté par Nicolas Boulay (site web personnel) le 10 janvier 2014 à 09:48. Évalué à 4.
      
      J'ai bossé sur l'écriture de la lib bas niveau de gestion d'énergie d'un truc équivalent à l'omap3. Le cpu avait 4 points de fonctionnement, chaque point bas était plus efficace par cycles. Donc ajuster la fréquence aurait un sens pour baisser la consommation. Sauf que cela ne tient pas compte de la consommation des caches, qui avait 3 modes de fonctionnement : on, freeze, off. Les caches allumés faisaient perdre tout gain d'une baisse de fréquence.
      
      A l'époque, la mode était de passer de "race to idle" à "spread to deadline". Mais ce n'était pas vraiment applicable. Il valait mieux aller le plus vite possible, puis flusher et couper les caches.
      
      "La première sécurité est la liberté"
      - [^] # Re: Mouais
        
        Posté par cedric le 10 janvier 2014 à 15:51. Évalué à 2.
        
        D'ou ma description de l'utilisation du parallelisme. Reussir a faire la meme tache en tournant sur 4 coeurs a 1/3 de la frequence pour le meme resultat. Ca ne prend pas moins de temps ou plus de temps, ca utilise par contre moins d'energie. En gros, en faisant tourner le 4 eme core (qui est problement necessaire pour payer l'overhead du multithread), tu arrives a obtenir le meme resultat en temps d'execution. Mais du fait que tu tournes a 1/3 de la frequence, tu reussis a consommer moins d'energie.
        
        Mais comme je l'ai deja dis dans un autre thread, le probleme, c'est la cooperation entre le kernel et l'user space. Il n'y a pas moyen d'informer le kernel qu'on a 4 taches CPU intensif et que la maintenant, il faut reveiller tout le monde. Le kernel d'un point de vue scheduling joue au devinette et ca devient tres complique pour lui. Plusieurs coeurs heterogenes qui peuvent tourner a des frequences variables avec des taches a dispatche dont on ne connait pas les besoins futures, mais juste le comportement passe. Meme Mme Irma se trouve dans une meilleur situation lorsqu'elle predit l'avenir !
        
        [^] # Re: Mouais
        
        Posté par Nicolas Boulay (site web personnel) le 10 janvier 2014 à 16:34. Évalué à 2.
        
        "En gros, en faisant tourner le 4 eme core (qui est problement necessaire pour payer l'overhead du multithread), tu arrives a obtenir le meme resultat en temps d'execution. Mais du fait que tu tournes a 1/3 de la frequence, tu reussis a consommer moins d'energie."
        
        Je ne vois pas comment c'est possible. Pour moi, c'est toujours plus rapide, et moins consommateur d'énergie globalement, de tourner à 100% d'un seul cpu.
        
        En gros, tu as chaque cpu consomme 100 et ton cache 100. Si tu as besoin de 1000 cycles de calcul, tu as une conso sur un seul cpu de 200 000 d'énergie (nb cycle * puissance : (100 + 100) * 1000). Si tu tournes à 1/3 de la fréquence, on va dire que tu consommes 25 par cycle. Donc, tes 1000 cycles de coute (25+100)*3000= 375 000 (cpu 3x plus lent). Si tu dis que tes 4 cpus permet de garder le boulot en 1000 cycle, tu as (4*25+100)*1000= 200 000.
        
        En gros, tu y gagnes, si tu baisses franchement la consommation d'un multicoeur unitaire. Mais bon, on ne tient compte que de la consommation dynamique, normalement tu as de la consommation statique, et ton monocoeur devrait moins consommer si tu rajoutes encore une part de consommation fixe.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Mouais
        
        Posté par lasher le 10 janvier 2014 à 17:34. Évalué à 2.
        
        Il y a tout un champ de recherche sur des mémoires locales (caches ou scratchpads) ou même la DRAM qui soient désactivables par morceaux (clockgating ou même powergating) en fonction de ce dont les processeurs ont besoin, justement pour que tu puisses réduire la consommation statique. Intel a récemment publié un papier (il y a ~6 mois ?) qui montre comment utiliser une FPU avec une précision variable pour des FMA, histoire de pouvoir « couper » la partie du bus qui ne sert à rien. Les modes étaient quelque chose du genre 16bits, 32bits, et 64bits si je me souviens bien.
        
        [^] # Re: Mouais
        
        Posté par Nicolas Boulay (site web personnel) le 12 janvier 2014 à 21:45. Évalué à 3.
        
        Sur omap, tu avais plusieurs modes sur plusieurs zone : couper le courant; couper le courant, sauf celui de certains registres, passer en veille (mise en série d'une diode qui basse la tension de 0.6V, ce qui permet de sauver les registres horloge coupé), ensuite il y a les modes sans horloges.
        
        La différence entre ses modes, c'est le niveau de consommation, mais surtout le temps de réveille : allumer une PLL était très long, idem pour un powerdomain (qq ms ?).
        
        Si intel propose des coupures sur FMA, les changements de mode peuvent couté très cher.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Mouais
        
        Posté par cedric le 11 janvier 2014 à 05:08. Évalué à 2.
        
        Il est admis que la consomation d'energie suit une loi en puissance de 3 de la frequence. Donc si tu as 25 a 1/3 de la frequence, tu passes a 25 * 25 * 25 a pleine frequence. Pas 100, mais 15625. Ca change un peu le calcul de depart a pleine frequence :-)
        
        La consomation dynamique n'est pas a negliger quand tu as un CPU qui peut passer de 0 a 2Ghz avec de 1 a 4 coeurs (voir avec des variations sur les coeurs disponible). Il y a clairement une consomation statique, mais bon, sur le materiel dont on parle, c'est la partie dynamique qui est le plus genant (Sans compter l'ecran et la radio).
        
        [^] # Re: Mouais
        
        Posté par Nicolas Boulay (site web personnel) le 12 janvier 2014 à 21:52. Évalué à 3.
        
        "Il est admis que la consomation d'energie suit une loi en puissance de 3 de la frequence. Donc si tu as 25 a 1/3 de la frequence, tu passes a 25 * 25 * 25 a pleine frequence. Pas 100, mais 15625. Ca change un peu le calcul de depart a pleine frequence :-)"
        
        Soit il y a du changement depuis 2008, soit il y a un gros soucis. La consommation est en f*V² (conso dynamique) + conso statique qui est proportionnel à la surface et à le tension (fuite). La conso dynamique était devenu inférieur à la conso statique. Le but était de baisser la tension à tout prix.
        
        " Il y a clairement une consomation statique, mais bon, sur le materiel dont on parle, c'est la partie dynamique qui est le plus genant (Sans compter l'ecran et la radio)."
        
        Pour moi, c'était plus vrai depuis le 65nm.Encore avant, couper l'arbre d'horloge pouvait faire tomber 70% de la consommation.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Mouais
        
        Posté par cedric le 13 janvier 2014 à 03:07. Évalué à 2.
        
        La consommation est en f*V² (conso dynamique)
        
        Vu qu'on fait varier la frequence et le voltage a la baisse dans le cas de la conso dynamique, on n'est pas loin d'avoir un f³ pour la consomation en premiere approximation.
        
        La conso dynamique était devenu inférieur à la conso statique.
        
        Sur un terminal mobile qui passe son temps en veille, oui, la consomation statique est le probleme important. Maintenant la plus part de ces terminaux mobiles sont la pour etre utilise et le but est donc de maximiser le temps d'utilisation. Pour ca, il est certain qu'il faut baisser la conso statique, mais ca le soft n'y peut rien. C'est du a la techno utilise et tu n'as pas d'optimisation pour. Par contre pour la conso dynamique, tu peux gratter un ordre de grandeur entre deux logiciels qui donnent le meme resultat visuel et ca, ce n'est absolument pas negligeable. Une optimisation qui te donne un gain de 10% de batterie quand tu as deja 10h d'autonomie en utilisation, ce n'est pas negligeable. Et Android n'est pas un foudre de guerre de ce cote la (Pas de scene graph et pas de gestion fine de la memoire).
        
        Apres il y a d'autres trucs fun qui ont un impact sur la consomation. Par exemple avec les ecrans AMOLED, il vaut mieux un theme sombre pour minimiser l'utilisation de la batterie. Certains ecrans integres une memoire directement au niveau du pixel, ce qui permet d'eteindre completement la puce qui fait le scanout et d'avoir encore une consomation plus basse meme quand on affiche quelques choses.
        
        Le touchscreen est aussi un truc qui coute de la batterie. C'est pour ca que Qualcomm pour sa montre est capable de n'activer qu'une partie de celui-ci. Mais cela demande au soft de remonter quel sont les zones ou il veut recevoir des events et d'adapter l'UI en fonction.
        
        Certaines applications ont besoin d'information de geolocalisation, mais n'ont pas forcement besoin d'une grande precision, avoir un daemon et une API qui permet d'eviter d'allumer le GPS quand une application veut juste savoir a peu pres ou tu es et encore une optimisation qui paye.
        
        C'est avec toutes ces optimisations qu'on arrive, ou pas, a tenir une journee sur sa batterie en utilisant son telephone. Par contre, si tu arretes de l'utiliser, il tiendra la semaine sur sa batterie…
        
        [^] # Re: Mouais
        
        Posté par Nicolas Boulay (site web personnel) le 13 janvier 2014 à 09:22. Évalué à 4.
        
        "Vu qu'on fait varier la fréquence et le voltage a la baisse dans le cas de la conso dynamique, on n'est pas loin d'avoir un f3 pour la consomation en premiere approximation."
        
        Pour la puissance instantané, pas pour la consommation d'une tache, qui est multiplié par le temps pour l’exécuter. Ce temps augmente avec la baisse de la fréquence. Si on baisse une fréquence sans baisser la tension, cela ne sert à rien. Les OMAP sont équipé d'un système de retroaction qui mesure la vitesse de la puce (vitesse d'un anneau d'inverseur) et adapte la tension en fonction.
        
        "Sur un terminal mobile qui passe son temps en veille, oui, la consomation statique est le probleme important."
        
        Non pas du tout. En veille, 99% de la puce est coupé. Il reste juste le domaine de réveil(wakeup domain), qui est alimenté avec une horloge à 32khz. Quand je parle de conso statique, je parle de fuite de courant de bloc allumé (power domain). Ces fuites sont proportionnelles à la surface de la zone et à la tension, indépendamment de la fréquence de l'horloge.
        
        " Pour ca, il est certain qu'il faut baisser la conso statique, mais ca le soft n'y peut rien. C'est du a la techno utilise et tu n'as pas d'optimisation pour."
        
        Si tu peux, avec le "race to idle", et la gestion correct des latences de réveil (cf les arrondis des compteurs de Linux pour grouper les réveils). Il y a aussi la gestion correct des états des périphériques, souvent si un driver est utilisé, son bloc n'est jamais complètement coupé de peur de perdre son état. Le fait d'adapter la fréquence entre bus mémoire et cpu, permet aussi de baisser la tension qui a un effet sur la consommation statique.
        
        Souvent la combinaison des systèmes de gestion d'énergie est tellement compliqué (on parle de >100 blocs dans des power domain différent, avec des clock domain différent, et des dépendances gérés plus ou moins automatiquement), que le plus simple est encore de gérer des "modes" d'usage, pour passer de l'un à l'autre, et optimiser à mort leur configuration. C'est beaucoup plus simple que d'essayer de faire du code intelligent qui s'adapte à tous les cas (en plus un code qui tourne, c'est un cpu allumé, un bus mémoire, une mémoire, etc…).
        
        "La première sécurité est la liberté"
        
        [^] # Re: Mouais
        
        Posté par ariasuni le 13 janvier 2014 à 09:59. Évalué à 5.
        
        Il y a moyen de faire des citations en Markdown.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Mouais
        
        Posté par cedric le 13 janvier 2014 à 14:06. Évalué à 4.
        
        indépendamment de la fréquence de l'horloge.
        
        A priori non, car la tension varie en fonction de l'horloge.
        
        Quand a la strategie du race to idle, il faut qu'il n'y ait rien qui ne se mette en travers du CPU. Hors il est tres tres difficile d'avoir une tache qui n'est pas memorie bound. Resultat si tu peux, et c'est le cas sur pas mal de tache, diviser le boulot entre 4 coeurs qui tourneront a frequence plus faible qu'un unique coeur qui tournera a frequence maximum, tu gagnes en batterie. Ton point etant que quitte a avoir 4 coeurs qui tournent, autant les faire aller le plus vite possible. Le probleme, c'est qu'a ce moment la, c'est la memoire qui ne suit plus et tu te retrouves a prendre au tant de temps qu'avant, sauf que tu as 4 coeurs qui tournent dans le vide une bonne partie du temps. Le principal probleme vient de la bande passante memoire qu'un unique coeur peut saturer assez facilement sur quasiment toutes les operations.
        
        Pour la blague, on fait de la compression RLE des glyphs pour gagner sur la bande passante memoire. On gagne 30% de performances sur le rendu du texte et un peu plus de 10% en terme de gain sur la batterie. On fait faire plus au processeur, mais il attend alors moins longtemps avant d'aller roupiller. Sans compter qu'en accedant moins au sous-systeme memoire, on diminue aussi la consomation, car chaque niveau a un cout d'acces energetique superieur. Ah, et c'est chiffre sont sans optimisation de type vectorisation pour l'instant. Il faut encore qu'on fasse le port NEON. Oui, l'implementation C d'un blit de glyph en RLE est plus performante qu'un blit vectorise en assembleur…
        
        [^] # Re: Mouais
        
        Posté par Nicolas Boulay (site web personnel) le 13 janvier 2014 à 14:23. Évalué à 2.
        
        "Ton point etant que quitte a avoir 4 coeurs qui tournent, autant les faire aller le plus vite possible. "
        
        Ok, c'est ça que je ne comprenais pas : dans l'archi en question, tu ne peux pas couper les cpus individuellement. Maintenant, avec les archi big/little, ARM met 2 cpus cote à cote, et il y a un transfert de registres pour les mode les moins rapide, cela permet d'utiliser un processeur plus petit.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Mouais
        
        Posté par cedric le 13 janvier 2014 à 14:46. Évalué à 2.
        
        Pour le detail, sur les Exynos et les derniers Qualcomm, pour ne citer que ceux que je connais, on fait du hot plug de CPU. On les coupe litteralement completement si ils ne sont pas necessaire. C'est d'ailleur assez problematique comme systeme, car tu ne peux plus detecter combien de core tu as et repartir intelligement tes taches. Globalement, le manque de communication entre noyau et espace utilisateur est encore plus criant.
        
        [^] # Re: Mouais
        
        Posté par Nicolas Boulay (site web personnel) le 13 janvier 2014 à 14:52. Évalué à 2.
        
        "On les coupe litteralement completement si ils ne sont pas necessaire."
        
        C'est nouveau comme technique ? Cela fait un moment que l'on peut coupé les cpu. J'imagine que c'est nouveau de n'avoir qu'un seul cpu allumé au lieu de 2 ou 4 habituellement.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Mouais
        
        Posté par cedric le 14 janvier 2014 à 02:30. Évalué à 2.
        
        J'ai vu apparaitre ca dans le hard qu'on a eu, il y a environ 1 an et demi. Et c'est different de mettre la clock a zero. Le temps pour rallumer un CPU est "assez" important vu qu'on pert le cache de premier niveau.
        
        [^] # Re: Mouais
        
        Posté par Nicolas Boulay (site web personnel) le 14 janvier 2014 à 09:40. Évalué à 2.
        
        Oui quand tu coupes un powerdomain, il faut un temps de mise en place de la tension qui est de l'ordre de la milliseconde au moins, et tu perds au moins les registres et les caches, sauf si il y a une tension spécifique de rétention pour ces registres. Dans ce dernier cas, cela peut être vue comme la coupe d'une horloge, mais avec plus de temps de mise en route. Le plus long a redémarrer sont les pll qui génèrent les horloge, de mémoire, c'était ~250ms.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Mouais
        
        Posté par Nicolas Boulay (site web personnel) le 13 janvier 2014 à 15:10. Évalué à 3.
        
        ". Il faut encore qu'on fasse le port NEON. Oui, l'implementation C d'un blit de glyph en RLE est plus performante qu'un blit vectorise en assembleur…"
        
        Je ne sais pas si cela a changé mais la balance de performance entre cpu normal et NEON a complètement changer entre CortexA8 et CortexA9, ce sont 2 équipes différentes qui ont créé les 2 cpus, l'une ne croyant pas à l'intérêt du NEON (de mémoire, c'est la française). De mémoire encore, le A8 issue 2 instructions à la fois, le A9 une seul, ce qui fait que parfois le cpu est plus rapide que le copro NEON sur A9.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Mouais
        
        Posté par cedric le 14 janvier 2014 à 02:27. Évalué à 3.
        
        De maniere generale, on arrive a rendre du code vectorise avec NEON plus rapide qu'en C. Le principale probleme, c'est que compare a toute la tripote de MMX, SSE et compagnie du x86, NEON est assez pauvre et manque souvent de fonctionalites qui le rendent moins utile. Mais le point important, c'est qu'un blit d'un glyph en 8bits optimise en assembleur vectorise est plus lent que du code qui fait du blit d'un glyph compresse en RLE code en C (optimise aussi, mais pas autant).
        
        Cela veut dire que l'on est clairement memory bound sur ce genre d'operation. En fait, ce n'est pas la premiere optimisation qui en reduisant notre consomation memoire resulte en une amelioration de nos performances. Nous avons fait de la deduplication de chaine de characteres et de structure C en memoire pour diminuer notre consomation memoire, mais, au final, nous avons gagne plus de 10% de performance de rendu. On en est a ce demander si ca ne vaut pas le cout de compresse en RLE certaine de nos resources graphiques. Globalement, le seul moyen d'ameliorer les performances que nous voyons maintenant, c'est de trouver ce que l'on peut encore dedupliquer et ce que l'on peut compresser.
        
        [^] # Re: Mouais
        
        Posté par Nicolas Boulay (site web personnel) le 14 janvier 2014 à 09:46. Évalué à 3. Dernière modification le 14 janvier 2014 à 09:48.
        
        "De maniere generale, on arrive a rendre du code vectorise avec NEON plus rapide qu'en C. "
        
        Oui, mais sur quel CPU ? Sur A8, je n'en doute pas, sur A9, c'est moins évident.
        
        " Globalement, le seul moyen d'ameliorer les performances que nous voyons maintenant, c'est de trouver ce que l'on peut encore dedupliquer et ce que l'on peut compresser."
        
        Vous triez déjà les champs des structures de données par ordre décroissant de taille pour éviter le padding ?
        
        Vous pouvez aussi mettre en place du tiling, c'est à dire de changer l'ordre des opérations pour que les données utiles restent dans le cache le plus longtemps possible (travailler par texture et non par coordonnés d'écran par exemple, etc…). Sur la multiplication de matrice pleine, cela fait gagner un facteur 10.
        
        Sur x86, tu as aussi des instructions pour ne pas mettre certaine données en cache. Cela peut être utile, si il s'agit de faire une simple copie de données, dont tu n'as plus besoin du tout ensuite, cela évite de "trasher" le cache.
        
        Sinon, je croyais qu'un des avantages des images vectorielles étaient justement la faible empreinte mémoire, remplacé par du temps cpu.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Mouais
        
        Posté par lasher le 14 janvier 2014 à 18:20. Évalué à 2.
        
        Sur x86, les instructions qui ne mettent pas en cache (je suppose que tu parles des instructions de type mov[xxx]nta etc.) n'empêchent pas la mise en cache à ma connaissance, mais garantissent que les données seront placées en tant que « lignes les moins utilisées » (pour être les premières à être évincées).
        
        [^] # Re: Mouais
        
        Posté par cedric le 15 janvier 2014 à 04:39. Évalué à 2.
        
        Oui, mais sur quel CPU ? Sur A8, je n'en doute pas, sur A9, c'est moins évident.
        
        Le A8 n'est pas multiprocesseur :-) Donc on parle bien des generations apres le A8.
        
        Vous triez déjà les champs des structures de données par ordre décroissant de taille pour éviter le padding ?
        
        Ca, ca fait des annees que l'on fait ca ! C'est un peu la base. On en est a faire de la deduplication de structure entre objet pour limiter la consomation memoire. Une espece de copy on write de certaine partie d'une structure en C avec un garbage collector qui utilise une table de hash pour trouver qui ressemble a qui et merger tout le monde on-idle.
        
        Vous pouvez aussi mettre en place du tiling, c'est à dire de changer l'ordre des opérations pour que les données utiles restent dans le cache le plus longtemps possible (travailler par texture et non par coordonnés d'écran par exemple, etc…).
        
        On fait deja ca, meme en OpenGL, pour reordonneer les operations et rester en cache (ou limiter les switch de context en OpenGL).
        
        Sinon, je croyais qu'un des avantages des images vectorielles étaient justement la faible empreinte mémoire, remplacé par du temps cpu.
        
        Le probleme etant que le temps de generation devient bien trop important et que la somme de code necessaire pour generer une image est aussi problematique. Il faut trouver un equilibre entre le niveau de compression, la somme de code que cela necessite pour faire la decompression, la bande passante memoire utilise et la puissance CPU necessaire pour cela.
        
        Le RLE se code assez facilement en inline pour la decompression. Globalement, c'est "juste" une expansion d'une valeur. En ajoutant une table de saut en entete pour faciliter le saut a une ligne precise, tu te retrouves avec un code un peu complexe, mais pas impossible a maintenir et sans impact important sur la masse de code traverse. Ce n'est bien entendu pas le cas avec le SVG qui est tellement complexe qu'il te faut une VM Javascript pour couvrir tout le standard…
        
        [^] # Re: Mouais
        
        Posté par Nicolas Boulay (site web personnel) le 16 janvier 2014 à 09:55. Évalué à 1.
        
        "Ce n'est bien entendu pas le cas avec le SVG qui est tellement complexe qu'il te faut une VM Javascript pour couvrir tout le standard…"
        
        Et un format vectoriel +simple, aurait du sens ?
        
        "La première sécurité est la liberté"
        
        [^] # Re: Mouais
        
        Posté par cedric le 17 janvier 2014 à 03:21. Évalué à 3.
        
        Le probleme du vectoriel, c'est qu'on se retrouve avec des formules de courbe assez complexe a execute niveau CPU dans tous les cas. Je ne pense pas qu'il soit possible d'avoir un format vectoriel qui est des performances proches de ce que font de simple blit. Il faudrait que la difference entre bande passante memoire et performance CPU soit encore plus grande qu'actuellement pour que cela soit vraiment plus interressant (En esperant arriver a faire tenir le tout dans pas trop de code pour eviter de perdre de l'autre cote dans les temps d'acces au code).
        
        Pour l'instant, tous les systemes de rendu vectoriel que je connais sont un ordre de grandeur plus lent que ceux qu'on a. Pour etre interressant, il faudrait trouver un qui soit deja dans le meme ordre de grandeur puis voir si on peut l'optimiser pour le rendre competitif. Je n'en connais pas qui corresponde a cette objectif…
        
        [^] # Re: Mouais
        
        Posté par Nicolas Boulay (site web personnel) le 17 janvier 2014 à 09:37. Évalué à 1.
        
        Je pensais à des bêtes polynômes. Ce n'est pas du vectoriel, mais plus du généré.
        
        Je suis tombé sur : http://www2.maths.ox.ac.uk/chebfun/ pour avoir une idée d'implémentation efficace de la fonction de compression.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Mouais
        
        Posté par Nicolas Boulay (site web personnel) le 14 janvier 2014 à 11:16. Évalué à 3.
        
        D'ailleurs, au lieu de faire du RLE, pourquoi ne pas utiliser les nouveau algo de compression ultra rapide comme LZO ou LZ4.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Mouais
        
        Posté par cedric le 15 janvier 2014 à 04:43. Évalué à 3.
        
        Principalement parce qu'ils sont plus complexe et inliner un decompresseur LZ4 ou LZO pour acceder a une ligne de pixels dans un glyph, ca va un peu impacter tes caches instructions et donc ta bande passante memoire. Maintenant le challenge, c'est de coder un decompresseur RLE avec des shaders :-)
        
        Apres je ne crois pas qu'il y ait l'equivalent des instructions AES de disponible pour faire de la compression/decompression a la volee. Clairement, si c'etait disponible on utiliserait un mecanisme disponible en hard pour tenter de gagner encore en bande passante (meme si au final, on a le meme debit, on aurait moins d'instruction et donc plus de bande passante pour pousser des pixels a l'ecran).
        
        [^] # Re: Mouais
        
        Posté par Nicolas Boulay (site web personnel) le 16 janvier 2014 à 09:57. Évalué à 1.
        
        Dans certain papier, ils disent que la décompression LZ4, va plus vite qu'une copie en RAM. En multi-cpu, il arrive à saturer la bande passante mémoire. J'imagine qu'il est possible d'encore plus simplifier le schéma pour aller encore plus vite.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Mouais
        
        Posté par cedric le 17 janvier 2014 à 03:26. Évalué à 2.
        
        Faudra regarder dans le detail, mais il y a un detail a ne pas oublier, c'est qu'on a besoin de pouvoir faire un acces aleatoire aux pixels (pour pouvoir supporter le clipping). Il faut donc faire attention a ne pas etre force de lire tout une ligne pour trouver le pixel qui nous interresse. De plus il faut pouvoir chainer la mecanique de saut pour trouver le pixel qui nous arrange, a celui ou on blit en mixant le code avec le reste de la logique de decompression. Ca pose certaine contrainte. Mais je regarderais si il n'y a pas moyen de moyenner quelques choses avec Lz4, meme si ma semble tres tres complique au vu de l'ensemble des contraintes.
        
        [^] # Re: Mouais
        
        Posté par Nicolas Boulay (site web personnel) le 17 janvier 2014 à 09:38. Évalué à 1.
        
        Les polynômes permettent aussi un accès aléatoire.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Mouais
        
        Posté par cedric le 17 janvier 2014 à 09:54. Évalué à 2.
        
        Hum, parcontre en temps de generation (pour la compression et la decompression), ca doit etre plutot couteux, non ?
        
        Ca doit probablement se rapprocher des techniques de Glyphy pour le rendu des font directement cote GPU.
        
        [^] # Re: Mouais
        
        Posté par Nicolas Boulay (site web personnel) le 17 janvier 2014 à 10:14. Évalué à 1.
        
        La compression peut prendre du temps, si on veut être optimal. La décompression aussi si le bloc est large, mais cela peut se borner. Dans le cas le pire, tu as n coeff pour n donnés, et pour chaque pixel tu as n multiplication, et (n-1) additions.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Mouais
        
        Posté par Nicolas Boulay (site web personnel) le 16 janvier 2014 à 10:47. Évalué à 1.
        
        Ta compression RLE compresse des lignes de pixels RGBA ?
        
        "La première sécurité est la liberté"
        
        [^] # Re: Mouais
        
        Posté par cedric le 17 janvier 2014 à 03:22. Évalué à 2.
        
        Non, on parle de glyph pour l'instant uniquement, donc niveau de gris.
        
        [^] # Re: Mouais
        
        Posté par Thomas Debesse (site web personnel) le 13 janvier 2014 à 10:58. Évalué à 5.
        
        Vu qu'on fait varier la frequence et le voltage
        
        → Vu qu'on fait varier la fréquence et la tension
        
        Ce serait dommage que les commentaires qui sont à ma portée ne soient pas écrits en Français ! ;)
        
        ce commentaire est sous licence cc by 4 et précédentes
- [^] # Re: Mouais
  
  Posté par mordicusetcubitus le 10 janvier 2014 à 17:57. Évalué à 3.
  
  Hum, euh, hum, c'est bizarre, je dois vivre dans le futur. Ici tout le monde a la fibre et la 4G. Tu peux trouver du wifi gratuit a peu pres partout, meme les bus on une borne Wifi (Et aussi des TV avec de la pub entre deux arrets). Par contre, on fait plutot du tethering, vu qu'on a 5Go de limite mensuel sur nos forfaits 4G. Une fois les update automatique d'Android desactive, il y a de la marge pour consommer de la bande passante sur une seule SIM.
  
  Ah, oui, je ne suis pas en France, ni dans le futur, mais juste en Coree !
  
  Oui, bien moi je suis à la campagne, en France et même pas dégroupé !
  Et je galère un peu: j'ai même pas la télé. Mais finalement, c'est peut-être une bonne chose.
  
  Mais c'est vrai que c'est déjà du présent. Toutefois tu ne peux pas encore vraiment dire que tu peux utiliser ton smartphone pour faire tout ce que tu fais avec un pc et notamment programmer : le futur proche c'est la convergence smartphone/tablette/pc et ce sera de la balle. Mais il faut un smartphone qui ait de la puissance et une faible consommation…
  
  Moi j'y vois bien un Kalray quand il fera tourner Linux Ubuntu (version mixte smartphone/desktop)…
  - [^] # Re: Mouais
    
    Posté par briaeros007 le 12 janvier 2014 à 10:50. Évalué à 3.
    
    j'ai même pas la télé.
    
    Tu perd pas grand chose , peut être un peu arte le mardi soir de temps en temps, et quelques polars pour passer une soirée tranquille. Mais à part ça ….
    (et puis tu as pluzz pour arte,/france5 , et certainement la même chose si un polar passe et t'intéresse).
    - [^] # Re: Mouais
      
      Posté par ariasuni le 12 janvier 2014 à 12:22. Évalué à 1.
      
      Tu rates ça ou ça. Ou ça.
      
      Oui, je pense que ceux qui font les pubs télévisés prennent de la drogue.
      
      Remarque: il y en a aussi des drôles des fois (très très très rarement certes), comme celle-là.
      
      Écrit en Bépo selon l’orthographe de 1990
# Le prix du Kalray

Posté par Maccappuccino le 09 janvier 2014 à 07:25. Évalué à 10.

Ce produit aussi révolutionnaire a un problème c'est qu'il n'affiche pas son prix. Pour l'instant vendu sous forme de carte additionnelle MPPA BOARD EMB01.
De nombreux produits révolutionnaires sont mort nés à cause de ce problème.
- [^] # Re: Le prix du Kalray
  
  Posté par lasher le 09 janvier 2014 à 22:20. Évalué à 7.
  
  Le prix est relativement élevé, mais c'est quelque chose d'attendu. Un autre processeur manycore, Tile64 (produit par Tilera, une boite fondée par un prof au MIT), coûte dans les ~12000$ (ça inclut la chaîne de compilation basée sur gcc, la carte d'extension, etc.). Le MPPA est plus ou moins dans le même ordre de prix si je me souviens bien. Il ne faut pas oublier que les processeurs type Alpha étaient aussi très très chers comparés aux x86 dans les années 90.
  
  Le problème est évidemment lié au volume de production. Au début seuls les gens qui ont un réel besoin de ce genre de processeurs (effectivement, les organismes de type CEA/DAM, DCRI, l'armée en règle générale, etc.) peuvent se permettre d'acheter ces trucs. Mais si ces processeurs ont un succès « significatif » dans ces niches, on peut espérer voir des versions plus « grand public » et plus faciles à produire en masse.
  - [^] # Re: Le prix du Kalray
    
    Posté par benoar le 10 janvier 2014 à 12:02. Évalué à 5.
    
    Un autre processeur manycore, Tile64 (produit par Tilera, une boite fondée par un prof au MIT), coûte dans les ~12000$ (ça inclut la chaîne de compilation basée sur gcc, la carte d'extension, etc.).
    
    D'ailleurs je les trouve intéressant, car ils ont super bien collaboré avec l'upstream, et on retrouve leur support dans le noyau et dans gcc dès aujourd'hui. Voir http://www.tilera.com/ et http://www.tilera.com/scm/. Un bon avantage sur ce « Kalray » (au fait, c'est un communiqué commercial cette news ?).
    - [^] # Re: Le prix du Kalray
      
      Posté par MarbolanGos (site web personnel) le 10 janvier 2014 à 15:09. Évalué à 3.
      
      au fait, c'est un communiqué commercial cette news ?
      
      Il suffit de lire le dernier paragraphe :
      
      Pour finir, je tiens à préciser que, malgré mon engouement notoire pour cette belle technologie qu'est le MPPA 256, je ne travaille pas pour Kalray. Ce qui n'empêche pas que je sois totalement partial sur ce sujet. Normal, le MPPA 256 c'est un catalyseur d'économies : c'est bon pour le business, et c'est bon pour la planète !
      - [^] # Re: Le prix du Kalray
        
        Posté par mordicusetcubitus le 10 janvier 2014 à 18:04. Évalué à 1.
        
        Je confirme que je n'ai pas de lien de quelque ordre que ce soit avec Kalray, à part mon attachement à ce produit.
        Cet article est mon initiative propre et ni mon employeur, une société de services en logiciels libres basée sur Nantes, Toulouse et Tunis, ni moi, n'avons d'accord commerciaux avec Kalray.
        
        Il est vrai que la dépêche fait la belle part à ce processeur, mais cela reste un avis personnel.
        Simplement je trouve que 256 coeurs c'est une belle prouesse technologique et que sa basse consommation répond à un véritable problème d'aujourd'hui: le mur énergétique !
        
        [^] # Re: Le prix du Kalray
        
        Posté par Zenitram (site web personnel) le 12 janvier 2014 à 16:12. Évalué à 3. Dernière modification le 12 janvier 2014 à 16:14.
        
        répond à un véritable problème d'aujourd'hui: le mur énergétique !
        
        C'est un problème oui, mais un truc cher n'y répondra pas faute d'utilisateurs. Donc le problème restera.
        Bref, ce n'est pas une solution au problème, si le mur énérgétique d'interesse tu ne devrais pas être passionné par ce projet du moins sans en connaitre le prix et sa viabilité au niveau déploiement.
# i7 980x ?

Posté par M.Poil (site web personnel) le 09 janvier 2014 à 07:58. Évalué à 6.

Je me suis arrêté là parce que boulot …
Mais i7 980x c'est déjà une vieille génération (3 ou 4 ans de mémoire), un 3930k fait déjà 40% de perf de mieux et la dernière génération (ex 4960x) à de gros gains en consommation.
Le i7 reste du grand public, après tu as les Xeon avec 2 fois plus de cœurs …

Is it a Bird? Is it a Plane?? No, it's Super Poil !!!
- [^] # Re: i7 980x ?
  
  Posté par mordicusetcubitus le 10 janvier 2014 à 18:16. Évalué à 0.
  
  C'est vrai qu'il y a un paquet de i7.
  
  La série 9x est la seule à avoir 6 coeurs (derniers datent de 2011) avec la série 3000 dont les derniers datent de 2013.
  
  La "publicité" Kalray dit "4x plus rapide que la meilleure puce Intel".
  
  Ma réaction initiale a été: laquelle ? i7, Itanium, Xeon et quelle version ?
  
  J'ai donc posé la question à Kalray qui m'a répondu précisément mais je n'ai plus la main sur mes notes. Normalement, sauf erreur de ma part, j'ai mis les bons modèles à chaque exemple de l'article.
  Dans les tests sur la compression vidéo c'est bien un itanium avec lequel il rivalisait : performances identiques mais 20 fois moins de consommation électrique pour Kalray. Ce n'est pas rien sur une facture… Même à la maison !
  - [^] # Re: i7 980x ?
    
    Posté par M.Poil (site web personnel) le 10 janvier 2014 à 19:02. Évalué à 2.
    
    Mon 3930k a 6 coeurs physiques 12 logiques (HT) :)
    Les dernières générations de i7 c'est 4 ou 6 coeurs physiques par ~~CPU~~ chip
    Et pour les Xeon de 4 à 12 coeurs (peut-être plus aujourd'hui je me suis arrêté là avec le E5-2697)
    
    Mais ça n'enlève rien à ton article qui est très intéressant
    
    Is it a Bird? Is it a Plane?? No, it's Super Poil !!!
  - [^] # Re: i7 980x ?
    
    Posté par Zenitram (site web personnel) le 12 janvier 2014 à 16:22. Évalué à 3. Dernière modification le 12 janvier 2014 à 16:26.
    
    La "publicité" Kalray dit "4x plus rapide que la meilleure puce Intel".
    
    En 2013, il existait déjà des 8 coeurs chez Intel.
    donc pour tester avec 6 coeurs? Et surtout pas avec la meilleuresérie d'Intel (Xeon)?
    Et en 2014, intel sort des 15 coeurs, il va falloir refaire les tests…
    
    Ce n'est pas rien sur une facture… Même à la maison !
    
    Ca dépend du prix d'achat, que tu n'indiques pas. Sans prix d'achat, tu n'as aucune idée de la facture. Même à la maison (en fait, surtout à la maison où tu as moins de problème pour accéder à la l'électricité pour pas cher contrairement à d'autres environements potentiels).
    Faudrait te décider : tu t'interesses juste à la prouesse technologique hors notion de prix juste pour le fun et admettons, ou tu t'interresses à l'écologie et/ou la facture et il faut te renseigner sur le coût total et pas seulement sur la conso.
# J'ai pas trouvé...

Posté par Zenitram (site web personnel) le 09 janvier 2014 à 08:58. Évalué à 10. Dernière modification le 09 janvier 2014 à 09:02.

Lorsque des centres comme ceux d'OVH ou Google auront compris qu'avec cette puce ils pourront avoir 10 fois plus de machines à consommation égale ou consommer 10 fois moins pour la même puissance de calcul, leurs calculs seront vite faits : « Business is money ! »

OVH et consort ne sont pas stupides et ne vont pas dépenser 1 000 000 € pour gagner 100 000 € sur la facture énérgétique. On a rien à faire de toutes les specifications "qui tuent" sans une des spécifications les plus importantes : le prix (ou si proto, le prix visé). Et je n'ai pas trouvé (la dépèche est longue, j'ai zappé?)
Sans cette information, impossible de savoir si c'est viable ou pas.
Alors : combien ça coûte de gagner 1 € en énergie par rapport à du Intel par exemple?

Pour comparaison un intel i7-980X a une performance d'environ 90 Gflops pour une consommation de 130W.

Comparer à un CPU plus en vente (il a 4 ans!), ça craint, ça ne donne pas du tout confiance en l'honnêté de la personne qui parle du produit.
Comparé à un CPU moderne, ça donne quoi?

Bref, au final pas beaucoup d'info qui donne une idée de viabilité… :(
Transmeta bis donc?
- [^] # Re: J'ai pas trouvé...
  
  Posté par Troy McClure (site web personnel) le 09 janvier 2014 à 11:06. Évalué à 5.
  
  Comparé à un CPU moderne, ça donne quoi?
  
  la nouveauté c'est les instructions AVX2 , qui permettent de faire 2*8 flops par cycle.
  
  16 flops / cycle * la frequence (3.33GHz) * le nb de core (disons 6 pour etre comme le i7-980X) -> 320 GFlops
- [^] # Re: J'ai pas trouvé...
  
  Posté par Matthieu Moy (site web personnel) le 09 janvier 2014 à 16:29. Évalué à 3.
  
  Pour l'instant en tous cas, et à ma connaissance, le MPPA ne vise pas vraiment marché de masse avec des processeurs pas cher. Ça vise surtout les applications (embarquées) spécifiques pour lesquelles l'état de l'art est le FPGA voire ASIC ou le GPU.
  - [^] # Re: J'ai pas trouvé...
    
    Posté par mordicusetcubitus le 10 janvier 2014 à 18:18. Évalué à 1.
    
    C'est cela.
    Mais moi je le voudrais dans mon smartphone…
- [^] # Re: J'ai pas trouvé...
  
  Posté par mordicusetcubitus le 10 janvier 2014 à 18:29. Évalué à 1.
  
  Comparer à un CPU plus en vente (il a 4 ans!), ça craint, ça ne donne pas du tout confiance en l'honnêté de la personne qui parle du produit.
  Comparé à un CPU moderne, ça donne quoi?
  
  Effectivement ce n'est probablement pas le bon comparatif. L'itanium aurait été plus judicieux. Mea culpa.
  
  Par contre je ne partage pas ton avis sur la consommation.
  Aujourd'hui le top green 500 des supercalculateurs prend une importance de plus en plus grande et il dépassera sûrement en intérêt et pouvoir de décision/choix technologique le top 500 (non green).
  
  Des milliers d'ordinateurs ça consomme énormément, et ce n'est pas qu'un problème de facture électrique : c'est aussi un problème d'approvisionnement et de maintenance de la qualité électrique.
  Sans parler des soucis pour les solutions de secours de ces machines gigantesques : a ton avis, combien faut-il de groupes électrogènes pour maintenir un supercalculateur opérationnel si une coupure de courant arrive ?
  
  Regarde aussi les smartphones: il faut les recharger tous les jours: même au niveau du particulier l'énergie est un problème. Nous trouvons tous cela pénible. Et ton allume cigare arrive tout juste à recharger un Galaxy Nexus en mode GPS.
  D'ailleurs, quand tu te sers de ton smartphone comme GPS en moins de 2/4h il est à plat. Après t'es perdu si tu n'as pas prévu de carte, c'est bête tu étais si proche de l'arrivée.
  
  Le prix actuel, que je ne connais pas, ne sera pas un problème longtemps si le processeur obtient une production de masse: il va vite chuter.
  
  Sérieusement, je pense que les gains énergétiques de ce produit en font un KILLER PROC pour les défis énergétiques que nous vivons. Il suffit de regarder son score au top green des supercalculateurs.
# arm ?

Posté par Nicolas Boulay (site web personnel) le 09 janvier 2014 à 09:45. Évalué à 10.

"Les processeurs multicoeurs d'aujourd'hui ont beaucoup de mal à dépasser les 8 cœurs car la complexité de l'unité de ré-ordonnancement des instructions croit avec le carré du nombre de cœurs gérés."

Joli mélange entre superscalaire et multicore. Pour info, le seul cout d'un multi coeur par rapport au mono coeur est la gestion de la cohérence de cache. Le cout du réordonnancement c'est pour un cpu avec plein d'unité de calcul comme l'i7.

", très adapté à la programmation parallèle, les meilleurs Itanium ne dépassent cependant pas 8 cœurs."

Oui, ils sont VLIW, qui gère des paquets de 3 instructions. Selon les générations d'itaniuim, le cpu gère 1 packets de 3, 2 ou 3 packets de 3, donc 9 instructions à la volé.

"La distance occupée entre les éléments composant le supercalculateur : l'information ne peut se déplacer plus vite que la lumière. Aussi, si la distance entre les éléments dépasse plusieurs mètres, des temps de latence de l'ordre de la dizaine de nanoseconde peuvent apparaître et atténuer les performances."

Oui, mais non. Les pertes dans la bufferisation ou dans la transmission (sérialisation, encodage, code correcteur) sont bien plus importante que ce problème là.

"Concernant le second point, si l'on caricature la puissance d'un superordinateur à son nombre de cœurs, avec 256 cœurs sur une même puce, à nombre de cœurs égaux, une seule puce MPPA suffit là où il faudrait 32 processeurs 8 cœurs. On diminue donc la taille du système par 32 et d'autant les risques de latence. Enfin, cela reste une caricature, mais c'est un facteur qui a une réelle importance."

C'est une caricature, car tu oublies complètement la bande passante mémoire.

"la loi de Moore implique une multiplication par 2 tous les 2 ans de la performance et donc de la consommation électrique. "

La loi de Moore stipule un doublement du nombre de transistor pour le même prix, tous les 12 18 ou 24 mois, selon les versions. Il n'est pas question de consommation. Mais ce doublement a été fait en baissant la taille des transistors qui mécaniquement consomme moins.

"Parce que l’efficacité énergétique de ce nouveau processeur amène une réelle rupture technologique qui trouvera un double écho dans le monde des grands centres de données qui sont dans le mur énergétique aujourd'hui et dans le monde de l'embarqué car il rend des applications réalisables aujourd'hui qui étaient impossibles auparavant, demandant une forte puissance de calcul pour un budget consommation restreint."

Oui, mais il ne faudrait pas non plus prendre Intel pour des cons. Toutes les techniques employé par ce cpu sont disponible pour Intel. C'était le projet Larrabee, qui a raté car les GPU sont beaucoup plus puissant. Un GPU propose une nouvelle façon de programmer, sans cohérence mémoire, mais toujours plus facile. Les itanium étaient aussi VLIW dans le but de récupérer le silicium de l’ordonnanceur pour mettre des unités de calcul. Mais le code a tellement enfler, qu'il fallait ajouter des mega octets de cache, là, où le x86 demandait 10x moins. Gagner sur les ordonnanceurs pour y perdre sur le cache n'a pas d’intérêt.

"Les processeurs MPPA 256 sont aussi et avant tout une alternative aux solutions FPGA et ASICS actuellement utilisées dans les projets industriels ayant besoin d'une grande puissance de calcul. Ils diminuent la complexité de programmation de ce type de puces qui demandent plusieurs mois de développement en ramenant ce délai à quelques semaines : « Time is money ! » "

J'ai rarement vu ce genre d'application. Si un standard est bien établis comme celle de la vidéo (h264), un asic sera toujours imbattable en terme de prix et de consommation. Ce genre d'ip est dans tous les téléphones portables. Concernant les FPGA, ils servent souvent pour de la communication ou du traitement où la latence est primordiale. Latence impossible à tenir avec un truc avec un OS. Si le besoin est de la grosse puissance de calcul, les DSP était beaucoup employé.

"Les processeurs Kalray tiennent apparemment clairement leurs engagements et aucun autre processeur du marché ne rivalise aujourd'hui avec leur rendement en terme de puissance/consommation électrique. "

Les coeurs ARM ? Il y a un tas de projet de cpu multicoeur ARM pour aller dans le cloud. L'avantage est que la pile de logiciel est mature sous ARM. Le besoin du cloud est rarement autour de la puissance de calcul, mais plutôt de serveur de donné (web, db, …).

"Bien sur ces ordinateurs seront entièrement personnalisables sur le principe du Phonebloks."

Non, cela n'arrivera jamais. Les connecteurs nécessaires couteraient plus chère que les puces.

"Ils seront équipés de détecteurs en tout genre comme la radioactivité, le cancer, microscope, laser…"

Je parie sur les détecteurs de CO2, Nox, CO,… Bref, la pollution atmosphérique.

"La première sécurité est la liberté"
- [^] # Re: arm ?
  
  Posté par mordicusetcubitus le 10 janvier 2014 à 18:54. Évalué à 1.
  
  Joli mélange entre superscalaire et multicore.
  
  J'avoue ne pas être un expert en architecture, je suis développeur (essentiellement web et bdd aujourd'hui) et j'ai clairement quelques lacunes sur le matériel.
  J'ai cependant fait pas mal d'efforts pour me documenter sur ce sujet qui me passionne et j'ai appris pas mal de choses au passage en écrivant cette dépêche. J'ai d'ailleurs fourni la plupart des liens que j'ai lus avant de l'écrire.
  
  Si tu n'y vois pas d'inconvénient je veux bien que tu expliques un peu plus la différence entre superscalaire et multicore: je pense que d'autres que moi apprécieront aussi tes lumières.
  
  "La distance occupée entre les éléments composant le supercalculateur : l'information ne peut se déplacer plus vite que la lumière. Aussi, si la distance entre les éléments dépasse plusieurs mètres, des temps de latence de l'ordre de la dizaine de nanoseconde peuvent apparaître et atténuer les performances."
  
  J'ai tiré cela de wikipédia, et refais le calcul à la main sur le temps de latence dûs à la propagation de l'information avec la distance en mètres. C'est une information qui reste juste. Après je ne dis pas que ce soit le seul critère. Il faut aussi penser que l'électricité ne se déplace pas forcément à la vitesse de la lumière. D'ailleurs, dans le silicium, quelqu'un connaît-il sa vitesse ?
  
  Oui, mais non. Les pertes dans la bufferisation ou dans la transmission (sérialisation, encodage, code correcteur) sont bien plus importante que ce problème là.
  
  C'est exact. D'ailleurs un des goulots d'étranglement du traitement de l'information dans les processeurs actuels c'est le temps de transmission de l'information à travers tous les bus (cartes PCI/Port Com/USB, …) qui ont des débits encore très bas.
  
  Oui, mais il ne faudrait pas non plus prendre Intel pour […] Gagner sur les ordonnanceurs pour y perdre sur le cache n'a pas d’intérêt.
  
  Oui, mais là c'est bien Intel qui s'est planté, ils ont essayé mais pas su rivaliser avec leurs concurrents.
  Le MPPA n'est pas en soi une bête de guerre en puissance de calcul, c'est probablement le Dieu actuel de la guerre en termes de rapport puissance de calcul/consommation électrique.
  Quelqu'un connaît-il un processeur ou GPU ou autre puce qui fasse mieux ?
  
  J'ai rarement vu ce genre d'application. Si un standard est bien établis comme celle de la vidéo (h264), un asic sera toujours imbattable en terme de prix et de consommation. Ce genre d'ip est dans tous les téléphones portables. Concernant les FPGA, ils servent souvent pour de la communication ou du traitement où la latence est primordiale. Latence impossible à tenir avec un truc avec un OS. Si le besoin est de la grosse puissance de calcul, les DSP était beaucoup employé.
  
  Il faudrait que quelqu'un de Kalray ou plus calé que moi te réponde, mais sa force concernant les solutions FPGA et ASICS c'est son temps de développement réduit de plusieurs mois voire années à quelques semaines. Programmer un système FPGA/ASICS c'est compliqué et fastidieux. Avec Kalray tu programmes dans ton langage préféré "comme un cpu classique" pour ce que j'ai saisi.
  
  Diminuer un temps de production d'un facteur 10 ce n'est pas rien: tu peux en 1 mois sortir un produit là ou tes concurrents vont mettre une année pour obtenir le même résultat: du coup tu es en avance, ton produit est considéré comme innovant car arrivé avant tout le monde et tu prends tout le marché !
  Regarde la guerre des consoles de jeux et smartphones ou chaque constructeur se bat pour sortir son produit quelques jours avant les concurrents…
  
  Il faut aussi penser au business dans sa globalité.
  - [^] # Re: arm ?
    
    Posté par Antoine le 11 janvier 2014 à 00:20. Évalué à 4.
    
    J'avoue ne pas être un expert en architecture […]
    je veux bien que tu expliques un peu plus la différence entre superscalaire et multicore […]
    Le MPPA n'est pas en soi une bête de guerre en puissance de calcul, c'est probablement le Dieu actuel de la guerre[…]
    
    Sérieusement, si tu n'y connais rien, évite ce genre d'affirmations tonitruantes, c'est pénible et ridicule.
    
    (je me demande franchement pourquoi cette dépêche a été validée en l'état ; ou alors ce CPU permet de faire tourner Evenja plus rapidement ?)
    - [^] # Re: arm ?
      
      Posté par claudex le 11 janvier 2014 à 08:55. Évalué à 9.
      
      je me demande franchement pourquoi cette dépêche a été validée en l'état
      
      Parce que sinon, elle aurait trainé 3 mois dans l'espace de rédaction sans que personne ne la modifie. Et l'information est quand même intéressante.
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
      - [^] # Re: arm ?
        
        Posté par briaeros007 le 12 janvier 2014 à 10:58. Évalué à 6.
        
        je rajouterais, que si je ne m'abuse, Antoine aurais très bien pu la corriger lors de la rédaction de la dépêche vu que linuxfr permet un mode collaboratif (mais j'avoue ne jamais avoir prêté une forte attention).
        
        Dans un manga, il y avait une "citation" que j'aime beaucoup
        "Je n'ai vu personne se plaindre pendant, alors venez pas me faire chier après".
        ou dit autrement, "ce qui font, ils ont le mérite de faire, même si ce n'est pas parfait."
  - [^] # Re: arm ?
    
    Posté par Nicolas Boulay (site web personnel) le 12 janvier 2014 à 22:08. Évalué à 4.
    
    " superscalaire et multicore."
    
    multicore : plusieurs cpu se partage la même mémoire : le goulot d'étranglement est sur la cohérence de cache
    superscalaire : un cpu et plusieurs unité de calcul fonctionnant en parallèle : le goulot d'étranglement est l’ordonnanceur pour faire comme si les instructions étaient exécutées dans l'ordre.
    
    "D'ailleurs, dans le silicium, quelqu'un connaît-il sa vitesse ?"
    
    10cm par ns, quand on faisait des pcb.
    
    "Quelqu'un connaît-il un processeur ou GPU ou autre puce qui fasse mieux ?"
    
    La puce d'IBM pour le hpc basé sur plusieurs powerpc.
    
    "Il faudrait que quelqu'un de Kalray ou plus calé que moi te réponde, mais sa force concernant les solutions FPGA et ASICS c'est son temps de développement réduit de plusieurs mois voire années à quelques semaines. Programmer un système FPGA/ASICS c'est compliqué et fastidieux. Avec Kalray tu programmes dans ton langage préféré "comme un cpu classique" pour ce que j'ai saisi. "
    
    Dans ce cas, c'est la taille du marché qui compte. Si c'est pour faire du calcul pour l'armée, il s'agit de quelques unités. Si il s'agit de h264, il s'agit de millions d'unité. Si c'est pour un téléphone, c'est facile d'acheter une ip qui existe déjà.
    
    "La première sécurité est la liberté"
# BitCoin mining

Posté par Benbben le 09 janvier 2014 à 09:55. Évalué à 1.

Bonjour,

Très doué pour du calcul parallèle et consommant peut d'énergie, ce processeur pourrait relancer le BitCoin mining en replaçant les GPU dans les machines dédiées.
- [^] # Re: BitCoin mining
  
  Posté par nonas le 09 janvier 2014 à 10:29. Évalué à 3.
  
  C'est déjà dépassé le minage de Bitcoin par GPU. Les ASIC disponibles les battent à plate couture. Les mineurs dotés de gros GPU se sont tournés vers d'autres monnaies (Litecoin etc).
# Dommage…

Posté par openmind le 09 janvier 2014 à 10:41. Évalué à 2.

J'ai cru a une nouvelle techno

Les batteries de nos téléphones seront produites par des bactéries en impression 3D

:(
# Merci pour cet article!

Posté par FantastIX le 09 janvier 2014 à 11:25. Évalué à 2.

Je ne savais pas qu'un tel processeur existait déjà. Je me souviens que lors d'un Salon Linux, un orateur avait extrapolé que l'année suivante Intel sortirait des processeurs à 80 cœurs. C'était vers juin 2007, si j'ai bonne mémoire.

Au sujet de la consommation d'énergie, je tendrais à dire que les sociétés ne vont pas viser l'économie mais plutôt à 10 fois plus de puissance de calcul pour le même prix de l'énergie. En tous cas c'est vrai que la consommation d'énergie est un facteur sérieux. J'ai toujours chez moi une calculatrice Casio, que je me suis achetée alors que j'étais en secondaire (école avant les études supérieures, en Belgique) voilà presque 30 ans et je n'ai pas encore changé la pile alors que je dois recharger mon smartphone tous les 5 jours.

Pour ajouter aux espoirs longue durée, perso, j'espère un jour avoir une sauvegarde qui tienne la route et le temps parce que, faut bien l'avouer, les périphériques de stockage actuels soit tombent en panne au bout de quelques années, ce qui arrive de plus en plus fréquemment (les disques mécaniques), soit vieillissent (tout matériel électronique, utilisé ou non) ou se dégradent avec le temps (disques optiques). Disons un backup dans un cube de plexi multicouches sorti d'une imprimante 3D? Reste à pondre le lecteur…
- [^] # Re: Merci pour cet article!
  
  Posté par claudex le 09 janvier 2014 à 11:51. Évalué à 2.
  
  Ce n'était pas une extrapolation, c'était ce qu'Intel avait plus ou moins anoncé http://www.clubic.com/actualite-72537-processeur-80-coeurs-intel-atteint-teraflops.html
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: Merci pour cet article!
    
    Posté par Antoine le 09 janvier 2014 à 17:29. Évalué à 3.
    
    Ce ne sont pas des processeurs généralistes… Il faut arrêter de mélanger tout et n'importe quoi, comme le fait malheureusement cette dépêche.
- [^] # Re: Merci pour cet article!
  
  Posté par ariasuni le 09 janvier 2014 à 14:14. Évalué à 3.
  
  Les SSD ça peut le faire pour le stockage non? Bon pour le moment c’est cher, mais quand ça se dégrade c’est beaucoup moins dangereux pour les données.
  
  Écrit en Bépo selon l’orthographe de 1990
  - [^] # Re: Merci pour cet article!
    
    Posté par FantastIX le 10 janvier 2014 à 10:58. Évalué à 3.
    
    Le SSD? N'en parlons pas… c'est de l'électronique pure. Au fil des ans, l'électronique devient instable, surtout si c'est de l'électronique programmée. C'est un système complexe qui peut tomber en panne de manière irrécupérable. Non, je parlais vraiment d'un système de stockage inaltérable, du moins aussi peu altérable que le papier ou la pierre.
    
    C'est aussi sans compter la mauvaise expérience d'une de mes connaissances; son disque SSD a rendu l'âme après deux ans et demi: il a tout perdu. Même si deux ans, ça a l'air d'une durée honorable, le simple fait qu'il faille faire attention à ce qu'on achète, ça refroidit. Un transistor, ça tombe en panne, ça peut brûler; un condensateur, pareil et rien ne dit qu'il ne s'altérera pas au bout de plusieurs années, rendant l'appareil inutilisable; une résistance, idem. Un système de lecture électronique comme un contrôleur de disque a autant de risques de tomber en panne que le nombre de composants qu'il contient, et il y en a.
    
    Je suis moi-même électronicien et même si ma parole est loin de valoir celle de l’Évangile je n'ai aucune confiance en l'électronique sur le très long terme. Raison pour laquelle j'ai parlé de support inerte gravé ou imprimé. Je serais du genre à imprimer mes backups sur papier avec code de correction d'erreur parce que je sais que le principe du scanner a de grandes chances d'exister encore dans plus de dix ans, probablement amélioré, de sorte que la reconnaissance de caractères ne sera plus qu'une formalité. L'ennui c'est la quantité de papier à utiliser pour sauvegarder des données binaires de plusieurs giga-octets… Mais côté technologie (à tout le moins «grand public»), on est loin de la même durabilité.
    - [^] # Re: Merci pour cet article!
      
      Posté par jyes le 10 janvier 2014 à 19:27. Évalué à 3.
      
      même si ma parole est loin de valoir celle de l’Évangile
      
      Dans quel sens ? …parce-que tout le monde n’accorde pas le même crédit à ces bouquins.
    - [^] # Re: Merci pour cet article!
      
      Posté par ariasuni le 10 janvier 2014 à 23:48. Évalué à 2.
      
      Bah ils vont devenir plus fiable, et sûrement plus fiables que les disques durs.
      
      Maintenant, la meilleure solution pour conserver ses données, c’est encore une sauvegarde: avoir ces données à deux endroits différents, si l’un tombe en panne on peut toujours les recopier sur un nouveau support de stockage.
      
      Écrit en Bépo selon l’orthographe de 1990
    - [^] # Re: Merci pour cet article!
      
      Posté par xcomcmdr le 11 janvier 2014 à 10:55. Évalué à 2.
      
      Le SSD? N'en parlons pas… c'est de l'électronique pure. Au fil des ans, l'électronique devient instable, surtout si c'est de l'électronique programmée. C'est un système complexe qui peut tomber en panne de manière irrécupérable. Non, je parlais vraiment d'un système de stockage inaltérable, du moins aussi peu altérable que le papier ou la pierre.
      
      J'ai vu énormément de disques durs de mauvaise qualité péter au bout de quelques mois (MAXTOR, surtout).
      
      J'ai des SSD de marque Kingston et Samsung depuis des années, et R.A.S. :)
      
      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
- [^] # Re: Merci pour cet article!
  
  Posté par Nicolas Boulay (site web personnel) le 09 janvier 2014 à 14:40. Évalué à 2.
  
  Tu parles de ce projet : https://fr.wikipedia.org/wiki/Larrabee
  http://www.tomshardware.fr/articles/Xeon-Phi,1-43948.html
  
  Il existe des cartes pour faire du HPC, mais cela ne va pas plus loin, les perfs étant trop basse pour concurrencer les GPU.
  
  "La première sécurité est la liberté"
  - [^] # Re: Merci pour cet article!
    
    Posté par lasher le 09 janvier 2014 à 23:29. Évalué à 2.
    
    Ben en l'occurrence, le Xeon Phi, c'est Larrabee qui arrête de se prendre pour un GPU. :-)
    
    Il y a 50 cœurs sur une carte dédiée pour la première génération (Knight Corner si je me souviens bien), mais la prochaine génération (Knight Landing) devrait être intégrée à un processeur multicœur classique, ce qui réduira évidemment tous les problèmes de latences dus aux transferts sur port PCI. Après, reste à savoir si le premier essai d'Intel sera mieux fichu que celui d'AMD avec le fusion (apparemment ça va mieux avec l'archi utilisée pour la PS4 et la Xbox One).
  - [^] # Re: Merci pour cet article!
    
    Posté par FantastIX le 10 janvier 2014 à 21:44. Évalué à 2.
    
    Tu parles de ce projet : https://fr.wikipedia.org/wiki/Larrabee
    
    En fait je sais pas de quoi je parlais en particulier (ça fait toujours très bien de dire ça en public… même pas peur.) comme c'est l'orateur qui avait introduit le sujet à l’époque, j'attendais de voir un jour ce type de processeur ou au moins qu'on le présente en grande pompe! Mais je ne me serais jamais douté qu'il s'agissait de processeurs non destinés au grand public. (Ou alors j'ai dû louper quelque chose.) Depuis les années où je suis Phoronix (entre autres), je n'ai jamais lu quoi que ce soit sur un tel processeur de chez Intel. J'ai donc cru que c'était du vent… Ça arrive à tout le monde de se planter, il paraît.
# Sceptique…

Posté par Aissen le 09 janvier 2014 à 12:24. Évalué à 10.

Je suis assez sceptique; j’étais à la conférence sur le MPAA-256 de Kalray à l’ELC (slides), et je dois dire que si il y a des bonnes idées, c’est loin d’être la révolution annoncée dans le discours marketing, ou encore dans cette news.

Déjà, il est bon de noter que du à l’architecture, les OS conventionnels ne peuvent tourner sur les 256 cores (l’interconnect ne le supporterai pas). Linux tourne sur seulement 4 cœurs, et les autres sont accessibles via une interface particulière, un peu comme on enverrai des shaders sur un gp-gpu ou un firmware sur un microcontrolleur. Donc déjà ça veut dire que vos applications traditionnelles (erlang, go, openmp…) ne vont pas profiter du cluster sans effort. Il faudra les réécrire; même si ceux qui bossent sur des HPC ont déjà l’habitude de ça.

Ensuite, si son positionnement semble intéressant par rapport aux GPU, dans les mondes des HPC je ne le vois pas concurrencer les Intel Xeon-Phi et leur future génération Knights Landing, qui saura, comme le MPAA-256, être utilisé à la fois en tant que CPU maître et CPU d’offload sur une carte PCI-E. Et je ne parle même pas de la compétition de Tilera et al, que je connais moins bien.

Cela-dit, je leur souhaite toute la réussite possible dans ce domaine assez concurrentiel, où il y a encore tout à faire…
- [^] # Re: Sceptique…
  
  Posté par rewind (Mastodon) le 09 janvier 2014 à 13:29. Évalué à 8.
  
  Personnellement, je me demande comment ça se fait que, de nos jours, on n'imagine pas le processeur en même temps que le logiciel qui va tourner dessus. En l'occurrence, Linux semble être un choix naturel pour ce genre de processeur, mais pourtant, rien n'est prêt, et même pire, l'architecture est tellement compliqué qu'il va falloir des années sans doute avant de profiter pleinement du processeur. Et donc on se prive de tout un tas d'applications gratuites. On a vraiment l'impression que les développeurs du processeur se sont fait plaisir sans penser un seul instant à ceux qui l'utiliseront plus tard, c'est-à-dire les développeurs logiciels. Alors ouais, ça en jette niveau performance brute, mais en pratique, les perfs, c'est zéro pour l'instant parce que tout le code OpenMP/MPI déjà disponible ne peut pas tourner dessus. La clef du succès, c'est aussi qu'ils soient beaucoup utilisés pour faire des économies d'échelle et faire baisser son prix unitaire. Sans ça, ça restera un joli joujou qui dépassera à peine le prototype.
  - [^] # Re: Sceptique…
    
    Posté par Aissen le 09 janvier 2014 à 16:18. Évalué à 5.
    
    Personnellement, je me demande comment ça se fait que, de nos jours, on n'imagine pas le processeur en même temps que le logiciel qui va tourner dessus.
    
    Tu veux dire comme chez Apple ?
    
    Troll à part, avant qu’ils se rachètent une team de design hardware, c’était les seuls à miser sur le GPU et pousser leur fournisseur (Samsung) à investir là dedans; kit à ce que ça prenne une place très importante sur le die; aujourd’hui on se retrouve avec des surfaces démentielles, égalées uniquement sur des puces de consoles de jeux. Ils ont été les premiers à miser sur les CPU 64-bits ARM (qui ne sert pas qu’à adresser plus de RAM), et commencent à customiser leurs cœurs ARM (comme Qualcomm) pour tirer encore plus de perfs. Sans compter qu’ils vont certainement designer leur propre GPU et lâcher Imagination à n+2 vu leurs efforts récent en recrutement.
    
    En face, peu de monde a les moyens de faire la même chose, et ceux qui en ont les moyens ne semblent pas vouloir s’en préoccuper. On va vers une concentration des fabricants de processeurs mobiles assez inquiétante.
    - [^] # Re: Sceptique…
      
      Posté par palm123 (site web personnel) le 09 janvier 2014 à 16:59. Évalué à 6.
      
      On va vers une concentration des fabricants de processeurs mobiles assez inquiétante.
      
      Dans tous les domaines. Qui se souvient des fournisseurs d'accès à Internet du début des années 2000 ?
      France-net
      Worldnet
      Club-Internet
      Tiscali
      Liberty Surf
      
      Dans la téléphonie mobile, il y en a 4 (je ne compte pas les MVNO) et certains disent qu'un va disparaitre (SFR est le favori).
      
      En téléphonie mobile, Apple et Samsung faisaient il y a un an quelque chose comme 90% du marché et 99% des bénéfices (Nokia, Blackberry, Sony, HTC, ZTE, Alcatel, Siemens, Motorola et autres se partageant donc les 1% de bénéfices restants).
      
      ウィズコロナ
  - [^] # Re: Sceptique…
    
    Posté par black le 09 janvier 2014 à 19:47. Évalué à 2.
    
    OpenMP est disponible sur MPPA256: http://www.kalray.eu/products/mppa-accesscore/c-c-posix-programming/ (en bas)
    - [^] # Re: Sceptique…
      
      Posté par Aissen le 09 janvier 2014 à 22:09. Évalué à 2.
      
      Effectivement, merci de la précision! Ça ne change rien à l’idée de fond néanmoins, les applis ne sont pas portées sans effort, il faut adapter la workload à la cible.
  - [^] # Re: Sceptique…
    
    Posté par lasher le 10 janvier 2014 à 00:25. Évalué à 10.
    Personnellement, je me demande comment ça se fait que, de nos jours, on n'imagine pas le processeur en même temps que le logiciel qui va tourner dessus.
    
    Oui enfin c'est un peu facile comme remarque. Pendant environ 20 ans, on a eu droit à la loi de Moore « facile », celle qui transformait « pour une surface donnée, on va doubler le nombre de transistors tous les 18 ou 24 mois » en « on va doubler la fréquence d'horloge des microprocesseurs tous les 18 à 24 mois ». Maintenant qu'on ne peut plus faire ça, on (re)passe au parallélisme (qu'on croyait être la panacée dans les années 70 et 80, et qui avait été déclaré mort et enterré pour l'usage générique dans les années 90 jusqu'en 2005). Donc pendant 20 ans, le hardware grand public accélérait plus ou moins automatiquement l'exécution d'applications, parfois sans même avoir besoin de recompiler. Bien sûr il y avait quelques trucs supplémentaires ici et là (AltiVec, 3dNow!, MMX, puis SSE, AVX) pour écrire des applications qui pouvaient spécifiquement viser certains types de codes (comme les instructions AES pour SSE4), mais globalement tout était pépère pour des applications « grand public ».
    
    Pour les gens qui écrivent des applications dans un environnement où les ressources sont très limitées (en gros les applications de calcul scientifique/calcul intensif et les applications embarquées), chaque nouvelle version d'un processeur a tendance à rajouter son lot de comportements qui perturbent fortement les performances. Comme les compilateurs ont tendance à évoluer relativement lentement, on se retrouve à faire des optimisations à la main, et qui souvent devront être refaites/modifiées pour la prochaine génération de processeurs.
    
    Et la raison pour tout ça, c'est qu'il y a deux facteurs de ralentissement pour l'optimisation automatique de code (en utilisant un compilateur) :
    1. Entre le moment où une technique/un algorithme/etc. pour l'optimisation de code est publiée quelque part et le moment où elle est mise en œuvre dans des compilateurs en production, il se passe environ 10 ans. Le hardware n'y est pour rien. Par exemple, une version efficace de la représentation de programmes sous forme SSA (Static Single Assignment) a été proposée en 1989. Elle a été mise en œuvre dans des compilateurs de prod' vers 1997 si je ne me trompe pas (dans open64 de SGI), et dans GCC pas avant la v3.5, soit vers 2003-2004.
    2. Entre le moment où le hardware expose de nouvelles fonctionnalités, que ce soit des instructions vectorielles (MMX/SSE/AVX), l'utilisation de prédicats pour exécuter du code spéculativement (sur processeurs Itanium ou ARM), les instructions de préchargement mémoire, ou même comme plus récemment, une version limitée de mécanismes de mémoire transactionnelle (sur certains modèles du Haswell d'Intel, ou bien pour les processeurs de Blue Gene Q), et le moment où elle peut être exploitée automatiquement, il se passe entre 5 et 10 ans. Par exemple, la génération automatique d'instructions vectorielles sur GCC a été considérée comme expérimentale jusque vers GCC v4.3 je crois bien (je peux me tromper). Pire, elle reste extrêmement restreinte comparée à l'implémentation d'Intel dans ICC.
    3. Bref, le temps qu'un compilateur exploite correctement les features d'une archi, celle-ci a le temps de devenir dépassée (c'est quasiment le cas avec l'Itanium 2 par exemple).
    Et oui, il y a un gros effort à faire pour faire communiquer les architectes et les développeurs de compilateurs et autres bibliothèques haute performance. D'ailleurs, un bon moyen d'obtenir des sous pour la recherche aux USA et en UE depuis environ 2009-2010, c'est de parler de co-design, en montrant qu'on associe des mecs du hardware et des mecs du software pour faire un système informatique avec un modèle d'exécution parallèle qui tient la route (càd : une vraie sémantique parallèle, un modèle mémoire qui permette les optimisations tout en assurant que les programmes s'exécutent correctement, et un modèle de synchronisation qui relie modèle de concurrence et modèle mémoire de façon cohérente).
    - [^] # Re: Sceptique…
      
      Posté par Nicolas Boulay (site web personnel) le 10 janvier 2014 à 09:52. Évalué à 6.
      
      Marrant j'ai passé mon DEA en 2001, qui parlait déjà de co-design. Puis, j'ai été dans l'industrie, et j'ai vu que souvent le point commun entre les gars du soft, et les gars du hard est le PDG.
      
      Si tu as de la chance, la boite a un département système qui fait une synthèse et reste au niveau. Si tu n'en a pas, l'équipe hardware peut être moteur, et le soft rame derrière pour tenter de suivre.
      
      "La première sécurité est la liberté"
      - [^] # Re: Sceptique…
        
        Posté par lasher le 10 janvier 2014 à 17:16. Évalué à 2.
        
        Je parle en termes de recherche bien sûr, et par exemple les projets auxquels je participe en ce moment ont tous le co-design à l'avant plan : des mecs de la compilation, des mecs des runtimes, des mecs de l'archi, etc., mais aussi des mecs des applications.
    - [^] # Re: Sceptique…
      
      Posté par rewind (Mastodon) le 10 janvier 2014 à 10:48. Évalué à 6.
      
      C'est marrant, tu as exactement le point de vue du côté hardware : croire que c'est en faisant des améliorations matérielles qu'on arrivera à avoir des performances. Et sous-entendre qu'en fait, ce sont ces boulets de développeurs de compilateurs qui sont trop lents à intégrer les super nouveautés hardware va totalement dans le sens de ce que je dénonce. On ne devrait plus fonctionner comme ça.
      
      Première raison, c'est que les principaux gains de performance qui ont lieu ne sont pas dû au matériel comme tu le sous-entends mais sont principalement le fait d'avancées algorithmiques (surtout dans le domaine du calcul scientifique auquel se destine le processeur dont nous parlons), et donc améliorer le matériel, c'est bien mais le prévoir pour le logiciel qui va tourner dessus, c'est mieux.
      
      Deuxième raison, le compilateur ne fait pas tout. Oui, comme tu le dis, il faut avoir un modèle de programmation parallèle, et si le matériel pouvait éviter de figer le modèle, on s'en porterait mieux, ça permettrait de pouvoir tester plein de modèle et de choisir suivant les cas. C'est bien l'algorithmique parallèle qui va amener les principaux gains, et pour faciliter le travail algorithmique, une machine «simple» (au sens où on peut en avoir une abstraction simple, mais elle peut être très complexe en vrai) et prévisible, c'est mieux.
      - [^] # Re: Sceptique…
        
        Posté par Nicolas Boulay (site web personnel) le 10 janvier 2014 à 10:59. Évalué à 3.
        
        Je ne sais pas si tu as lu les longues interview du créateur de la PS4, mais Sony a été obsédé par la simplicité du point de vue du développeur pour sa ps4.
        
        C'est amusant de voir que Xbox a fait les choix inverse : plus de perf hard au détriment de la simplicité (eDRAM + DDR128 bits vs 256 bits GDDR5, gestion des shaders simplifiés, mémoire unifé pour éviter les copies, etc…)
        
        "La première sécurité est la liberté"
        
        [^] # Re: Sceptique…
        
        Posté par rewind (Mastodon) le 10 janvier 2014 à 12:05. Évalué à 3.
        
        Je ne sais pas si tu as lu les longues interview du créateur de la PS4, mais Sony a été obsédé par la simplicité du point de vue du développeur pour sa ps4.
        
        Non, mais je ne suis pas étonné. La PS3 était un joujou technologique superbe… mais inutilisable ! Je pense que même les derniers jeux sortis sur PS3 n'exploite pas toute la puissance potentielle de la machine.
        
        [^] # Re: Sceptique…
        
        Posté par Nicolas Boulay (site web personnel) le 10 janvier 2014 à 12:12. Évalué à 2.
        
        http://www.gamasutra.com/view/feature/191007/inside_the_playstation_4_with_mark_.php
        
        "La première sécurité est la liberté"
        
        [^] # Re: Sceptique…
        
        Posté par lasher le 10 janvier 2014 à 18:16. Évalué à 4.
        
        Bah le problème de la PS3 était que le SDK était tout pourri, de ce qu'on m'a expliqué (j'y ai jamais touché). Bon, il y avait un autre problème aussi. Un mec d'une agence US à trois lettres que je n'ai pas le droit de nommer l'avait relativement bien expliqué devant des mecs d'IBM, Intel, etc. : « Le prochain architecte qui me propose une architecture de processeur sans cache d'instruction et me force à gérer la copie des donnés et des instructions dans les scratchpads, je vais physiquement lui faire très mal. »
      - [^] # Re: Sceptique…
        
        Posté par lasher le 10 janvier 2014 à 18:13. Évalué à 4.
        
        C'est marrant, tu as exactement le point de vue du côté hardware : croire que c'est en faisant des améliorations matérielles qu'on arrivera à avoir des performances.
        
        Ce n'est absolument pas ce que je sous-entends. Et je ne dis absolument pas que les mecs du hardware sont les « gentils », et les mecs du soft les « méchants ». Je suis un mec du soft moi-même, et il se trouve que j'ai bossé (et je continue de bosser en fait) beaucoup avec les gens de la compilation, mais aussi avec des architectures pour les processeurs.
        
        Dans le cas des architectes, je peux te dire qu'au moins sur le projet auquel je participe, à chaque fois qu'on demandait une instruction en matériel, la réponse qu'on obtenait était en gros « Why do you need it? Show me the data ». Pour être honnête, l'architecture est pensée pour être extrêmement efficace énergétiquement parlant, donc si tu demandes un mécanisme de prédicat pour les conditionnelles, forcément, le monsieur, il tique. En gros, l'idée de notre projet est de justement exposer le plus de trucs en hard au logiciel, pour le que le logiciel fasse ce qu'il veut/peut avec. Ensuite, les mecs des compilateurs/runtimes retournent parler avec les architectures/mecs du hard, et leur disent ce qui définitivement nécessite d'être mis en œuvre en matériel, et ce que le logiciel peut faire efficacement sans aide matérielle.
        
        Le point de vue que j'expose est aussi celui de pas mal de chercheurs en compilation : en gros, on a des techniques, on démontre qu'elles fonctionnent soit expérimentalement, du genre « je te donne mon algo, mais pour mes expériences j'ai tout transformé à la main », soit tu fais quelque chose de relativement théorique du genre « tiens, voilà mon algo, qui est en complexité polynomiale, et je fais la preuve qu'il est correct ». De temps en temps, tu as des mecs qui l'implémentent pour de vrai dans leurs compilateurs (heureusement). Mais je dirais que c'est du ⅓/⅓/⅓ en termes de proportions quand tu lis les papiers de recherche. À ceci il faut rajouter que l'implémentation n'est pas nécessairement disponible (parce qu'elle est faite dans un compilateur proprio), ce qui force donc le mec qui veut mettre en œuvre la technique de découvrir par lui-même tout ce qui n'a pas été dit. Parfois, ce qui fait qu'une technique fonctionne bien tient autant à l'algorithme qu'aux subtilités d'implémentation.
        
        C'est par exemple ce qui s'est passé pour le papier sur la forme SSA : le papier était le premier à proposer un algorithme utilisable (i.e. en temps polynomial) pour exploiter SSA. Le truc, c'est que même si tu as trouvé le bon algo, écrire un compilateur nécessite de choisir très soigneusement ses structures de données. Il existe des papiers qui tiennent plus de l'ingénierie que de la recherche, mais qui expliquent comment un algorithme (par ex, mise sous forme SSA, puis faire un « de-SSA ») est équivalent à l'original, mais plus simple, et donc plus facile à implémenter sans bug.
        
        De plus, SSA en elle-même n'est pas une optimisation, mais elle permet d'obtenir une représentation du code qui permet les optimisations plus facilement.
        
        Sinon, les chercheurs en compilation vont bien entendu aussi te dire que les mecs du hardware te sortent des features de leur chapeau, sans forcément penser à « l'interface », ce qui rend la tâche du dév. de compilateur pour le moins ardue (par exemple : toutes les options proposées par l'Itanium en font un processeur — au moins de recherche — génial, mais avec aucun moyen « facile » de les utiliser depuis des intrinsics).
        
        Première raison, c'est que les principaux gains de performance qui ont lieu ne sont pas dû au matériel comme tu le sous-entends mais sont principalement le fait d'avancées algorithmiques (surtout dans le domaine du calcul scientifique auquel se destine le processeur dont nous parlons),
        
        Pour le calcul scientifique, j'ai déjà dit ailleurs qu'entre deux générations de processeurs, il fallait souvent ré-adapter le code pour la nouvelle architecture (les timings étant différents pour certaines séquences d'instruction, la hiérarchie mémoire ayant changé, etc.), ce qui se fait évidemment de façon logicielle. Cependant, surtout dans le cas des x86, oui, la venue des moteurs out-of-order, couplée à la présence de préchargeurs mémoire en matériel fait que, très souvent, il n'est plus nécessaire d'insérer à la main les trucs du genre _mm_prefetch(address).
        
        Enfin, il est évident que le choix de la bonne structure de donnée et du bon algorithme sont les sources fondamentales de performance. Ce qui est aussi évident cependant, c'est que si ton implémentation utilise le « bon » algorithme, mais que les constantes élidées de ton algo en O(N) ou O(N log N) sont trop grosses, au final pour beaucoup des programmes scientifiques en question et qui tournent sur des workstations ou des petits clusters, la différence avec des algos à la complexité moins bonne mais mieux optimisés sera minime. Même sur les gros calculateurs, si ton programme est visiblement mal optimisé, tu risques de te prendre un refus par ses admins, parce que le temps machine est précieux (et que ça bouffe en électricité).
        
        La raison pour laquelle les architectes rajoutent des fonctionnalités en matériel est évidemment qu'elles sont considérées comme utiles par les mecs du soft. Les instructions AltiVec ou SSE sont limitées en termes d'utilité pour les programmes en général, mais pour écrire des BLAS efficaces, si tu n'utilises pas ces instructions sur PowerPC ou x86, tu perds potentiellement entre 20 et 50% de performance (je prends en compte le fait que ton code ne fera pas que des multiplications de matrices).
        
        Deuxième raison, le compilateur ne fait pas tout. Oui, comme tu le dis, il faut avoir un modèle de programmation parallèle, et si le matériel pouvait éviter de figer le modèle, on s'en porterait mieux, ça permettrait de pouvoir tester plein de modèle et de choisir suivant les cas. C'est bien l'algorithmique parallèle qui va amener les principaux gains, et pour faciliter le travail algorithmique, une machine «simple» (au sens où on peut en avoir une abstraction simple, mais elle peut être très complexe en vrai) et prévisible, c'est mieux.
        
        Ben je suis dans un groupe de recherche qui justement cherche à proposer un modèle d'exécution¹ adapté aux manycores. En gros notre but est de fournir une sorte de vision un peu abstraite d'un « assembleur parallèle ». Ensuite, si tu veux continuer à utiliser OpenMP¹, mais qu'il génère notre truc, on est très content aussi (il faut juste quelqu'un qui écrive le compilateur qui va bien …).
        
        Le gros problème est effectivement (comme je le disais dans un commentaire plus haut) un manque de communication entre les fabricants de processeurs/machines parallèles, et les gens des logiciels systèmes (OS, Runtime, compilateurs). La communauté scientifique en prend lentement conscience, à mesure que 50 000 machines parallèles voient le jour, chacune avec leur modèle d'exécution, chacune avec leur modèle de programmation.
        
        [1] Je dis bien exécution et pas programmation. Par exemple, le modèle de von Neumann est un modèle d'exécution séquentiel.
        [2] Voilà, ça c'est un modèle de programmation. :-) … Bon, il a aussi un modèle d'exécution, mais c'est pas (trop) important pour le programmeur.
        
        [^] # Re: Sceptique…
        
        Posté par Nicolas Boulay (site web personnel) le 12 janvier 2014 à 22:38. Évalué à 5.
        
        J'ai connu des monstres du codage de compilateur, qui finalement, ne connaissait pas grand chose sur les architectures cpu moderne. Les algo retenus par les informaticiens, prennent en compte, en général un temps d'accès mémoire uniforme. Ce qui n'a aucun sens : on se prend un facteur 100, si on ne fait pas attention.
        
        A l'inverse, j'ai vu des codeurs hardwares, que cela ne dérange pas de mettre des bits de contrôles de 2 périphériques différents sur un même octet mémoire, ce qui rend l'écriture de drivers "amusant", surtout si 2 cpus différents sont censé y accédé avec des Os différents.
        
        J'ai vu aussi des modes automatique de mise en sommeil qui peuvent perdre des données, mais consomme moins, sans interruption pour gérer la sauvegarde de contexte. Le logiciel doit alors simuler le comportement du hardware, super simple !
        
        "La première sécurité est la liberté"
        
        [^] # Re: Sceptique…
        
        Posté par Nicolas Boulay (site web personnel) le 12 janvier 2014 à 23:07. Évalué à 2.
        
        "Dans le cas des architectes, je peux te dire qu'au moins sur le projet auquel je participe, à chaque fois qu'on demandait une instruction en matériel, la réponse qu'on obtenait était en gros « Why do you need it? Show me the data ». Pour être honnête, l'architecture est pensée pour être extrêmement efficace énergétiquement parlant, donc si tu demandes un mécanisme de prédicat pour les conditionnelles, forcément, le monsieur,"
        
        Un système de prédicat n'est pas une simple instruction. En plus un concepteur de cpu se met rarement à niveau système. Il faut voir la tronche d'un SoC de téléphonie, c'est plein de bloc hyper complexe (plusieurs cpus, plusieurs type de cpus, une centaine de bloc). Il ne voit pas que rajouter une instruction de cryptage, qui lui bouffe son budget de surface de consommation, évite d'ajouter un bloc externe sur Soc qui rajoute un driver, de la latence.
        
        "La première sécurité est la liberté"
    - [^] # Re: Sceptique…
      
      Posté par khivapia le 10 janvier 2014 à 15:11. Évalué à 3.
      
      Pire, la génération automatique d'instructions vectorielles (…) reste extrêmement restreinte comparée à l'implémentation d'Intel dans ICC.
      
      C'est de moins en moins vrai semble-t-il, pour la vectorisation au moins. Le compilateur d'Intel est toujours devant certes, mais gcc a bien remonté la pente.
      
      http://slashdot.org/topic/bi/comparing-c-compilers-parallel-programming-performance/
- [^] # Re: Sceptique…
  
  Posté par lasher le 09 janvier 2014 à 23:47. Évalué à 6.
  
  Déjà, il est bon de noter que du à l’architecture, les OS conventionnels ne peuvent tourner sur les 256 cores (l’interconnect ne le supporterai pas).
  
  C'est vrai. En même temps, je ne vois pas pourquoi je voudrais forcément que l'OS tourne sur l'intégralité des cœurs.
  
  Linux tourne sur seulement 4 cœurs, et les autres sont accessibles via une interface particulière, un peu comme on enverrai des shaders sur un gp-gpu ou un firmware sur un microcontrolleur.
  
  Oui, car les quatre cœurs en question sont les seuls à pouvoir gérer les I/O (entre autres).
  
  Donc déjà ça veut dire que vos applications traditionnelles (erlang, go, openmp…) ne vont pas profiter du cluster sans effort.
  
  Oui, il faut utiliser une sorte de dialecte de C/C++ fournit avec le processeur. De ce qu'on m'a dit, programmer efficacement avec n'est pas sans peine. Cependant pour être honnête, c'est aussi vrai pour Cuda/OpenCL/OpenACC/HMPP/ etc. C'est même vrai pour les processeurs Intel/AMD/etc., où sans qu'on sache vraiment quand ni comment, certains aspects micro-architecturaux font qu'une série d'instructions assembleur vont se révéler très efficaces, mais avec la nouvelle version du Core i7 (par exemple), on se retrouve avec une performance unicœur plus pourrie. Pourtant, sur le papier y'a les mêmes specs : 32Kio de L1D, 256Kio de L2, 8Mio de L3 partagé… Sauf que non, le L3 n'est plus un cache avec une file d'attente, il s'agit désormais d'un cache de type NUCA (Non-Uniform Cache Access), donc segmenté, et que désormais la file d'attente est elle aussi segmentée, et … Bref. CUDA est encore pire, car même si on a accès au jeu d'instruction assembleur (PTX), il s'agit d'un langage « virtuel », et d'une carte Nvidia à l'autre la performance d'une séquence d'instructions PTX « optimisante » peut se retrouver « pénalisante ».
# Publireportage

Posté par Fabrice Devaux le 09 janvier 2014 à 12:53. Évalué à 9.

Merci pour cette dépêche "informative"…
# Hardware et software

Posté par alpha_one_x86 (site web personnel) le 09 janvier 2014 à 16:48. Évalué à 8.

Avec le même matos, il y as 2ans je consomer 85W, et maintenant 55W, ce qui as changé c'est le noyau et KDE qui ont été maj… bosser le matos c'est bien, encore faut t'il que la partie logiciel suive (soit optimisé, ne réveille pas tout le temps le cpu, …).

Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
# « les TIC pèsent, avec 1 500 TW-heure d'électricité par an, pour 10 % de la production mondiale. »

Posté par oao le 09 janvier 2014 à 20:26. Évalué à 5.

C'est faux. La consommation mondiale d'électricité est de 144 TWh/an. On est donc de l'ordre du pour-cent. Donc très faible. Je pense que les auteurs de l'article cité ont grossièrement mélangés énergie et électricité.

Par ailleurs les puces consomment de moins en moins à puissance égale, à cause de changements d'architectures et de la hausse de la finesse de gravure, et donc la loi de Moore n'implique pas une multiplication par deux de la consommation tous les deux ans. Au contraire je tape ce message d'un ordinateur qui a une autonomie de 13h, ce qui aurait été inimaginable il y a quelques années. Et ce n'est même pas un ARM.
- [^] # le titre était trop long
  
  Posté par Maclag le 09 janvier 2014 à 21:44. Évalué à 2.
  
  Les plus attentifs auront bien sûr remplacé 144 par 144,000.
  
  Et 1%, c'est aujourd'hui. Quand on aura remplacé 20% du parc auto mondial par des voitures électriques, on en reparle…
  - [^] # Re: le titre était trop long
    
    Posté par Jak le 10 janvier 2014 à 13:20. Évalué à 3.
    
    Pourquoi ?
    
    144=144,000=144000/1000
    - [^] # Re: le titre était trop long
      
      Posté par ariasuni le 10 janvier 2014 à 23:55. Évalué à 2.
      
      Je pense que par 144,000, il voulait écrire 144 000.
      
      Écrit en Bépo selon l’orthographe de 1990
      - [^] # Re: le titre était trop long
        
        Posté par Jak le 11 janvier 2014 à 17:01. Évalué à 1.
        
        J´en suis même convaincu.
        
        [^] # Re: le titre était trop long
        
        Posté par ariasuni le 11 janvier 2014 à 18:16. Évalué à 2.
        
        J´en suis même convaincu.
        
        Utiliser un accent aigu pour faire ses apostrophes, c’est pas bien. Et c’est moche. :p
        
        Écrit en Bépo selon l’orthographe de 1990
# Trente ans

Posté par Michaël (site web personnel) le 10 janvier 2014 à 00:03. Évalué à -1.

En 30 ans l'évolution informatique a été fulgurante : La fréquence des processeurs a grimpé d'un facteur mille, pour passer du Mega au Giga Hertz

Des processeurs cadancés à 1Mhz, c'était pas plutôt il y a 15 ans?

D'ailleurs j'ai lu ça cet après-midi, sur PSX: http://programmers.stackexchange.com/questions/49758/is-ocaml-any-good-for-numerical-analysis/223595#223595
- [^] # Re: Trente ans
  
  Posté par François Trahay (site web personnel) le 10 janvier 2014 à 10:44. Évalué à 4.
  
  Des processeurs cadancés à 1Mhz, c'était pas plutôt il y a 15 ans?
  
  Le Pentium III date d'il y a 15 ans (1999). Il tournait à 450 MHz.
  - [^] # Re: Trente ans
    
    Posté par khivapia le 10 janvier 2014 à 15:02. Évalué à 6.
    
    Des processeurs cadancés à 1Mhz, c'était pas plutôt il y a 15 ans?
    Le Pentium III date d'il y a 15 ans (1999). Il tournait à 450 MHz.
    
    S'il n'a pas confondu MHz et GHz, il a dû se prendre un sacré coup de vieux !
    - [^] # Re: Trente ans
      
      Posté par Michaël (site web personnel) le 10 janvier 2014 à 18:09. Évalué à 2.
      
      Oui, je me suis pris un sacré coup de vieux! J'ai possédé un Motorola 68000 et un 80286, mais j'avais oublié que c'était il y a si longtemps!
      - [^] # Re: Trente ans
        
        Posté par Thomas Debesse (site web personnel) le 10 janvier 2014 à 23:14. Évalué à 4.
        
        En fait les expériences des uns ou des autres peuvent être étonnantes : j'ai eu mon 8086 en 1999, mon Z80 en 2001, mon 386 en 2002, mon 68k en 2003, et le commodore 64 en 2007… Pour moi, tout ça ne me semble pas si vieux ! :)
        
        D'ailleurs, le 68k (dans sa TI V200) est posé à 10cm de mon clavier, alors que j'écris ce commentaire.
        
        ce commentaire est sous licence cc by 4 et précédentes
# Double précision

Posté par Sytoka Modon (site web personnel) le 10 janvier 2014 à 08:14. Évalué à 2.

Si on veut concurrencer le x86_64 sur les calculateurs, il faut avoir une bonne unité de calcul flottant en double précision ainsi qu'une interconnexion efficace (par infiniBand ou équivalent). J'ai rien lu concernant la double précision dans la dépêche or c'est souvent le composant qui coûte cher et qui fait une partie de la différence entre les CPU intel haut et bas de gamme (en plus de capacité IO plus importante aussi).
- [^] # Re: Double précision
  
  Posté par lasher le 10 janvier 2014 à 18:26. Évalué à 3.
  
  Heu, la FPU pour les processeurs Intel hauts et bas de gamme en termes de micro-architecture, je pige pas trop bien.
  
  Disons que j'ai un Core i5. Il y a une version haut de gamme, avec 8Mio de cache L3, 3.2GHz de vitesse d'horloge, etc. Il y a une version « bas de gamme », avec 3Mio de cache L3, et 1.8GHz. Il y a une différence de peut-être ~50$ entre la version haut de gamme et l'autre. Maintenant, si je considère un Core i7 : c'est exactement la même micro-architecture au niveau d'un cœur, ce qui inclue la FPU. Par contre, on passe de 2 à 6 cœurs, et de 8Mio à 12Mio de cache L3. Et le prix est multiplié par deux ou trois par rapport au haut de gamme du Core i5… Comme le nombre de cœurs en fait.
  - [^] # Re: Double précision
    
    Posté par Sytoka Modon (site web personnel) le 10 janvier 2014 à 22:04. Évalué à 1.
    
    Sur les Xeon haut de gamme par exemple, il y a plus de bus d'accès à la mémoire. C'est ce qui permet à SGI par exemple de faire des machines avec 4096 coeurs qui restent performant.
    - [^] # Re: Double précision
      
      Posté par lasher le 10 janvier 2014 à 22:34. Évalué à 3.
      
      Oui pour les bus, mais tu parles de quelque chose de différent là. Ce qui différencie un Xeon (en règle générale) de son équivalent « de bureau », c'est la possibilité de le faire fonctionner en multi-processeur (SMP). Ça veut dire entre autres qu'Intel doit rajouter un peu de logique pour gérer le protocole de cohérence de cache inter-processeur (MESIF). Il faut aussi rajouter de la logique pour gérer QPI (quick path interconnect), la techno d'accès NUMA d'Intel (qui concurrence HyperTransport d'AMD).
      
      Sinon je veux juste vérifier ce que tu veux dire par « plus de bus d'accès à la mémoire ». Est-ce qu'on parle du bus par processeur que je viens d'évoquer ? Ou bien parles-tu de plusieurs bus par processeur ? Je sais que sur certains processeurs d'AMD (Bulldozer etc.) il y a effectivement deux bancs mémoire par proc, mais je n'en avais pas entendu parler pour Intel…
      - [^] # Re: Double précision
        
        Posté par claudex le 11 janvier 2014 à 09:06. Évalué à 4.
        
        Ce qui différencie un Xeon (en règle générale) de son équivalent « de bureau », c'est la possibilité de le faire fonctionner en multi-processeur (SMP)
        
        J'aurais surtout dit que c'était le cache et l'ECC qui différenciait le Xeon des autres vu qu'il y en a quand même pas mal dans la gamme qui ne gèrent pas le multiprocessor.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Double précision
        
        Posté par lasher le 11 janvier 2014 à 22:43. Évalué à 2.
        
        Oui pour l'ECC, mais que veux-tu dire pour le cache ?
        
        [^] # Re: Double précision
        
        Posté par claudex le 12 janvier 2014 à 09:23. Évalué à 3.
        
        Je me suis trompé, j'étais persuadé que le bas de gamme Xeon avait plus de cache que le haut de gamme i7 mais c'est équivalent.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# environnement... blabla

Posté par RD le 11 janvier 2014 à 13:45. Évalué à 3.

Lorsque des centres comme ceux d'OVH ou Google auront compris qu'avec cette puce ils pourront avoir 10 fois plus de machines à consommation égale ou consommer 10 fois moins pour la même puissance de calcul, leurs calculs seront vite faits : « Business is money ! »

Le choix est illusoire, bien évidemment ces entreprises augmenteront la puissance à consommation égale.
L'"efficacité" n'aura été qu'un miroir pour accroitre la consommation. D'autre part ces processeurs se rajouteront au marché mondial sans véritablement remplacer les anciens.
Donc non, aucune préoccupation environnementale n'a lieu d'être ici (et encore moins d'enthousiasme) (todo: attacher la liste des innovations technologiques promettant bien haut des bénéfices d'économies énergétique)

Note: passer de 1 processeur à 100 W/h en 2014 à 200 processeurs à 5 W/h en 2020 correspond à une augmentation par 10 de la consommation et aucunement à une réduction, or c'est bien la caractéristique observable de la consommation de masse.
(c'est un calcul en apparence trivial pour qui jongle de Ghz à To, mais ironiquement et malgré son importance, c'est un calcul pour trop ignoré)
- [^] # Re: environnement... blabla
  
  Posté par NeoX le 12 janvier 2014 à 09:29. Évalué à 2.
  
  sans compter les histoires d'architectures.
  
  Actuellement c'est les instructions x86 et x86_64 qui dominent sur les serveurs,
  si demain on veut changer d'infra par cette infra "basse conso" à puissance égale, c'est tout le parc logiciel qui faut changer,
  meme si dans le cas de serveur à base de linux il est probable qu'il suffise de recompiler l'ensemble de la pile.
  
  s'il suffisait de cela, y a longtemps qu'on aurait des serveurs kimsufi ou dedibox sur une base ARM dual ou quadcore, 2Go de RAM, 32Go de SSD avec une conso de 5W/h (comme nos telephones)
  hors ce n'est pas le cas.
  - [^] # Re: environnement... blabla
    
    Posté par Zenitram (site web personnel) le 12 janvier 2014 à 16:33. Évalué à 3.
    
    Une tonne de machines ne font tourner que du bête PH/MySQL, donc une distro recompiée et basta.
    Ou est donc le problème?
    Pour le moment, il n'y a pas d'offre, donc difficile d'acheter.
    Faudrait voir le rapport total perfs/cout.
    - [^] # Re: environnement... blabla
      
      Posté par Nicolas Boulay (site web personnel) le 12 janvier 2014 à 22:43. Évalué à 1.
      
      Pour concurrencer intel, il faut déjà pouvoir vendre qq dizaines millions de pièce.
      
      "La première sécurité est la liberté"
      - [^] # Re: environnement... blabla
        
        Posté par Zenitram (site web personnel) le 13 janvier 2014 à 07:27. Évalué à 2.
        
        Si c'est interessant industriellement, je n'imagine aucun problème pour cet ordre de grandeur, surtout avec un nom comme ARM.
        Ce n'est pas le problème.
        
        [^] # Re: environnement... blabla
        
        Posté par Nicolas Boulay (site web personnel) le 13 janvier 2014 à 09:23. Évalué à 2.
        
        Je pensais que tu parlais d'un petit nouveau. Les serveurs ARM sont déjà annoncés.
        
        "La première sécurité est la liberté"
  - [^] # Re: environnement... blabla
    
    Posté par Antoine le 12 janvier 2014 à 23:58. Évalué à 4.
    
    s'il suffisait de cela, y a longtemps qu'on aurait des serveurs kimsufi ou dedibox sur une base ARM dual ou quadcore, 2Go de RAM, 32Go de SSD avec une conso de 5W/h (comme nos telephones)
    
    Ce qui compte, c'est le rapport performances / consommation, pas la consommation absolue.
    
    (je passe sur l'erreur classique consistant à annoncer une consommation en W/h :-)
    - [^] # Re: environnement... blabla
      
      Posté par NeoX le 13 janvier 2014 à 00:42. Évalué à 1.
      
      Ce qui compte, c'est le rapport performances / consommation, pas la consommation absolue.
      quand je vois ce que j'arrive à faire tourner avec mon telephone (jeu avec 3D)
      pour la consommation que cela represente…
      
      je me dis qu'on n'a pas à se plaindre.
      - [^] # Re: environnement... blabla
        
        Posté par Antoine le 13 janvier 2014 à 01:46. Évalué à 3.
        
        Et tu crois que le GPU a quoi que ce soit à voir avec la puissance du CPU ?
  - [^] # Re: environnement... blabla
    
    Posté par Zenitram (site web personnel) le 13 janvier 2014 à 07:39. Évalué à 4.
    
    une conso de 5W/h (comme nos telephones)
    
    Nos téléphones consomment plutôt 5W, non?
    Et des batteries, ça serait pas plutôt en Wh (ou plus généralement A.h), soit des Watt multiplié par des heures et non divisisé?
    Je serai curieux que tu m'expliques la signification de Watts divisé par des heures dans un premier temps, puis la signification quand appliqué à une consommation ;-).
    Bon, OK, Orange n'était pas mieux avec des pub de débit ADSL en Mo…
    
    PS : c'est pas plutôt 0.5W?
# Et les tubes !

Posté par Domi le 14 mars 2014 à 16:34. Évalué à 0.

Il ne faut pas oublier que la miniaturisation a commencé avec les tubes.

Le premier ordinateur de l'histoire fut réalisé avec des tubes, et même s'il occupait tout un immeuble ricain, c'était déjà de la miniaturisation.

Pour le comprendre, il suffit de comparer un orgue Hammond à tubes, lequel ne prend pas plus de place dans un salon qu'un piano, avec son ancêtre, le telharmonium et ses 200 tonnes : https://fr.wikipedia.org/wiki/Telharmonium

Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
# Home-Box PLUS avec Kalray

Posté par christianmartin le 14 mars 2014 à 21:58. Évalué à 0.

Merci de cette synthese enthousiasmante

Concernant les applications possibles, une QUESTION :
Es ce qu'une MEGA Home-Box PLATEFORME DE SERVICES a base de ce MPPA combinant
- Fonctions d'encodage - Decodage Videos HD (HEVC, …)
- Jeux (RA, 3D,…)
- Fonctions de fusion de donnees capteurs (Maison (Surveillance, optimisation) et capteurs de personnes ( Body Health)

serait une bonne utilisation de la technologie et une bonne strategie face aux acteurs existants (Arm, Broadcom, …) ?

Christian
# processesurs hybrides

Posté par Domi le 15 mars 2014 à 23:28. Évalué à 0.

Une autre source potentielle d'économie d'énergie et de gain d'efficacité serait de faire des processeurs hybrides. Aujourd'hui, la tendance est aux multicoeurs où tous les coeurs sont identiques, mais je verrais très bien un multicoeur avec 1 coeur basse consommation et basse fréquence pour le standby, un coeur dédicacé pour le hardware, un coeur générique pour le GUI, et un coeur DSP pour les calculs.

Il faudrait recompiler les programmes pour que leurs différentes parties aillent sur le bon coeur, mais rien d'impossible. Et beaucoup d'économies d'énergies car si un centre de calcul consomme des MW, tous les ordinateurs d'un pays consomment bien d'avantage. De plus, les algorithmes DSP ont prouvé leur supériorité en terme d'efficacité pour tout ce qui est calcul depuis plusieurs décennies maintenant. Avec l'arrivée de ces processeurs hautement parallèles qui arrivent, c'est certainement une nouvelle page de l'informatique qui commence.

Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.