ARM, architecture, news, etc.

**Møgluglu** · 26/08/2009, 14h00

Envoyé par newbie06

Un peu plus sérieux : OMAP4430 http://www.heise.de/newsticker/Hot-C...meldung/144183

Question con : ça sert à quoi les 48KB de "On-chip L3 RAM"? Comme buffer de communication entre les différents bidules branchés sur l'interconnect?

Envoyé par fefe

Tiens, j'aurais du aller a Hotchips

.

Mince, on comptait sur toi pour nous faire un compte-rendu.

(moi je peux pas, y'a Euro-Par en même temps. Vraiment, les organisateurs de Hotchips ont merdé.

)

**newbie06** · 26/08/2009, 15h16

Envoyé par Møgluglu

Question con : ça sert à quoi les 48KB de "On-chip L3 RAM"? Comme buffer de communication entre les différents bidules branchés sur l'interconnect?

Pas con ta question, et je n'ai pas la réponse... Ton hypothèse de buffer est plausible (bien que je ne pense pas que ça bufferise n'importe quel trafic interconnect, ça n'aurait pas beaucoup de sens). Une autre hypothèse pourrait être qu'il s'agit de la RAM dédiée au moniteur sécurisé (les 128 Ko de ROM dans le MPU sont probablement pour ce moniteur).

Un truc que je trouve intéressant est qu'il semble que le MPU est directement relié au contrôleur mémoire, ce qui, enfin, permettrait d'avoir une bande passante qui ressemble à quelque chose

**newbie06** · 27/08/2009, 13h47

http://www.akihabaranews.com/en/news...s.php?id=18763

**Lissyx** · 13/09/2009, 11h26

Tiens, des bonnes nouvelles côté consommation électrique sous Linux : http://lwn.net/Articles/347575/. Ça doit entrer dans le 2.6.32.

**newbie06** · 13/09/2009, 13h41

Envoyé par newbie06

Pas con ta question, et je n'ai pas la réponse... Ton hypothèse de buffer est plausible (bien que je ne pense pas que ça bufferise n'importe quel trafic interconnect, ça n'aurait pas beaucoup de sens). Une autre hypothèse pourrait être qu'il s'agit de la RAM dédiée au moniteur sécurisé (les 128 Ko de ROM dans le MPU sont probablement pour ce moniteur).

Ta question n'était pas con, mais ma réponse l'était : la RAM sécurisée semble se trouver sur le MPU...

**newbie06** · 16/09/2009, 14h11

http://www.arm.com/news/25922.html

En resume : deux hard macro dual-core Cortex-A9 40nm, une optimisee pour la vitesse a 2 GHz et l'autre optimisee pour le power.

**fefe** · 16/09/2009, 16h03

Quel budget power a 2GHz, quel type de voltage (1V?, 1.1V?), pareil pour la version a 250mW, quelle frequence (1GHz ?). Ces press release ca contient jamais rien

Ca a l'air interressant

. Tu me dis quand je peux acheter un systeme avec !

**newbie06** · 16/09/2009, 16h17

Oui, ces press releases sont vraiment penibles. Pour le reste, soit je ne peux rien dire, soit c'est entre les mains des clients potentiels d'ARM...

Au fait, Torvalds a pose une chouette question sur RWT : http://realworldtech.com/forums/inde...02552&roomid=2
Je me demande qui peut dire ce que consomme vraiment un Atom (sans le "bruit" autour).

**fefe** · 16/09/2009, 17h15

