Intel Atom

[fefe]

Pour le SMT le processeur auquel je pensais le plus est Niagara... Ca marche, et bien. Pour le P4, ca lui a permi de rester a peu pres competitif dans le monde des serveurs alors que la faiblesse de sa platforme aurait du le couler beaucoup plus tot.

Sinon pour l'importance relative du HW vs SW, mon argumentation est plus pragmatique que philosophique:
- il y a plus de monde qui fait du soft que du hard, donc autant choisir de deporter le probleme sur le hard
- les cycles de dev hardware sont plus courts que en software, donc avoir le hardware qui change est plus efficace.
Le jour ou le 2 eme point change, il faudra inverser la tendance, et on s'en approche lentement... Donc pour ce qui est de l importance relative du HW vs SW, je pense juste que dans les conditions actuelles c'est normal d'avoir le hard plus important, mais je pense que ca changera (donc je ne suis pas tant que ca un integriste du hardouere)

[newbie06]

Je pensais que le Niagara n'était vraiment efficace que sur des charges bien particulières comme par exemple le service de pages Web, une tache extrêmement limitée par les I/O. Peut-être le Rock va-t-il améliorer la donne, mais si ma supposition est juste on est quand même dans un domaine assez particulier. Me trompé-je ?

Je ne suis pas non plus un intégriste du soft. Je trouve juste que le hardware qu'on a est loin d'être suffisamment bien exploité et que ça va en s'agravant avec le multi-core et/ou le multi-thread massif.

[fefe]

Un petit ajout a propos des perfs des compilateurs recents, on a recement fait un test sur une application de quelques millions de lignes de code que l'on compile traditionellement avec gcc/g++, c'est essentiellement du code spaghietti, entier, pourri jusqu a la moele sans aucune regle imposee pour forcer les dev a coder qq chose de performant.
Le tout etant la moyenne de ~1000 runs de plusieurs heures chacun pour chaque config.
-Gcc/G++ 3.4.3 -O4: 1.0 (base)
-Gcc/g++ 3.4.3 +PGO: 1.1x (PGO avec un test qui a ete tres afine pour correspondre aux caracteristiques essentielles de nos dataset)
-ICC 9 (sans PGO): 1.11x

Donc gcc s'en sort tres bien avec PGO, mais la compilation avec PGO prend + de 45 minutes avec distcc sur 15 hosts contre 15-20 min pour ICC donc il n'y a pas photo .

[newbie06]

C'est interessant, il ne vous reste plus qu'a refaire pareil avec icc 10 et gcc 4
gcc 3.4.3 a plus de 3 ans et a beaucoup evolue en terme de vitesse de compilation et de generation de code (pas forcement en bien).

D'ailleurs -O4 ca fait -O3 dans gcc, ce qui me fait douter. Vous avez bien mis les bons flags (-mcpu notamment) ?

Bon je critique mais c'est vraiment interessant. J'ai une grosse theorie la-dessus : si tu as un code ecrit par des ramollis du bulbe, un compilo ne peut pas optimiser grand-chose. OK, il y a l'autre extreme du type qui optimise avec un compilo particulier et qui se retrouve avec un truc qui aurait pu etre plus rapide avec un autre compilo

Par ailleurs ce chiffre de 10% de gain correspond a peu pres a ce que j'ai obtenu en PGO avec gcc sur du code traduit verilog->c.

[fefe]

D'ailleurs -O4 ca fait -O3 dans gcc, ce qui me fait douter. Vous avez bien mis les bons flags (-mcpu notamment) ?

J'ai dit -O4 comme un raccourci, mais en pratique c'est O3, avec mcpu, omit frame pointer et force addr.

Notre code n'est pas traduit, il a ete ecrit directement en c/c++ (suivant les librairies), et ce n'est pas du RTL.

Pour les vieux compilos je sais, mais ca nous avait deja pris tant de temps pour passer de 3.3 a 3.4.3 pour si peu de benefices qu'on a un peu laisse tomber.

[newbie06]

Pour les vieux compilos je sais, mais ca nous avait deja pris tant de temps pour passer de 3.3 a 3.4.3 pour si peu de benefices qu'on a un peu laisse tomber.

Normalement (je dis bien normalement...) le passage a une version 4 devrait etre plus facile si vous etiez en 3.4.3, le support C++ est a peu pres stabilise depuis la 3.4. Bien sur si vous avez des lib sans source deja compilees, ca devient penible.

Plus qu'une semaine a tenir et je fais du benchmark de compilos...

[fefe]

