Intel Atom

[Alexko]

Ouai mais tu ne peux pas coller deux autocollants "Intel Inside" et "Intel OS Inside" sur un MID, y'a pas la place.

100% Intel, ça rentre

Moi j'ai toujours pas compris à quoi ça servait ces trucs-là, mais bon...

[newbie06]

Moi j'ai toujours pas compris à quoi ça servait ces trucs-là, mais bon...

Ha mais si, quand tu vas au petit coin et que t'as pas envie de lire, tu prends ton MID et tu surfes. C'est bô la technologie !

[Alexko]

J'en connais qui, dans ces circonstances, prennent leur laptop 15" voire 17" :D

[newbie06]

Ca c'est un coup à se cramer à un endroit sensible

[newbie06]

Je ne suis pas le seul à penser ça, mais je ne sais pas si je dois m'inquiéter de penser comme les types de The Inquirer

http://www.theinquirer.net/inquirer/...axis-crumbling

[Minuteman]

Un test de Ion sous Linux: http://www.phoronix.com/scan.php?pag...on_linux&num=1

[Yasko]

Amusant le nom du newser, il est pré-destiné à couvrir la sortie de LRB lui...
J'ai posté un lien sur le topic en HD, Ion + Atom N330 passe bien pour de la lecture BR, mais est insuffisant pour de l'upscaling SD>HD, ou BR avec filtre externe pour avoir les sous-titres (qui désactive l'accélération par l'IGP). Je vous le remets ici.

[Minuteman]

Amusant le nom du newser, il est pré-destiné à couvrir la sortie de LRB lui...

On est au fond du bac, je me suis fait exactement la même réflexion

[fefe]

Fais comme moi tape http://www.google.co.uk/search?q=lin...ient=firefox-a

Conso serveur : http://www.networkworld.com/research...ows-linux.html
Laptop : http://www.phoronix.com/scan.php?pag...dy_power&num=2

Et puis je suppose que tu es au courant du projet lesswatts ?
http://www.lesswatts.org/projects/index.php

Bon, j'ai fait des mesures sur mon Lenovo T61...
Idle power: XP 10.5W, Vista 11.5W, Linux 18W (tous avec les derniers SP/ kernels etc...). Sans appel imo, sachant que l'autonomie est generalement determinee par le power idle. En charge par contre ca devient comparable (je dirais que c'est normal).

[newbie06]

Hé bien ça prouve qu'on ne m'a raconté que des âneries...

Quelle version de Linux était-ce ? Version du kernel ? Le module cpufreq était-il correctement chargé et activé ?

[fefe]

OpenSuse, 2.6.29, oui. Et de toutes facons ce n'est pas le CPU qui est responsable de la difference, le power du cpu est le meme entre XP et linux (j'ai des breakdowns detailles), par contre le reste ce n'est pas le cas (certains composants ont l'air peu ou pas power managed).

[newbie06]

Lamentable. A quand un support complet de l'ACPI et des drivers video au point ?
En plus Linux est supporté par le constructeur sur cette gamme ?

[fefe]

Oui, et ce n'est pas moi qui le developperai, et oui (ils distribuent Suse dessus).

Tu oublies les drivers wireless dans la liste .

[Møgluglu]

le power du cpu est le meme entre XP et linux

Autrement dit, le mode tickless ne sert à rien?
Si tu fais un coup de powertop, tu as un driver qui réveille le CPU toutes les 10ms?

Ou bien parce que les latences de changement de C-state ont diminué sur Merom/Penryn par rapport à Dothan, le tickless n'a plus autant d'influence?

[fefe]

Autrement dit, le mode tickless ne sert à rien?
Si tu fais un coup de powertop, tu as un driver qui réveille le CPU toutes les 10ms?

Ca sert un peu en fait, mais ce qui est economise (quelques dizaines de miliwatts en moyenne) est negligeable face a ce qui est mal gere. L'amelioration des C-states et la rapidite de transition a du empieter sur ces benefices oui.
L'instrumentation pour mesurer le power est hardware au niveau des voltage regulators, l'OS n'a aucune idee que je suis en train de mesurer le power donc normalement mon influence est minime (et la meme quelle que soit l'OS).

[Møgluglu]

L'instrumentation pour mesurer le power est hardware au niveau des voltage regulators, l'OS n'a aucune idee que je suis en train de mesurer le power donc normalement mon influence est minime (et la meme quelle que soit l'OS).

OK.
Sympa de pouvoir mesurer au niveau des VR, quand les ploucs comme nous doivent se contenter de la pince ampèremétrique sur le 12V.

Mais je pensais plutôt à un driver existant genre wireless ou USB qui provoque plus de changements de C-states que nécessaire, ce que powertop détecterait facilement.

[fefe]

Si c'etait le cas, le power du CPU serait nettement plus eleve. Il prend ~0.3W du total sous XP et Linux (le double sous vista). Meme si des optims seraient encore possible, ce n'est pas dans le CPU que tu economiseras les 7.5W de difference... Mais plutot dans ton northbridge, southbridge, wireless, HDD, VR, ou le delta avec XP est >500mW (jusqu'a plus d'1W pour certains).

