Via Isaiah a.k.a. Nano

[Yasko]

Alors pour initier ce topic sur le challenger de l'Atom, commençons-donc par une interview du président de Centaur, sur un bon vieux rock comme les taiwanais en ont le secret :




Rubrique à brac :

• Date de sortie : Q3'08
• Bus : FSB 200 MHz QDR
• Process : 65 nm Fujitsu
• Die : 7.650mm x 8.275mm (63.3 mm²)
• Package : NanoBGA2 (21mm x 21mm) - idem C7
• ISA : x86, 64 bits, SSEx
• caches : 64 KB L1I + 64 KB L1D - 16-way, 1 MB L2 16-way exclusif
• Espace dédié de 64 lignes de cache pour le prefetch (?)
• Prédiction de branches : eight different predictors in two different pipeline stages. The first fetch pipeline stage contains three predictors of conditional branch behavior (each more accurate for a particular type of branch), a predictor of which of these predictors to use, and a separate return predictor. The translate stage contains a return predictor, a conditional branch “overflow” predictor, and a default predictor.
• Decode, issue, retire : decode three full x86 instructions per clock (instructions of any length in a single clock, assuming that all instructions start within the same 16-byte address range. no restriction on the type of x86 instructions or their format—all three x86 instructions can be “complex”), generate three fused micro-ops per clock, issue—speculatively and out-of-order—seven execution micro-ops per clock to seven execution ports (two integer, a load, a store address, a store data, a “media”, and a multiply micro-op. The media micro-op can be a floating-point add, divide or square root, or a SIMD integer instruction), and retire three fused micro-ops per clock.
• Macro & micro fusion : specific combinations of two x86 instructions are combined (fused) into one executable micro-op (macro-fusion). Multiple micro-ops controlling different execution ports can be fused into a single fused micro-op (micro fusion).
• Compute : four floating-point adds and four floating-point multiplies every clock processor — add : two clocks for any format (SP, DP, DE, packed or scalar). ; mul : three clocks for SP multiply, and four for DP and DE. data path for SIMD integer instructions is 128-bits wide,
  and almost all SSEx instructions—including all shuffles— execute in only one clock.
• Power : adaptively transitioning between performance and voltage states (“P” states) while the processor continues to run. automatic overclocking if the die temperature is low. automatically maintain the die temperature at a user-specified temperature.
• Securité : hardware for AES encryption, SHA-1 and SHA-256 secure hashing, random number generation, and a very specialized “secure execution mode”.

La gamme :

Model Speed Idle Power TDP
L2100 1.8GHz 500mW 25W
L2200 1.6GHz 100mW 17W
U2300 1.3GHz 100mW 8W
U2500 1.2GHz 100mW 6.8W
U2400 1.0GHz 100mW 5W


Les perfs :

