Intel Atom

[Neo_13]

Les nouveaux cpu ultra hyper mega basse consommation Silverthorne et Diamondville qui fabriquent eux memes leur courant sont en train de passer sous les feux de la rampe...

Et apparement, c'est hyper navrant sous superpi... Vla le bench . Bon les résultats du coup ne me paraissent pas étonnant vu le peu qu'on sait sur les bestiaux.

par contre, la différence de conso entre l'ICH7 et l'ICH9 est tellement importante ? (cf l'ich sur la mini itx)

[Paul Verveine]

en même temps on peut oublier superpi, c'est plus pour les MID et tous les engins mobiles type ifone

[Dandu]

pour l'ICH, je pense que ça vient du chipset, un ICH ça passe avec un i945 ?

accessoirement, il supporte l'IDE et pas le 9, je pense.

et l'IDE est plus courant sur les petits appareils (SSD, par exemple) et consomme nettement moins (la différence est importante sur les disques 2,5 pouces)

Enfin, en même tmpes l'ICH8 Mobile supporte aussi l'IDE, mais bon.

[Neo_13]

Heu, dans la mesure ou intel fait un mini itx, difficile de pas voir des benchs pc like

et faut oublier superpi, pas uniquement en mobile, faut l'oublier, c'est tout

voilà, on en parle plus, il n'existe plus

pour l'ICH, je pense que ça vient du chipset, un ICH ça passe avec un i945 ?

accessoirement, il supporte l'IDE et pas le 9, je pense.

et l'IDE est plus courant sur les petits appareils (SSD, par exemple) et consomme nettement moins (la différence est importante sur les disques 2,5 pouces)

Enfin, en même tmpes l'ICH8 Mobile supporte aussi l'IDE, mais bon.

ben par exemple l'ich 8 mobile... le 7 est ancien déjà.

Pour le SATA, ça ressemble à une orgie de watt plus qu'à une raison physique

[newbie06]

Perso les bench dont on ne peut pas voir les sources, je n'aime pas des masses, surtout que SuperPI a surement ete compile pour du OoO...

Je trouve neanmoins le chiffre interessant et le positionnement relatif edifiant.
Enfin c'est pas comme si on n'y attendait pas

[Neo_13]

Perso les bench dont on ne peut pas voir les sources, je n'aime pas des masses, surtout que SuperPI a surement ete compile pour du OoO...

Je trouve neanmoins le chiffre interessant et le positionnement relatif edifiant.
Enfin c'est pas comme si on n'y attendait pas

SuperPi a été compilé, c'est sûr...

Ce qui est sûr aussi c'est qu'il n'a aucune optimisation et donc le OoO s'en sort mieux.

[Oxygen3]

mmm...

http://www.hardware.fr/news/9473/she...fications.html
Je suis plutot certain que c'est la même plateforme qui est dans les fameux Real Private Server de OVH

[Neo_13]

faut voir... mais ça semble louche... ils devaient prendre des celeron core

[newbie06]

Ce qui est sûr aussi c'est qu'il n'a aucune optimisation et donc le OoO s'en sort mieux.

Que veux-tu dire par la ?

On trouve ca dans le code:

-fast -tp px -Mbuiltin -Minline=size:1000 -Mnoframe -Mnobounds -Mcache_align -Mdalign -Mnoreentrant
pgcc 3.2-3
Linux OS
 Version 2.0 of the super_pi for %s
 Fortran source program was translated into C program with version 19981204 of
 f2c, then generated C source program was optimized manually.
 %s with compile option of "%s" was used for the
 compilation.

A mon sens y'a eu un minimum de boulot... a l'epoque
Pour info c'est pas Pentium gcc mais Portland Group cc et le -tp px signifie "generate 32-bit code that is usable on any x86 processor-based system". Donc a priori pas vraiment de scheduling specifique sauf que pgcc est concu pour des x86 post p2...

[Neo_13]

Que veux-tu dire par la ?

On trouve ca dans le code:

-fast -tp px -Mbuiltin -Minline=size:1000 -Mnoframe -Mnobounds -Mcache_align -Mdalign -Mnoreentrant
pgcc 3.2-3
Linux OS
 Version 2.0 of the super_pi for %s
 Fortran source program was translated into C program with version 19981204 of
 f2c, then generated C source program was optimized manually.
 %s with compile option of "%s" was used for the
 compilation.

A mon sens y'a eu un minimum de boulot... a l'epoque
Pour info c'est pas Pentium gcc mais Portland Group cc et le -tp px signifie "generate 32-bit code that is usable on any x86 processor-based system". Donc a priori pas vraiment de scheduling specifique sauf que pgcc est concu pour des x86 post p2...

Jentend par là : pas de SSE, pas d'opti pour remplir le pipeline, pas d'agencement spécifique pour optimiser le comportement des OoO etc...

Un code x87 basique, ie représentatif de ... plus rien, en fait.

[Foudge]

Ceci dit, beaucoup (tous ?) de benchmarkeurs utilisent SuperPI mod 1.5
Cette version récemment recompilée signifie donc que les sources ont donc bien circulé et qu'un compilateur plus récent a été utilisé (avec quelles optimisations ?).
Ensuite, SuperPI reste SuperPI et n'est représentatif que de SuperPI.

[newbie06]

Ceci dit, beaucoup (tous ?) de benchmarkeurs utilisent SuperPI mod 1.5
Cette version récemment recompilée signifie donc que les sources ont donc bien circulé et qu'un compilateur plus récent a été utilisé (avec quelles optimisations ?).

Pas evident du tout que les sources aient circule. Un bon coup de desassembleur, quelques modifs ici et la, un coup de packer, et voila... Si j'ai bien compris ce mod existe pour tenter de contourner des problemes de triche.

Ensuite, SuperPI reste SuperPI et n'est représentatif que de SuperPI.

Comme tous les benchmarks

Il n'y aurait jamais *le* benchmark, source ou pas source.

[Franck@x86]

le -tp px signifie "generate 32-bit code that is usable on any x86 processor-based system". Donc a priori pas vraiment de scheduling specifique sauf que pgcc est concu pour des x86 post p2...

Non, ça signifie juste qu'il utilise du code x86 standard, sans faire appel à des instructions apparues plus tard, du style cmov.
Les optims "OOO" ou "non OOO", c'est du gros flan. SuperPi rame parce que le proc est in-order, et un proc in-order est plus lent qu'un proc ooo, faut pas aller chercher plus loin.

[Neo_13]

Non, ça signifie juste qu'il utilise du code x86 standard, sans faire appel à des instructions apparues plus tard, du style cmov.
Les optims "OOO" ou "non OOO", c'est du gros flan. SuperPi rame parce que le proc est in-order, et un proc in-order est plus lent qu'un proc ooo, faut pas aller chercher plus loin.

Nie tu que de réordonnancer judicieusement les instructions fait exploser les performances (un bon 30% me parait pas hors d'atteinte sur un in order) ?

Sans aller jusqu'à faire OoO=IO des gains importants sont prévisibles par une compilation soigneuse (dans els deux cas d'ailleurs)... Exemple : les gains entre deux versions successives d'ICC sur itanium...

[Franck@x86]

Nie tu que de réordonnancer judicieusement les instructions fait exploser les performances (un bon 30% me parait pas hors d'atteinte sur un in order) ?

Non bien sûr. Comme je l'ai dit dans un autre topic, un entrelacement judicieux des instructions pouvait pratiquement doubler la vitesse d'exécution d'une routine sur le P5.
Maintenant, je n'ai jamais vu un compilo prendre la peine de faire ce boulot (d'après Fefe il en a existé cependant). Même Intel s'est pas investi dans des optims in order pour son P5, car l'OOO était déjà dans les cartons.

Visual 5 ou 6 proposait une optim "P6", censée remplacer certains "test ... jmp" par un cmov. Rien à voir avec une quelconque optim OOO, et d'ailleurs l'optim "P5" ne pairait pas plus les instructions que sans l'optim. Bref, c'est des salades, les éditeurs de compilos ont vite compris que la meilleure chose à faire était de générer un code x86 standard et laisser faire le proc.
Ca vaut pour l'OOO mais aussi pour les prefetch. Les instructions de prefetch existent depuis 10 ans, pas un compilo ne s'en sert. Pas la peine, maintenant y'a les prefetchers hardware beaucoup plus efficaces.

[Neo_13]

Oui, mais là, on est in order et donc le hard ne fait plus le boulot...

D'autre part les compilo sont capable d'optimisation pour améliorer l'efficacité de l'OoO et de la prédiction de branchements, aujourd'hui. donc leur compétence sont extensibles

Et ICC optimise pour itanium, donc la compétence existe au moins pour ICC.

[Franck@x86]

D'autre part les compilo sont capable d'optimisation pour améliorer l'efficacité de l'OoO et de la prédiction de branchements, aujourd'hui.

La seule optim envisageable serait d'aller dans le sens des units de prédiction statiques, qui considèrent par exemple qu'une branche est prise par défaut. Dans ce cas, si le code de la branche prise suit directement la branche, il est déjà dans le cache code (et encore, sur les derniers procs je suis pas certain que l'impact soit flagrant).

[newbie06]

Rien...

[Franck@x86]

Le retour du in-order sur une archi parallèle comme Larabee, OK.
Sur un proc généraliste par contre ça signifie un retour en arrière de 10 ans, donc faut pas s'attendre à un truc qui avionne dans un bench.

Enfin c'est pas le but visé non plus, ma montre fait bien ce pour quoi elle a été faite, mais elle rame à super pi

[Neo_13]

bien sûr...

Je souhaitais juste souligné qu'en 10 ans les compilo ont progressé...

Et est ce que ST existera en MP ? façon PPC440 dans blue gene l/2

[fefe]

bien sûr...

Je souhaitais juste souligné qu'en 10 ans les compilo ont progressé...

Ah bon ? Personellement je n'ai pas vraiment l'impression que les compilos aient evolue de maniere significative dans les 15 dernieres annees (hormis la compilation VLIW). Mais je suis pres a ecouter les exemples (inutile de parler de vectorisation, Cray le faisait largement aussi bien dans les annees 80).

[Franck@x86]

à ce propos :
http://scr3.golem.de/?d=0803/Intel-A...On&a=58212&s=1

[Neo_13]

Ah bon ? Personellement je n'ai pas vraiment l'impression que les compilos aient evolue de maniere significative dans les 15 dernieres annees (hormis la compilation VLIW). Mais je suis pres a ecouter les exemples (inutile de parler de vectorisation, Cray le faisait largement aussi bien dans les annees 80).

j'avoue qu'en Cray, je suis moyen moins...

Donc, oui je pensais à l'expérience d'in order acquise par VLIW, à la vectorisation et aux optimisations obtenues avec les -O3 et consorts (réordonnancement pour permettre d'accroitre les perfs de la prédiction de branchement et d'OoO en fonction du -march cible).

Si je compile avec GCC 1.0 en -O3 et avec GCC 4 en -O3 (pour la meme archi bien sûr) j'aurais les memes perfs ? (J'ai pas essayé)

[newbie06]

Ah bon ? Personellement je n'ai pas vraiment l'impression que les compilos aient evolue de maniere significative dans les 15 dernieres annees (hormis la compilation VLIW). Mais je suis pres a ecouter les exemples (inutile de parler de vectorisation, Cray le faisait largement aussi bien dans les annees 80).

Donc tu veux dire que les seuls gains sont dûs aux optimisations spécifiques à telle ou telle architecture et version de cible ? Ca me rappelle l'intervention d'une prof au cours d'une présentation de stage de DEA que j'encadrais : "Je ne vois pas l'intérêt de parler d'allocation de registres, tout est déjà connu".

Bon autant dire que je pense que ce tu dis est faux :
1. l'ingénierie logicielle associée aux compilos a pas mal évolué (SSA par exemple ; OK c'est pas neuf, mais ça commence seulement à être massivement utilisé)
2. les compilos VLIW? tout ou presque a été fait dans les années 85 (Bulldog) ; massivement industrialisé par TI dans les années 97 pour ses DSP C6x
3. prends les bibliographies de "Engineering a Compiler" ou "Optimizing Compilers for Modern Architectures" et regarde les dates de publication
4. l'évaluation partielle s'est développée surtout après 97 et peut apporter des gains très intéressants.