Normalement (je dis bien normalement...) le passage a une version 4 devrait etre plus facile si vous etiez en 3.4.3, le support C++ est a peu pres stabilise depuis la 3.4. Bien sur si vous avez des lib sans source deja compilees, ca devient penible.

Plus qu'une semaine a tenir et je fais du benchmark de compilos...

On a encore toutes les sources , mais y a des trucs dans lesquels personne ne veut plonger vu la quantite de validation necessaire (sur certaines libs il ne faut pas seulement que ca compile et donne l'impression de marche il faut qu'on prouve que les reponses seront exactement celles attendues, et le probleme est que la preuve "formelle" prend vraiment du temps et de l'effort).

Bon quand je disais que tout le code etait ecrit en c/c++, j'exagerais un peu, il y a quand meme quelques 100aines de milliers de lignes qui sont generees, par des scripts en perl, bison, awk, python, bisounours et compagnie...

Des fois je serais heureux de devoir benchmarker des trucs ou je n'ai pas besoin d'attendre 2 semaines pour avoir les resultats

[newbie06]

Bon quand je disais que tout le code etait ecrit en c/c++, j'exagerais un peu, il y a quand meme quelques 100aines de milliers de lignes qui sont generees, par des scripts en perl, bison, awk, python, bisounours et compagnie...

Ca me rappelle mon premier job quand je tentais d'expliquer aux gens qu'utiliser les expressions regulieres de PERL, ca n'etait pas faire du parsing. Je ne sais pas s'ils ont jamais compris, mais en tout cas j'ai bien compris que faire changer les gens de point de vue n'etait pas chose aisee Maintenant j'ai evolue : je me fous de leur gueule et je les regarde faire sans intervenir. C'est cool d'etre un vieux con.

Des fois je serais heureux de devoir benchmarker des trucs ou je n'ai pas besoin d'attendre 2 semaines pour avoir les resultats

Fais tourner spec2006 en simu

En parlant de dormir, ils font quoi a Shangai

[fefe]

Fais tourner spec2006 en simu

a la vitesse de la simu si tu fais tourner tout le bench, ca va plus vite de fabriquer le chip et de le faire tourner dessus que d'attendre les resultats de la simulation

[newbie06]

a la vitesse de la simu si tu fais tourner tout le bench, ca va plus vite de fabriquer le chip et de le faire tourner dessus que d'attendre les resultats de la simulation

Oui et y'a meme des chances que le masque te coute moins cher que l'electricite consommee pour la simu

[fefe]

Oui et y'a meme des chances que le masque te coute moins cher que l'electricite consommee pour la simu

100W(load vs idle)x0.0001Ex12h(per bench sur une machine rapide)x5000000(ratio de simu grosso modo)=600K euros/bench ... en electricite, le masque devrait rester plus cher, par contre il faut esperer que la machine ne reboote pas pendant les 6800 ans ou elle a simule .

[newbie06]

100W(load vs idle)x0.0001Ex12h(per bench sur une machine rapide)x5000000(ratio de simu grosso modo)=600K euros/bench ... en electricite, le masque devrait rester plus cher

Ca depend du proc dont tu dois faire le masque

En revanche, si on tient compte du nombre de benchmarks...

Ca fait peur le ratio a 5M.

[Alexko]

Ce que tu appelles le ratio de simu, c'est bien le temps que prend la simulation, divisé par le temps réel que prendrait le chip ? C'est vrai que 5M, c'est violent !

[newbie06]

Ce que tu appelles le ratio de simu, c'est bien le temps que prend la simulation, divisé par le temps réel que prendrait le chip ? C'est vrai que 5M, c'est violent !

Si j'en crois des temps de simu que j'ai vus, l'ordre de grandeur pour un design pas trop ridicule est de l'ordre de 3k cycles/seconde (attention, je repete : c'est un ordre de grandeur). Il s'agit de simu RTL, pour du gate level ce serait beaucoup moins.

Donc pour un processeur 3 GHz le facteur de ralentissement est de 1M.

Naturellement apres, ca varie enormement d'un simulateur a l'autre. VCS est meilleur que ModelSim. Et ca varie aussi selon la taille du design et le niveau auquel les designers ecrivent.

[fefe]

Si j'en crois des temps de simu que j'ai vus, l'ordre de grandeur pour un design pas trop ridicule est de l'ordre de 3k cycles/seconde (attention, je repete : c'est un ordre de grandeur). Il s'agit de simu RTL, pour du gate level ce serait beaucoup moins.

Donc pour un processeur 3 GHz le facteur de ralentissement est de 1M.

Le facteur de 5M cis-dessus n'est pas pour une simu RTL, mais pour un model de "performance" custom (le but est de predire la performance, pas de simuler les caracteristiques detaillees du chip), il faut ajouter quelques ordres de grandeurs pour une simulation RTL equivalente...

[Alexko]

Ah ouais, quand même...

[newbie06]

Revenons au sujet

D'après Tom's fr:

Résultats Spec_int2000
Atom            @0,8  GHz  319
Atom            @1,2  GHz  439
Atom            @1,6  GHz  653
Core2 Duo E6300 @1,86 GHz 1900

Ca nous place le 0,8 GHz au niveau d'un P3 700 MHz. Pas trop mal si l'on considère que le P3 est out of order ; mais c'est probablement contre balancé par un compilo qui a évolué et un jeu d'instruction SIMD qui est peut-être mis à profit dans certains des benchs (il faudrait les résultats individuels pour en être sûr).

Bon, maintenant je tente la cascade en regardant specint 95 :

P3 (Dell)      @0,7   GHz 33,8
P5 MMX (Intel) @0,233 GHz  7,0

Maintenant on peut spéculer sur du vent

En tout cas dans ce qu'a présenté Intel, je trouve que le plus risible était la comparaison browser OMAP2420 vs Atom @1.6GHz. Je crois que c'est un sommet de benchmarketing bullshit, en tout cas ça mériterait de figurer dans un top 10

[fefe]

Toute comparaison de perf entre 2 plateformes qui ont des ordres de grandeur de difference en terme de prix et de depense energetique est pur marketing bullshit... J'ai rigole aussi quand j'ai vu les benchs dont tu parles.

Sinon pour le SIMD, la vectorisation sur un CPU moderne apporte 5% au score SpecFP et pas loin de 0 sur SpecInt (en dehors de boucles de copie memoire ou d'initialisations de structures il n y a rien que le compilo peut vectoriser, entre autre pour des raisons de differences arithmetiques). Donc dans ce cas precis je doute que le SIMD ne soit d'aucune aide.

Le score est pas mal pour voir que la comparaison est avec une machine OOO qui a 4 etages de pipeline de moins, mais ce n'est pas si atomique que ca (enfin en SpecInt rate Atom devrait etre assez competitif face a des single core non SMT). Sinon SpecInt est beaucoup plus sensible au OOO que du code FP (cf les resultats generalement mauvais d'autres archis in order sur SpecInt comme Itanium).

[newbie06]

Merci pour les infos sur l'intérêt du SIMD. Je creuserai un peu plus avec icc.

J'avoue que le score specint me paraît en effet élevé face aux autre résultats d'architectures in-order. Avec cette profondeur de pipeline, je ne peux que supposer que les prédicteurs de branchement sont diablement efficaces. D'un autre côté, j'imagine sans peine que la partie data doit être infiniment supérieure à ce qui existait du temps du P5

[newbie06]

Les resultats SPEC que j'ai cites ci-dessus proviennent de cette page :
http://www.presence-pc.com/tests/Atom-MID-22770/6/

Quelqu'un serait-il capable de me trouver une source officielle ?

[newbie06]

Encore un article sur Atom: http://arstechnica.com/articles/paed...obile-era.ars/

Il a meme le bon gout de parler des ARM Cortex-A8 et A9

[fefe]

L'article repose sur ses "gut-feelings" plus que des donnees solides... Un peu normal les donnees ne sont pas publiees .

[newbie06]

Ha mais si ARM a tout publie sur le Cortex-A9 :

Industry leading performance with over 2.0 DMIPS/MHz for unprecedented peak performance while also maintaining low power for extended battery life and lower cost packaging and operation

Qu'est-ce que tu veux de plus ?

[fefe]

Je parlais de la longue tirade sur a quel point le x86 penalisait Atom .
Et quant a la perf de chips pas encore sur le marche je suis pret a accepter les speculation, si les memes sont faites sur le chip du concurent a la meme periode .

Et effectivement j'avais oublie les DMIPS/MHz !!! Honte a moi .

En revanche j'aime bien son intro, Intel a deja gagne avec des chips qui n'etaient pas les meilleurs dans l'absolu (EV5/EV56/EV6 contre P6) mais grace a une capacite de production competitive.
La competition en terme de capacite de prod ne se fera pas avec ARM mais avec tous ceux qui font des chips a base d'ARM, qui ne beneficient pas tous des memes economies d'echelle qu'Intel.

[newbie06]

Et effectivement j'avais oublie les DMIPS/MHz !!! Honte a moi .

Ca fait prehistorique hein ?

En revanche j'aime bien son intro, Intel a deja gagne avec des chips qui n'etaient pas les meilleurs dans l'absolu (EV5/EV56/EV6 contre P6) mais grace a une capacite de production competitive.

L'Alpha que de souvenirs
Enfin c'est plutot HP qui a tue l'Alpha en vendant son ame a l'Itanium (disons que c'etait le coup de grace...).

La competition en terme de capacite de prod ne se fera pas avec ARM mais avec tous ceux qui font des chips a base d'ARM, qui ne beneficient pas tous des memes economies d'echelle qu'Intel.

La plupart des gros fournisseurs de semi conducteurs font du ARM aussi, donc je pense que la capacite de production est largement la (faut pas oublier, plus de deux milliards de CPU ARM l'an passe). Par ailleurs les couts de developpement et d'implementation sont amortis sur l'ensemble.

[fefe]

La plupart des gros fournisseurs de semi conducteurs font du ARM aussi, donc je pense que la capacite de production est largement la (faut pas oublier, plus de deux milliards de CPU ARM l'an passe). Par ailleurs les couts de developpement et d'implementation sont amortis sur l'ensemble.

Je pointais juste le fait qu'il s'agit de plusieurs acteurs et pas d'1 seul. Bien sur que les couts sont amortis, mais une des choses qui a ete fatale au marche des serveurs risc etait la competition acharnee entre risc autant que l'arrivee de P6 (quand HP s'est lance dans Itanic, ils savaient deja que leur serie PA etait finie au long terme).

Bien sur que tous les acteurs qui font de l'ARM unis pesent serieusement, mais sont ils unis face a un concurent qui arrive qui ne ressemble pas trop a une menace si ce n'est la compagnie qui le propose. Atom a des performances single thread assez lamentable, une plateforme en alpha version qui ressemble a du bricolage et un power pas foncierement attractif. Au final il n'y a pas vraiment de craintes a avoir ... a moins que le marche ne reagisse pas qu'a des caracteristiques technique.

PS: et malgre cette liste longue et assez critique je ne pense pas que ce soit x86 qui fasse du tort a Atom .

[Yasko]

PS: et malgre cette liste longue et assez critique je ne pense pas que ce soit x86 qui fasse du tort a Atom .

Mais Atom qui fait du tort à x86

[Neo_13]

Je pointais juste le fait qu'il s'agit de plusieurs acteurs et pas d'1 seul. Bien sur que les couts sont amortis, mais une des choses qui a ete fatale au marche des serveurs risc etait la competition acharnee entre risc autant que l'arrivee de P6 (quand HP s'est lance dans Itanic, ils savaient deja que leur serie PA etait finie au long terme).

Bien sur que tous les acteurs qui font de l'ARM unis pesent serieusement, mais sont ils unis face a un concurent qui arrive qui ne ressemble pas trop a une menace si ce n'est la compagnie qui le propose. Atom a des performances single thread assez lamentable, une plateforme en alpha version qui ressemble a du bricolage et un power pas foncierement attractif. Au final il n'y a pas vraiment de craintes a avoir ... a moins que le marche ne reagisse pas qu'a des caracteristiques technique.

PS: et malgre cette liste longue et assez critique je ne pense pas que ce soit x86 qui fasse du tort a Atom .

Je crois que c'est ça le soucis... En alpha, il est pas ridicule du tout (même s'il a des progrès à faire). Alors ensuite ???

Et le SEUL avantage d'Atom actuellement c'est le x86.

:'(Alpha EV

[Dandu]

tsss, le seul avantage du Atom va être le prix (pour Intel)

et oui, le marché réagit aux caracs techniques, enfin aux marketing Intel.

Exemple type : le Eee PC 900 a une batterie de merde et les premiers test (dont le mien) montrent qu'il a une autonomie très (trop) faible. Pourtant, le reste est très bon, et il est franchement mieux que le premier. Sur les forums, on voit que tous les gens attendent le 901 en Atom qui sera : pas spécialement plus rapide (voire moins) et pas nécessairement plus autonome (la différence sera pas non plus abyssale, a priori). Mais l'Atom semble faire rever pas mal (a tort ?)

[fefe]

Mais l'Atom semble faire rever pas mal (a tort ?)

C'est l'effet nouveaute, j'en connais bien qui ont achete des Phenom (bugges) a la sortie parce qu'ils etaient quad core natifs. Je ne denoncerai personne .