Attention, on entre dans le spéculatif (avec fortes probabilités d'erreur sur le prefetch...)
En se basant sur les chiffres de Via annonçant le Nano comme 2 fois (2.4 précisément) plus puissant que le C7 à fréquence identique, et ceux des tests du Doc entre le C7 et l'Atom, on obtient un Nano au moins 30% plus performant qu'un Atom à fréquence identique (entre 1.1 et 1.4 sans tenir compte des 100 MHz à l'avantage de l'Atom). On pourrait donc avoir Nano@1.2GHz/8W équivalent à un Atom@1.6GHz/2W (valeurs de TDP, pas conso réelle...)

[Franck@x86]

Ceci provient d'un dump qui date de qques mois déjà :

Core Speed		1795.6 MHz
Instructions sets	MMX, SSE, SSE2, SSE3, SSSE3, x86-64
L1 Data cache		64 KBytes, 16-way set associative, 64-byte line size
L1 Instruction cache	64 KBytes, 16-way set associative, 64-byte line size
L2 cache		1024 KBytes, 16-way set associative, 64-byte line size

[fefe]

Il semble que pour les plateformes style Asus EEE le Nano va etre tres interressant. Les 2W de l'Atom etant relativement ininterressants tant que couple a un chipset qui en consomme ~20... Reste a voir le prix du Nano vs le prix d'Atom.

[Foudge]

J'ai lu que l'Atom pouvait aussi se coupler à un chipset SIS qui consomme 8W. Ca fait toujours beaucoup comparé au CPU, mais c'est beaucoup moins que le chipset Intel.

[Alexko]

C'est un peu dommage que le Nano soit sur 65 nm Fujitsu et doive faire face à l'Atom sur 45 nm Intel (donc High K + Metal Gate)...

Mais bon, si les choix de VIA sont pertinents il a peut-être une chance.

[newbie06]

C'est un peu dommage que le Nano soit sur 65 nm Fujitsu et doive faire face à l'Atom sur 45 nm Intel (donc High K + Metal Gate)...

Mais bon, si les choix de VIA sont pertinents il a peut-être une chance.

Intel est très en avance sur le process, je ne crois pas qu'il y ait un seul autre fondeur qui produise massivement des chips complexes en 45 nm (par complexe, je veux dire autre chose des mémoires). La maîtrise complète de tout le flot est une de leurs grandes forces

[Alexko]

C'est clair. Quelques benchs du Nano ici :

http://www.legitreviews.com/article/719/3/

Sinon, je viens de penser à un truc :

- NVIDIA oppose son Tegra à l'Atom sur le segment MID/UMPC. Tegra est sans doute moins performant, pas compatible x86 mais beaucoup plus petit et économe en énergie.

- VIA, de son côté, oppose Nano à l'Atom sur le segment Netbooks et Nettops. Nano consomme plus d'énergie, mais pas trop et ça pourrait être en partie rattrapé sur le chipset, et Nano devrait être nettement plus performant. À vrai dire, je soupçonne même Nano de faire un CPU tout à fait décent pour un desktop bas de gamme classique, dans sa version actuelle voire dual-core à venir. En attendant cette dernière, l'Atom devrait toutefois se démerder à peu près correctement sur workloads multi-threadés.

Du coup, est-ce qu'Intel ne sera pas trop en difficulté à devoir se battre sur deux fronts à la fois, en faisant face à des produits plus ciblés ? Sans compter que, si le cas Nano est assez unique, NVIDIA n'est/ne sera pas seul à proposer des SoCs basés sur ARM...

AMD semble avoir plus ou moins abandonné la gamme Geode, par contre.

[newbie06]

L'Atom est un coup d'essai raté (avis perso) : pas assez performant pour justifer sa conso, pas de SoC, trop gourmand pour le segment MID.

Mais c'est Intel, ils ont des brouzoufs, des tonnes d'excellents ingénieurs, et je pense que la génération suivante sera bien plus intéressante.

[Alexko]

Bah d'après Sam, c'est un rattrapage de projet many-core avorté. Mais à vrai dire je me demande presque pourquoi : il fait 25 mm² pour un TDP de 2W à 1.6 GHz. Du coup, on peut se demander pourquoi Intel n'a pas choisi de produire un 16-core à base d'Atom, ça ferai 400 mm² (enfin sûrement 500 avec le cache et les pertes) pour un TDP d'environ 50W à peine... ou peut-être 90W à 2 GHz.

Ça aurait peut-être pas été super intéressant pour M. Tout-le-Monde en face d'un C2Q Penryn, mais peut-être pour un serveur ? Finalement, le concept est assez proche du Niagara de Sun...

[Dandu]

l'Atom en lui même est pas réellement raté : ca consomme peu, ca coute pas cher et c'est raisonnablement performant avec l'hyperthreading (enfin, ça reste faible, mais Via vend bien du 7 bien plus faible).

Par contre, le choix des chipsets me sidère : on a le 945GC en "bureau" qui consomme 5 x comme le CPU et qui doit être refroidi, ou le GSE en "mobile" qui consomme encore près de 6 W (2 pour le CPU) et qui en plus offre des performances ridicules (GMA @ 133 MHz )

Reste le SCH "poulsbo" (poulsbo, poulsbo, petit chipset mobile...) qui consomme peu, semble performant mais offre des technologies pas adaptées aux PC classiques.

Et d'ailleurs, ma carte mère C7 consomme moins en pratique que la carte avec un Atom, à cause du chipset (bon, on est en dessous en perfs)

[newbie06]

@dandu: ce que tu dis prouve juste que l'Atom actuellement est mal positionne

[AiZ]

Arf,

Y a pas à dire, ça tatanne...
Video: Mini-ITX 2.0 with VIA Nano really does play Crysis

Heureusement qu'ils ont mis une 8600 plutôt qu'une 9800GX2, sinon ils auraient pleuré chez Intel.

AiZ

[Childerik]

Arf

La démonstration de ... force avec un Crysis probablement en 1024X768, voire 800X600 vu les frites qu'il y a sur l'écran.

Puis la video avec via.com.tw, genre la source très ... sérieuse

[Dandu]

ca va hein, j'ai fait tourner Crysis sur un C7

(lentement, certes, avec une 8800 Ultra)

[Minuteman]

Pourquoi ils sont obligés de tirer sur une pauvre tortue?

[newbie06]

Nouveaux "benchs" vs Atom : http://www.pcper.com/article.php?aid=572
Dommage qu'il manque la frequence de l'Atom et les conso...

[fefe]

Je parie sur frequences egales, et avec un minimum de tests multithreades.En fait quand on voit comment Atom s'en sort par rapport a un C2D qui a une conso comparable au Nano a frequence egale, ce nest pas encourageant pour Nano a moins qu il ne soit vendu vraiment pas cher...

Nano 30 ou 40% plus rapide qu'atom lui meme plus de 3x plus lent qu'un C2D et ce sans l'avantage du second thread HW d'atom qui grignotte probablement effectivement 20% de l avantage hors utilisation jeux.

[Yasko]

http://www.xbitlabs.com/articles/cpu...m-vianano.html

Pas encore lu.

[Childerik]

Having launched processors with x86 microarchitecture for ultra-portable devices, Intel will have to compete not against their eternal rival, AMD, but against VIA that occupied this market niche a few years ago after successful acquisition of “second-tier” processor developers – Cytrix and Centaur

Je ne savais pas qu'un développeur de solution logicielle faisait dans le hardware

Les résultats sont quand même étranges : on n'arrive pas à déterminer un ensemble logique de programmes où Nano est constament devant Atom ou inversement. On dirait que le facteur aléatoire joue beaucoup .

Par exemple, des programmes qui exploitent lourdement l'ALU, tantôt c'est Atom qui est devant, tantôt c'est Nano : et pas qu'un peu.

[Franck@x86]

pas mal ce petit Nano, finalement il ne lui manque d'un autre core.

Par exemple, des programmes qui exploitent lourdement l'ALU, tantôt c'est Atom qui est devant, tantôt c'est Nano : et pas qu'un peu.

oui c'est en effet assez variable, en floats le Nano semble un peu à la traine quand même.

[Møgluglu]

Ce n'est pas simplement du à l'HT?
J'ai l'impression que les benchs où l'Atom 230 passe devant le Nano sont aussi ceux où l'Atom 330 est loin devant... donc les benchs multithreads qui scalent bien.

[newbie06]

oui c'est en effet assez variable, en floats le Nano semble un peu à la traine quand même.

Pas tant que ça si on regarde Sandra Whetstone.

[Yasko]

Perso, je m'attendais un peu à mieux de la part de Nano. Le modèle testé tourne plus vite que le modèle d'Atom, les TDP sont très éloignés en défaveur du Nano (à défaut de pouvoir comparer leurs conso réelle du fait de leur boulets de chipset), mais l'écart de performance entre les 2 reste assez faible.
Je doute que les modèles de Nano aux TDP < 10W arrivent à lutter avec Atom...

Pour l'Atom 330, les résultats sont aussi un peu mitigés, on peut pas dire que le scaling soit bon souvent, mais c'est probablement dû aux applications utilisées pas forcement adaptées à 4 threads, puisque pour certaines comme XL et la lecture vidéo, les résultats sont bons.
XBits aurait pu essayer en désactivant le SMT sur le 330, voire si ca scalait mieux. Si oui, ca aurait pu indiquer un problème dans l'allocation des threads sur Vista ?

[Foudge]

XBits aurait pu essayer en désactivant le SMT sur le 330, voire si ca scalait mieux. Si oui, ca aurait pu indiquer un problème dans l'allocation des threads sur Vista ?

Ce qui ne serait pas une bonne nouvelle pour le Nehalem .

[Dandu]

je pense pas que le problème se pose au niveau de la gestion de l'HT, parce que bon, c'est quand même connu depuis un moment par MS.

Je pense surtout qu'un bus 533 et de la DDR2 en simple canal, ça aide pas le SMP, vu que bon, le 330 c'est juste deux Atom en SMP.

[Foudge]

Les 2 cores ne communiquent pas par le FSB, si ?

[Yasko]

Ce qui ne serait pas une bonne nouvelle pour le Nehalem .

Ouaip, je m'étais fait la même remarque (on a parlé je crois d'ailleurs dans le topic du nehalem).