On peut entrer dans les détails. Un exemple, il a été montré récemment que l'allocation de registres sur un program SSA par coloriage de graphe était un problème polynomial. Donc ça va surement commencer à débarquer dans les compilos.

Je pense que le point important c'est le point 1 : peu à peu tous les compilos utilisent des infrastructures leur permettant d'utiliser massivement des optimisations assez difficiles à implémenter.

Désolé, ça m'agace toujours quand on dit qu'un domaine n'évolue plus

[fefe]

Desole, mais la recherche en compilation a surement avance, mais les compilos x86 eux n'ont pas avance particulierement (on va dire que j'ignore tout des compilos en dehors de x86 et IA64 dans une moindre mesure). Pour les compilos VLIW, je suis particulierement surpris, en particulier par les performances entre les premieres et dernieres generations de compilo pour Itanium ou la il y a eu unreel progres et ce n'etait pas que des bug fix. Je ne vois pas pourquoi la premiere generation etait si lamentable en calcul entier si tout avait deja ete invente, mais je suppose qu'il est tout a fait possible qu'Intel et HP aient fait un boulot lamentable la dessus au debut.

Bien entendu un gcc moderne donnera des programmes plus rapides sur les machines modernes, une des principales raisons est qu'il corrige beaucoup de cas qui sont connus pour causer des defauts de performance sur ces archi (genre alignement du code pour les decodeurs de telle ou telle machine, aliasing... mais je n'appelle pas ca des avancees particulierement importantes PS: je ne dis pas que c'est la seule chose qui ait change, mais cote gains visible de perf c'est une contribution majeure...).