A vue de nez je dirais aussi que les fonctions d'eco d'energie de la memoire ne sont pas utilisees non plus sous linux (ou mal).

Apres il est peut etre possible de mieux configurer les drivers etc (je suis particulierement ignorant de ce genre de choses vu que je n'ai pas cherche)... Pour faire tout ca, mais quand c'est un OS propose par le constructeur on pourrait s'attendre a ce que ce soit fait par defaut (ou par un outil de configuration fourni).

Donc le probleme n'est pas le CPU, juste tout le reste (a part etonnament l'audio ).

[Minuteman]

Je sais pas si ça a un rapport, mais je sais que sous Fedora ils ont modifié en profondeur la gestion du son par PulseAudio précisément pour éviter des réveils continus, et donc réduire la consommation.

[Møgluglu]

Il prend ~0.3W du total sous XP et Linux (le double sous vista)

Ah ouais quand-même

Donc à l'échelle de la plate-forme, Atom n'apporte strictement rien en conso par rapport à Core 2 (on s'en doutait, mais je pensais pas à ce point-là...)
La conso crête est différente, mais un C2D bloqué à la tension/fréquence mini ne doit pas monter bien haut non plus...

[fefe]

Un C2D ULV exploite dans les memes conditions qu'atom a besoin d'environs 2.5x le budget. Ca demande un packaging et un solution de refroidissement beaucoup plus couteuse donc (et un die ulv coute beaucoup plus aussi, peu de dies/waffer ont les caracteristiques recquises).

[Oxygen3]

Ceci dit, ca confirme les impressions que j'avais, il y'a bien eu aucun effort de fait dans l'économie de puissance sur 'tout le reste' alors que coté CPU, ca a fait d'énormes efforts ...

D'ou aussi les différences entre un Apple et un 'simple' PC à partir du moment ou la machine Apple est sans doute tripatouillée aux petits oignons pour maximiser la batterie (et/ou minimiser la puissance requise)

[Møgluglu]

En lisant le x64/IA-32 optimization reference manual (http://www.intel.com/Assets/PDF/manual/248966.pdf), je tombe par hasard sur les latences/débits d'Atom, pourtant soigneusement planquées dans une section à part.

Le ADDPD de SSE2 (addition double packed) est fait en microcode en 5 cycles non recouvrables sur les 2 unités...
Du coup il est bien plus rentable de faire 2 ADDSD (débit de 1, unité 1) quitte à bouffer un registre de plus...
Quand à MULPD il n'ont même pas osé l'inclure dans la table... [edit: si ailleurs dans la doc: 9 cycles]

Quand on parlait d'implémenter en microcode les instructions-legacy-X86-exotiques-que-plus-personne-n'utilise-de-toute-façon, je pensais pas que ça incluait l'addition SSE2.

[fefe]

Les instructions packed de SSEx ont toujours ete lentes lorsque implementees sur des machines qui n'avaient pas des unites et un datapath de 128 bits (avant Merom chez Intel). Atom n'y echappe pas, mais pas plus que les vieux P3, Banias, P4 (dans une moindre mesure, le datapath etait de 128 bits et les unites de 64), le K7 etc... Atom est un processeur recent avec beaucoup des defauts des vieilles generations de x86, d'ailleurs c'est pour ca qu'il assez peu difficile, a mon avis, de predire quelles ameliorations lui seront apportees dans les futures generation

En pratique une partie de la latence est recouvrable sur la plupart de ces archis, je ne sais pas exactement ce qu'il en est d'atom mais ca serait surprenant qu'ils blockent les 5 cycles du pipeline, 3-4 probablement (1 par moitie + 1 a 2 pour bouger les donnees).

Si tu as du code packed et que tes donnes sont dans des registres 128 bits, tu n'iras pas plus vite que les instructions microcodees etant donnee qu'il te faudra shuffle la partie haute vers la partie basse pour utiliser les SD et reshuffle a l'arrivee a moins que tu les reschedule a la mimine. Bien sur si tu recompiles tout ton programme pour employer SD (et uniquement 64 bits des registres) ca ira plus vite, mais remplacer "betement" les instructions packed par du scalar ne devrait rien gagner.

[newbie06]

http://www.semiaccurate.com/2009/07/...r-atomic-bomb/

14 SoC en cours de design @32nm, ça va être intéressant... Ou pas

[Møgluglu]

Les instructions packed de SSEx ont toujours ete lentes lorsque implementees sur des machines qui n'avaient pas des unites et un datapath de 128 bits (avant Merom chez Intel). Atom n'y echappe pas, mais pas plus que les vieux P3, Banias, P4 (dans une moindre mesure, le datapath etait de 128 bits et les unites de 64), le K7 etc...

Je n'ai plus les chiffres pour tous ces CPU, mais sur Dothan et P4 le débit est divisé par 2 et la latence augmente de 1 cycle (ou débit/4 et 2 cycle pour MULPD sur Dothan), je suis d'accord que c'est optimal étant donné les ressources dispo.

Alors que Atom est quand-même pire :

En pratique une partie de la latence est recouvrable sur la plupart de ces archis, je ne sais pas exactement ce qu'il en est d'atom mais ca serait surprenant qu'ils blockent les 5 cycles du pipeline, 3-4 probablement (1 par moitie + 1 a 2 pour bouger les donnees).

C'est pourtant ce que dit la doc:
ADDPD xmm, xmm: latency 6, throughput 5, units Both
MULPD xmm, xmm: latency 9, throughput 9, unit ??
(aprés c'est fort possible que les deux unités ne soient pas utilisées à fond pendant les 5/9 cycles)

Ils confirment à un autre endroit que ce n'est pas pipeliné:

Note that packed double-precision instructions are not pipelined, using two scalar double-precision instead can achieve higher performance in the execution cluster.

Si tu as du code packed et que tes donnes sont dans des registres 128 bits, tu n'iras pas plus vite que les instructions microcodees etant donnee qu'il te faudra shuffle la partie haute vers la partie basse pour utiliser les SD et reshuffle a l'arrivee a moins que tu les reschedule a la mimine.

J'ai l'impression que c'est exactement ce que le microcode fait.

[fefe]

Je n'ai plus les chiffres pour tous ces CPU, mais sur Dothan et P4 le débit est divisé par 2 et la latence augmente de 1 cycle (ou débit/4 et 2 cycle pour MULPD sur Dothan), je suis d'accord que c'est optimal étant donné les ressources dispo.

Dothan avait un datapath et des registres 64 bits donc pas besoin de shuffle la partie haute du registre vers l'unite. Mais le multiplieur DP n'etait pas completement pipeline...
P4 c'est un peu plus complique, mais en gros tu as un datapath de 128 bits et une unite 64 bits, et pas besoin d'employer de shuffle vu que le datapath le fait tout seul entre les registres et l'unite. Tout etait pipeline sur P4.

Alors que Atom est quand-même pire :

C'est pourtant ce que dit la doc:
ADDPD: latency 6, throughput 5, units Both
MULPD: latency 9, throughput 9, unit ??
(aprés c'est fort possible que les deux unités ne soient pas utilisées à fond pendant les 5/9 cycles)

Atom est in order, une instruction implementee en microcode va couter plus cher que si le programmeur l'ecrivait vu que le microcode ne peut pas reordonnancer les instructions alors que le programmeur le peut. Sur une archi OOO il y a beaucoup d'instructions microcodees mais tu ne le vois pas vraiment grace au reordonnancement. En plus tout est sur le meme port d'execution ou presque donc chaque instruction de microcode bouffe de la bande passante.

Bref vaut mieux compiler en scalar sur Atom , mais ce n'est pas sense etre une brute en FP. Tiens d'ailleurs je n'ai pas regarde, mais quelles sont les capacites flottantes d'un Cortex-A* ou autre cpu visant a etre integre dans des netbooks ?

[newbie06]

Tiens d'ailleurs je n'ai pas regarde, mais quelles sont les capacites flottantes d'un Cortex-A* ou autre cpu visant a etre integre dans des netbooks ?

A8 a une FPU lite (en français ça se traduit par "de merde") non pipelinée. L'unité SIMD (NEON) peut sortir deux opérations SP par cycle (mais pas de DP).
Sur A9, la FPU est meilleure mais est toujours single issue. NEON est le même que sur A8.

[Møgluglu]

OK.
J'avais regardé vite fait le jeu d'instruction VFP, et je me demandais à quelle genre d'archi le concepteur pouvait bien penser en écrivant le jeu d'instruction (un unfused multiply-add, pas de rint mais un div et un sqrt, pas de min/max...)
En fait il y a juste un additionneur et un multiplieur en hard, le reste est fait en soft?

[newbie06]

Le fused MA arrive dans la prochaine révision de l'architecture.
Quant au rint il est bien présent, il s'appele VCVT.
Et tout est fait en hard.

Je me demande quelle doc tu as lue...

[Møgluglu]

Le fused MA arrive dans la prochaine révision de l'architecture.

Et tout est fait en hard.

Même la division/sqrt? Ça peut effectivement avoir un intérêt pour la conso...

Je me demande quelle doc tu as lue...

L'ARM (Architecture Reference Manual, ah ah) de l'ARMv5:
http://infocenter.arm.com/help/index...00i/index.html

Je m'y perd un peu entre NEON, VFP, les numéros de version des archi, des micro-archi, des implémentations, les extensions... C'est pire que les SSE, vos trucs.

Edit: NEON n'a effectivement rien à voir avec VFP, NEON est en simple précision seulement et n'a pas de division (VCVT c'est un lrint, rien à voir )