Les 2 cores ne communiquent pas par le FSB, si ?

Je pense que oui. C'est la même solution que pour les smithfield.

[Childerik]

Ce qui ne serait pas une bonne nouvelle pour le Nehalem .

Nehalem, c'est pas Silverthorne hein Le nombre d'étages du pipeline ne sera surement pas équivalent, même si on ne sait toujours pas combien d'étages aura Core i7.

Les 2 cores ne communiquent pas par le FSB, si ?

Par quoi veux-tu qu'ils communiquent ?

Les accès spéculatifs à la mémoire système passent toujours par le FSB.

En revanche, depuis l'architecture Yonah, le L2 est unifié, ce qui évite aux deux cores de passer immédiatement par le FSB pour partager les données stockées dans le L2.

Ce qui ne fut pas sous le Pentium D, vu que les L2 étaient séparés et ne pouvaient dialoguer entre-eux qu'en passant par le FSB.

[Foudge]

Nehalem, c'est pas Silverthorne hein Le nombre d'étages du pipeline ne sera surement pas équivalent, même si on ne sait toujours pas combien d'étages aura Core i7.

Je fais référence au pb des multicores SMT, pas à la longueur du pipeline.

Par quoi veux-tu qu'ils communiquent ?

Les accès spéculatifs à la mémoire système passent toujours par le FSB.

En revanche, depuis l'architecture Yonah, le L2 est unifié, ce qui évite aux deux cores de passer immédiatement par le FSB pour partager les données stockées dans le L2.

Ce qui ne fut pas sous le Pentium D, vu que les L2 étaient séparés et ne pouvaient dialoguer entre-eux qu'en passant par le FSB.

En fait je ne savais pas comment Intel a conçu son Atom dualcore, et j'ai naïvement imaginé qu'ils avaient fait ça "proprement" cad comme le Yonah ou les A64 X2.
Et finalement, ils ont fait comme avec le P-D, alors que le FSB est minuscule.

[Yasko]

A partir du moment ou c'est deux dies accollés, je ne sais pas si il y a d'autres alternatives.
On peut faire passer un bus "interne" (pour relier les 2 L2 par exemple) par le packaging ?