Pour ce qui est d'un domaine qui n'avance pas, je peux t'en donner un qui n'a pas evolue beaucoup depuis 1995: l'archi des CPUs. Les dernieres "inventions majeures" qui aient fini dans des CPUs modernes datent d'a peu pres cette periode, et pourtant la recherche n'a pas arrete de publier. Pour les compilateurs x86, je suis desole tes exemples ne me convainquent pas particulierement... Comme pour l'archi des CPUS l'ingenierie a avance, mais je ne vois pas d'avancees particulierement importante.

[fefe]

Désolé, ça m'agace toujours quand on dit qu'un domaine n'évolue plus

Et moi ca m'agace quand on me misquote: pas d'avancee significative different de n'evolue plus

[fefe]

Je retire une partie de ce que j'ai dit, la compilation guidee par profiling a fait de gros progres en x86, mais reste assez peu utilisee (utilisable ?) dans un contexte generaliste. En revanche l'extraction de threads (speculatifs ou non) a des resultats toujours particulierement limitee, et je n'hesiterai pas a dire qu'il s'agit d'un progres majeur des qu'un compilateur fournira une version efficace de ce type d'optimisations. Les implementations actuelles auquelles j'ai ete confronte ne m'ont pas encore convaincu.

[newbie06]

Et moi ca m'agace quand on me misquote: pas d'avancee significative different de n'evolue plus