C'est plutot Linus qui se plante completement la. En l'absence de turbo, certe il existe des workloads qui depassent le TDP, mais le TDP est choisi de maniere a ce qu'ils representent moins de 1/2% des applications et ne contiennent aucune application courante. En pratique le TDP est largement au dessus de l'essentiel des applications (a moins que tu ne fasses tourner que Linpack, dans ce cas l'utilisation du power a TDP est un choix judicieux...).

Qui plus est pour des raisons de binning, le TDP est calcule pour le plus mauvais die qui peut finir dans cette bin, donc non seulement tu as peu d'applications qui y arrivent, mais en plus il y a peu de die qui peuvent effectivement l'atteindre.

Il y a un facteur ~2 de power a frequence peak entre le meilleur die et le plus mauvais die qui sortent d'une chaine de production, donc encore une fois qu'il y ait une version a 4W pour ecouler les mauvaid dies me semble tout a fait normal.

D'ailleurs ca me surprend de Linus, en general il se documente un peu avant de parler.

PS: non je n'irai pas commenter sur RWT.

**newbie06** · 16/09/2009, 17h22

OK. Mais il ne s'agit neanmoins pas de peak power, et Linpack, dans le cadre de l'article de RWT est plutot adequat, puisqu'il s'agit d'avoir le max d'ops DP/W, non ?

Bref, le TDP semble donc plutot fiable

PS - Si, si viens sur RWT, tu peux meme invoquer Paul de Mone pour rire de l'Itanium

**fefe** · 16/09/2009, 17h51

Je connais bien RWT et les forums de aces, mais c'est trop high profile pour que je poste. En francais dans un forum recule du web, pas de problemes

.

**newbie06** · 17/09/2009, 10h43

Cet "article" donne les chiffres suivants de consommation :
0.5W @ 800 MHz
1.9W @ 2 GHz

Pour le fun : http://www.coremark.org/benchmark/index.php
L'A9 4 coeurs a des perfs a peu pres similaires a un E5405.
Pour info, ce bench doit scaler quasi-lineairement avec la frequence et avec le nombre de coeurs (pas de partage de donnees, ni de lock).

PS - Si j'ecris "pour le fun", c'est que personnellement je n'accorde que peu de credit a ce benchmark, meme si ca reste un peu mieux que le debilissime Dhrystone.

**Yasko** · 17/09/2009, 13h07

Envoyé par fefe

En francais dans un forum recule du web, pas de problemes

.

Va dire ça au Doc, que son serveur en carton il arrive même pas à faire tourner un coin perdu du net.

**fefe** · 17/09/2009, 16h28

Ce canard est un scandale de toutes facons !

**fefe** · 17/09/2009, 17h47

Envoyé par newbie06

Cet "article" donne les chiffres suivants de consommation :
0.5W @ 800 MHz
1.9W @ 2 GHz

Pour le fun : http://www.coremark.org/benchmark/index.php
L'A9 4 coeurs a des perfs a peu pres similaires a un E5405.
Pour info, ce bench doit scaler quasi-lineairement avec la frequence et avec le nombre de coeurs (pas de partage de donnees, ni de lock).

PS - Si j'ecris "pour le fun", c'est que personnellement je n'accorde que peu de credit a ce benchmark, meme si ca reste un peu mieux que le debilissime Dhrystone.

Interressant, je me demande juste ce que ca donne sur du code server qui passe son temps a exercer le sous systeme memoire et les interconnexions. On se souvient de la longue domination d'AMD sur les serveurs, non pas parce qu'ils avaient un bon core (il etait comparable a la competition) mais parce qu'ils avaient HT au lieu d'un FSB. La performance serveur est vraiment une autre bestiole.

PS, je suis interresse par un score de Pentium 4 a Coremark, tu as ca (pas un celeron mais genre un P4 Northwood a 3.2GHz) ?

**newbie06** · 17/09/2009, 18h03

Envoyé par fefe

e suis interresse par un score de Pentium 4 a Coremark, tu as ca (pas un celeron mais genre un P4 Northwood a 3.2GHz) ?

C'est bon ca ? J'y comprends rien

Code:

vendor_id       : GenuineIntel
Cpu family      : 15
Model           : 4
Model name      :                   Intel(R) Xeon(TM) CPU 3.20GHz
Stepping        : 1
Cpu MHz         : 3200.326
Cpuid level     : 5

Vite fait, j'ai ca:
CoreMark 1.0 : 5206.114818 / GCC3.4.6 20060404 (Red Hat 3.4.6-3) -O2 -DPERFORMANCE_RUN=1 -lrt / Heap

**fefe** · 17/09/2009, 18h28

C'est un Prescott, qui a priori devrait etre moins bon a frequence egale a moins qu'il y ait du 64k aliasing dans coremark.

Northwood c'est model 13, Prescott c'est 15.

**newbie06** · 17/09/2009, 18h35

J'ai du P3 900 MHz si tu veux

**fefe** · 17/09/2009, 18h39

Un EV67 en stock ? Un itanium ? Un power6 ? Je suis interresse de voir ce qu'une archi "large" obtient

.

**Neo_13** · 17/09/2009, 19h51

J'ai un EV56 quelque part... Mais je peux pas bencher avant ouhlà, au moins 1mois.

**Minuteman** · 17/09/2009, 20h01

Je me suis séparé de mon EV67 il y a 2 mois...tu devrais aller demander sur IRC, freenode #alpha

**Møgluglu** · 17/09/2009, 20h37

On a un EV6 et un EV67.
Mais si je lance un truc lourd dessus c'est tout le réseau de la fac qui tombe.

**fefe** · 17/09/2009, 20h39

[Mode Troll on]
C'est pas un truc lourd, c'est un bench pour ARM !

**Møgluglu** · 17/09/2009, 20h57

Bon j'ai essayé :

Code:

Bash-2,00$ ./coremark.exe  0x0 0x0 0x66 0 7 1 2000 > ./run1.log
Segmentation fault

Ah ouais, c'est bien un bench pour ARM.

Edit: ouais, j'avais pas changé un typedef en 64-bit comme décrit au fin fond d'un obscur readme.

Code:

CoreMark Size    : 666
Total ticks      : 14766076
Total time (secs): 14.766076
Iterations/Sec   : 2031.683976
Iterations       : 30000
Compiler version : Compaq C V6.5-011 on Compaq Tru64 UNIX V5.1B (Rev. 2650)
Compiler flags   : -O4 -arch ev67 -DPERFORMANCE_RUN=1  
Memory location  : STACK

Code:

CoreMark Size    : 666
Total ticks      : 13849446
Total time (secs): 13.849446
Iterations/Sec   : 1444.101085
Iterations       : 20000
Compiler version : GCC2.95 19990728 (release)
Compiler flags   : -O3 -DPERFORMANCE_RUN=1  
Memory location  : STACK

EV6.7 667MHz
Soit 3.0 CoreMark/MHz...

**fefe** · 17/09/2009, 21h58

Soit a peu pres la meme chose qu'un core 2 / un peu mieux que le A9

. C'est un bench qui aime les superscalaires larges

.

**newbie06** · 17/09/2009, 22h50

Envoyé par Møgluglu

Edit: ouais, j'avais pas changé un typedef en 64-bit comme décrit au fin fond d'un obscur readme.

Ca me rappelle les jours passés à compiler lorsque les premiers Alpha sont arrivés, un pur bonheur

Bon vu la fréquence ça doit être un ev67, 21264A.
3.0/MHz c'est pas mal quand même. Ils avaient vraiment fait du bon boulot entre leur chip et leurs compilo. Encore une bonne raison de regretter l'Alpha

**newbie06** · 17/09/2009, 23h01

http://www.itproportal.com/portal/ne...-cpus/showall/

"Although the chips are not compatible with desktop based Windows,
Nothing would prevent one of ARM's partners to come up with a
Hardware-based virtualised environment like Wine or using a solution
Like Win4Lin."

C'est bô non ?

**newbie06** · 03/11/2009, 14h03

Le nouveau SoC de ST/Ericsson a base de Cortex-A9 :
http://www.slashgear.com/st-ericsson...video-0362588/
http://www.stericsson.com/platforms/U8500.jsp

La carte de dev :
http://www.malideveloper.com/platfor...t-platform.php

**Alexko** · 10/11/2009, 00h42

http://www.arm.com/news/26063.html

C'est un peu vieux, mais ça a lancé la machine à spéculation dans ma tête :

- Nvidia produit Tegra, un SoC basé sur un CPU ARM et un GPU Nvidia, produit par... TSMC ?
- AMD prévoit de remplir la tranche 10 - 100 W avec Stars pour le moment, et Bulldozer par la suite. La tranche 1 - 10 W sera laissée à Bobcat.
- AMD n'a rien de prévu en-dessous de 1 W.
- AMD fait produire ses CPU et bientôt ses GPU (au moins Llano et compagnie) par GlobalFoundries.
- À partir du process 28 nm (2011 normalement) GlobalFoundries pourra produire des CPU ARM pour quiconque le souhaitera.

D'où mon interrogation : qu'est-ce qui empêchera AMD de produire un Tegra-like basé sur un CPU ARM et sur leur propre architecture GPU, qui a l'avantage d'être nettement meilleure que celle de Nvidia en performances/(taille x power) ? Ou alors d'offrir sa technologie sous licence, comme ARM, de façon à ce que des tiers puisse concevoir un Tegra-like ? Ça me semble être un très bon moyen pour AMD de s'introduire sur le marché des smartphones et autres appareils de petite taille sans avoir 3 architectures simultanées, et c'est quelque chose qu'Intel semble incapable de faire avec Atom, et aurait du mal à faire avec un core ARM et leurs GPU pourris.

**newbie06** · 10/11/2009, 01h29

Pour pouvoir concevoir un CPU ARM, il faut acheter une license d'architecture. Intel en avait une qu'ils ont revendue à Marvell. On peut donc en conclure qu'ils ne sont pas intéressés.

Par ailleurs, pour faire fondre des SoC avec du ARM, il faut que le client de la fonderie ait la license du coeur à utiliser. ARM se fiche de savoir qui fabrique les CPU. Tout au plus, il y a du tuning et/ou du partenariat sur un process, mais du fait même du modèle économique d'ARM devenir le partenaire exclusif d'un fondeur n'est pas une option

Maintenant savoir ce que veut faire AMD, hé bien je n'en ai aucune idée. Peut-être ont-ils d'autres choses à faire que de s'inquiéter du marche <1W ?

EDIT : J'oubliais un détail. Même si AMD est avant tout un fabricant de CPU/GPU, il ne faut pas oublier toute la partie soft qui est nécessaire autour ; et j'ai quand même l'impression que leurs gus sont très bons en x86 et en Windows ; pour ce qui est d'autres archi et de Linux, c'est pas la joie...

Discussion: ARM, architecture, news, etc.

Outils de la discussion

Règles de messages