Désolé, je me suis laissé emporter

Je suis globalement d'accord avec toi : on n'a pas d'avancée significative que ce soit en compilo ou en archi depuis un bon moment. J'irai même plus loin en disant que les avancées significatives ("breakthrough") sont et ont été très rares (allez soyons fou, je dirais que c'est vrai de tous les domaines scientifiques...). Je ne suis pas certain qu'on ait jamais vu un nouveau proc ou un nouveau compilo qui nous fasse un x2 en perf.

C'est en effet l'ingénierie qui fait avancer les choses à coups de 10% par-ci par-là.

Tu as parlé de compilos x86. Je trouve que c'est le parfait exemple des problèmes compilo vs hardware. Les designers rajoutent une tripotée d'optim microarchitecturales, et les compilos mettent quelques années à pouvoir tout exploiter efficacement. Comme tu le fais remarquer, la "nouvelle" mode des threads est en train d'arriver sur nos bureaux et on ne sait pas encore l'exploiter dans un compilo. (Note sur le côté : je ne suis pas certain que les threads spéculatifs soient si intéressants que ça sur le long terme parce que niveau power ça va être monstrueux d'exécuter pour rien des dizaines d'instructions x le nombre de threads faux...).

De toute façon on a une sacrée barrière : le langage C qui est trop laxiste pour permettre beaucoup de choses niveau optim. (Tiens d'ailleurs voilà un bon exemple : maintenant qu'on a des machines performantes avec plein de RAM, les compilos sont capables d'optimiser tout un programme, sans avoir à compiler séparément ; donc le compilo peut voir par exemple le véritable aliasing et pas faire des suppositions pessimistes.)

EDIT : pour la PGO, je pense que c'est une belle arnaque ; pour que ça marche vraiment il faudrait être capable d'avoir un ensemble d'entrées vraiment représentatif, mais cet ensemble, c'est comme les benchmarks, il est représentatif de lui-même :D

[fefe]

Je ne suis pas certain qu'on ait jamais vu un nouveau proc ou un nouveau compilo qui nous fasse un x2 en perf.

Si je voulais etre malhonnete je te demanderais de faire l'experience suivante:
- CPU d'il y a 10 ans avec compilo d'il y a 10 ans
- CPU d'il y a 10 ans avec compilo d'aujourd'hui
- CPU d'aujourd'hui avec compilo d'il y a 10 ans
- CPU d'aujourd'hui avec compilo d'aujourd'hui

en 10 ans le CPU aura probablement change ses perfs de >2x, alors que je doute que le compilateur reussisse le meme tour de force en 10 ans, et ce meme si c'est du code susceptible d'etre vectorise (je parle d'applis completes bien sur, pas de kernels). Meme si on prend SPEC, sur lequel tout le monde aussi bien en compil qu'en hardware a beaucoup bosse (et avec un ensemble de donne fixe donc PGO est utilisable), je doute que les ameliorations des compilos soient comparables aux ameliorations des CPUs. Le seul cas que je connaisse sur SPEC ou il y ait eu des ameliorations importantes est un cas de loop inversion (qui sent assez fort la triche parce que peu appliquable en dehors de ce bench particulier).

Comme je l'ai introduit c'est une comparaison malhonnete, ce genre de caracteristiques n'a jamais ete attendue d'un compilateur x86 (tout du moins sur les 10 ans passes), surtout que les CPUs ont investi une quantite tres importante de hardware qui justement est utilise a des fins d'optimisations qui overlap avec les capacites du compilateur. Mais justement avec la generalisation des multi-cores c'est une des premieres opportunites depuis longtemps qui remet la balle dans le camp du software pour la performance (par comparaison avec ma suggestion cis-dessus ou le resultat tend a dire que le hard a propose plus d'ameliorations que le soft sur cette periode).

Malheureusement pour l'instant c'est sur le programmeur que cette performance repose et non pas sur le compilateur meme si la recherche s'intensifie dans le domaine.

Une autre opportunite a ete avec la vectorisation, mais malheureusement les jeux d'instructions SIMD disponibles sur les x86 n'ont jamais ete concus pour etre compilables efficacement (on peut moderer en disant que ce n'etait pas leur objet primaire). Le resultat est que malgre les connaissances importantes dans le domaine de la vectorisation automatique, les benefices ont ete assez ridicules sur tout ce qui n'a pas ete reecrit a la main.


Pour ce qui est des threads speculatifs permet moi de ne pas etre completement d'accord. C'est le probleme classique du cout energetique de la speculation, qui est directement lie au rapport entre gain et succes de speculation. Aujourd'hui un CPU specule sur presque tout, la resolution des branchements, la resolution des adresses, le chargement des donnees, donc je ne vois pas de raisons de ne pas aller plus loin et de speculer sur les dependances entre instructions (equivalent a casser un code sequentiel en threads). A partir du moment ou le taux de succes d'une telle speculation sera suffisant ces methodes pourront etre interressantes. En pratique plus on se rend compte tot d'une mauvaise speculation, moins le cout energetique est important.

Qui plus est il y a 2 types de problemes poses par le cout energetique d'une telle solution:
-depassement d'un budget power alloue au hardware, ou TDP
-efficacite energetique, ou battery life

Dans le 2 eme cas il est effectivement difficile d'imaginer une solution ou on attendra un taux de bonnes speculation suffisant pour ameliorer l'efficacite (mais c'est un sujet de recherche tres actif, tant du cote soft que hard). En revanche dans le premier cas, il y a bon nombre d'applications qui ne fonctionnent pas proche du TDP (surtout pour les applis mono thread), il y a donc un budget power disponible assez important pour ces applications, et gagner de la performance meme en speculant avec une efficacite faible peut etre interressant.

J'irai même plus loin en disant que les avancées significatives ("breakthrough") sont et ont été très rares

En hardware (CPU centrique), je qualifierais de breakthrough l'implementation de multiples threads en hardware dans les memes cpus. Je fais reference aux techniques de SMT/SoEMT et pas aux multicores. Bien sur il y a eu des tentatives de machines multithread il y a longtemps, mais rien qui n'ait vraiment perce, alors que aujourd'hui on trouve des cpus integrant un type ou un autre de SMT dans des serveurs, dans des applis mobiles et dans des PCs. En revanche la recherche dans le domaine s'est intensifie uniquement il y a une bonne 15 aine d'annes, donc on peut discutter sur le fait que ca soit une idee de notre decennie.

Il y a eu d'autres bonnes idees avec les caches de traces/ caches d'instruction predecodees/ disambiguation memoire, mais encore une fois il s'agit de la meme epoque.

[newbie06]

Si je voulais etre malhonnete je te demanderais de faire l'experience suivante:
- CPU d'il y a 10 ans avec compilo d'il y a 10 ans
- CPU d'il y a 10 ans avec compilo d'aujourd'hui
- CPU d'aujourd'hui avec compilo d'il y a 10 ans
- CPU d'aujourd'hui avec compilo d'aujourd'hui

C'est marrant, c'est exactement le genre de comparaison que j'allais proposer.

en 10 ans le CPU aura probablement change ses perfs de >2x,

Tu le sais que c'est malhonnête : le proc va gagner parce que sa fréquence aura augmenté (ce qui est possible pour deux raisons, micro archi et process) et ses caches auront fait x10 en taille au minimum (je parle caches L2/L3).
Donc les seules comparaisons intéressantes seraient à CPU égal, compilos différents. Mais même là c'est biaisé : qui vérifie que son compilo marche encore bien sur un P5 ?

Je pense quand même que tu as raison sur le fond : ce sont plus les avancées des processeurs qui ont fait grimper les performances que les avancées des compilos.

alors que je doute que le compilateur reussisse le meme tour de force en 10 ans, et ce meme si c'est du code susceptible d'etre vectorise (je parle d'applis completes bien sur, pas de kernels).

C'est une évidence ce que tu dis : tu as une limite, celle du processeur que tu cibles (mauvaise foi inside).

Meme si on prend SPEC, sur lequel tout le monde aussi bien en compil qu'en hardware a beaucoup bosse (et avec un ensemble de donne fixe donc PGO est utilisable), je doute que les ameliorations des compilos soient comparables aux ameliorations des CPUs. Le seul cas que je connaisse sur SPEC ou il y ait eu des ameliorations importantes est un cas de loop inversion (qui sent assez fort la triche parce que peu appliquable en dehors de ce bench particulier).

Tu parles du "truc" de Sun ? J'avais cru qu'il s'agissait d'une astuce multi CPU, mais j'avoue que ce genre de x2 sur un score ne me donne pas envie de creuser.

Comme je l'ai introduit c'est une comparaison malhonnete, ce genre de caracteristiques n'a jamais ete attendue d'un compilateur x86 (tout du moins sur les 10 ans passes), surtout que les CPUs ont investi une quantite tres importante de hardware qui justement est utilise a des fins d'optimisations qui overlap avec les capacites du compilateur.

C'est d'ailleurs un point qui m'ennuie : les designers font des benchmarks avec le meilleur compilo qu'ils trouvent et en déduisent des choses. Ils oublient juste qu'ils se trainent des artefacts de génération datant d'une génération précédente et/ou des benchmarks devenus idiots (dans le monde dans lequel je bosse, on sort à peine de Dhrystone ).

Je suis complètement d'accord avec toi sur le fait que le MT massif va devoir remonter du programmeur vers le compilateur, cependant cela nous ramène à ce que je disais, il va falloir aller au-delà du langage C et aussi rééduquer les programmeurs qui pour 99% d'entre eux n'ont même pas la notion de ce qu'est un cache de données ou le coût du dispatch dynamique.

Une autre opportunite a ete avec la vectorisation, mais malheureusement les jeux d'instructions SIMD disponibles sur les x86 n'ont jamais ete concus pour etre compilables efficacement (on peut moderer en disant que ce n'etait pas leur objet primaire). Le resultat est que malgre les connaissances importantes dans le domaine de la vectorisation automatique, les benefices ont ete assez ridicules sur tout ce qui n'a pas ete reecrit a la main.

Ces jeux d'instructions ont été hélas pensés pour l'écriture à la main de CODEC. Et les formats de données associés n'existent pas en C standard. D'un autre côté si on regarde ce que fait le compilo d'IBM voire même gcc, pour les SPU du CELL en utilisant des extensions de C, c'est quand même très intéressant.

Dans le 2 eme cas il est effectivement difficile d'imaginer une solution ou on attendra un taux de bonnes speculation suffisant pour ameliorer l'efficacite (mais c'est un sujet de recherche tres actif, tant du cote soft que hard). En revanche dans le premier cas, il y a bon nombre d'applications qui ne fonctionnent pas proche du TDP (surtout pour les applis mono thread), il y a donc un budget power disponible assez important pour ces applications, et gagner de la performance meme en speculant avec une efficacite faible peut etre interressant.

J'avoue que je suis probablement perturbé par mon environnement de boulot : c'est plus l'efficacité énergétique qui me paraît importante. Mais je suis d'accord avec toi.
Je noterais cependant que la spéculation peut réduire les performances des applications non pensées pour cela ou qui ne s'y prêtent simplement pas. Le P4 SMT est probablement un tel exemple, même si comme il s'agissait d'un premier essai grand public, on peut laisser le bénéfice du doute à cette technique.

En hardware (CPU centrique), je qualifierais de breakthrough l'implementation de multiples threads en hardware dans les memes cpus. Je fais reference aux techniques de SMT/SoEMT et pas aux multicores. Bien sur il y a eu des tentatives de machines multithread il y a longtemps, mais rien qui n'ait vraiment perce, alors que aujourd'hui on trouve des cpus integrant un type ou un autre de SMT dans des serveurs, dans des applis mobiles et dans des PCs. En revanche la recherche dans le domaine s'est intensifie uniquement il y a une bonne 15 aine d'annes, donc on peut discutter sur le fait que ca soit une idee de notre decennie.

(/mode provoc on) Ouai on a fait descendre le principe de switch de contexte sur IO au niveau du hardware (/mode provoc off)
J'ai encore du mal à croire que cette technique va vraiment apporter des gains importants, et donc je n'arrive pas à la qualifier de breakthrough. Je suis prêt en revanche à admettre que j'ai tort, ce n'est vraiment qu'un point de vue personnel !

Il y a eu d'autres bonnes idees avec les caches de traces/ caches d'instruction predecodees/ disambiguation memoire, mais encore une fois il s'agit de la meme epoque.

Ces idées existent en soft depuis un moment.

Je conclurai en disant que je suis globalement d'accord avec toi, pas de doute là-dessus. On n'est probablement juste pas d'accord sur l'importance relative du SW vs celle du HW