ARM, architecture, news, etc.

[Møgluglu]

Vu qu'ils sont 64-bit, il fallait leur donner un numéro qui soit au moins le double de celui de l'A15, et on rajoute encore environ 25 de plus parce que c'est des nouvelles micro-archi. C'est ça le raisonnement du marketing ?

[Dandu]

Le Cortex A15 tabasse bien un Atom, en fait, dans un Chromebook. http://www.anandtech.com/show/6422/s...s-cortex-a15/6

[newbie06]

Le Cortex A15 tabasse bien un Atom, en fait, dans un Chromebook. http://www.anandtech.com/show/6422/s...s-cortex-a15/6

Mouai, comment dire ? Ne peut etre surpris que celui qui a cru un jour que Medfield etait vraiment plus performant qu'un A9 parce qu'il etait plus rapide sur Sunspider?

[Alexko]

Mouai, comment dire ? Ne peut etre surpris que celui qui a cru un jour que Medfield etait vraiment plus performant qu'un A9 parce qu'il etait plus rapide sur Sunspider?

Mais, mais, mais… 2 GHz !

[newbie06]

Mais, mais, mais… 2 GHz !

Ouai 2 GHz parce que Sunspider est tellement court que Medfield peut rester en mode turbo tout le long

Remarque j'ai jamais vu d'etude sur les variations de frequence des CPU pendant les bench, que ce soit chez Intel ou chez ARM. Ca pourrait etre interessant ca.

(Enfin si, j'avais vu un article, sur Anand il me semble, qui montrait comment un SB ULV en chiait pour rester dans son TDP en faisant alternativement varier la frequence du GPU et celle du CPU rendant le FPS tres variable et le jeu quasi injouable.)

[fefe]

(Enfin si, j'avais vu un article, sur Anand il me semble, qui montrait comment un SB ULV en chiait pour rester dans son TDP en faisant alternativement varier la frequence du GPU et celle du CPU rendant le FPS tres variable et le jeu quasi injouable.)

Il y a 2 manieres de voir les choses:
-tu mets autant de hardware que tu peux, et tu utilise des algorithmes dynamiques de power management pour optimiser ton allocation du TDP. Le resultat est que tu es toujours a TDP et tu bouges le budget plus ou moins efficacement entre les composants
-tu minimises la quantite de hardware et tu n'atteints le TDP que dans des scenarios lourds, et le reste du temps economise du power.

Suivant le "monde" duquel tu viens, tu interpretreras l'autre de maniere negative . "En chier pour rester dans le TDP" vs "maximiser l'utilisation du budget power". Et "tenir facilement dans le TDP" vs "gacher des opportunites pour plus de performance". Bien entendu j'augmente le contraste histoire d'avoir un argument, mais la question de perspective reste la meme.

[Dandu]

Mouai, comment dire ? Ne peut etre surpris que celui qui a cru un jour que Medfield etait vraiment plus performant qu'un A9 parce qu'il etait plus rapide sur Sunspider?

Sans aller jusque là (vu que Sunspider dépend à mort du navigateur), la différence est quand même importante.

---------- Post added at 19h16 ---------- Previous post was at 19h13 ----------

Ouai 2 GHz parce que Sunspider est tellement court que Medfield peut rester en mode turbo tout le long

Remarque j'ai jamais vu d'etude sur les variations de frequence des CPU pendant les bench, que ce soit chez Intel ou chez ARM. Ca pourrait etre interessant ca.

(Enfin si, j'avais vu un article, sur Anand il me semble, qui montrait comment un SB ULV en chiait pour rester dans son TDP en faisant alternativement varier la frequence du GPU et celle du CPU rendant le FPS tres variable et le jeu quasi injouable.)

C'est encore plus drôle avec IVB en fait : si tu compares un modèle ULV et un modèle classique qui ont un Turbo à la même fréquence, t'as des résultats similaires si le test est court.

Comme visiblement le Turbo est activé au moins 30 secondes sur IVB sans gérer la contrainte de TDP (de ce que j'ai compris), si ton test dure 30 secondes ou moins, un IVB à 2,5 (3,2) et un modèle à 1,8 (3,2) ont les mêmes perfs visibles...

[fefe]

Comme visiblement le Turbo est activé au moins 30 secondes sur IVB sans gérer la contrainte de TDP (de ce que j'ai compris), si ton test dure 30 secondes ou moins, un IVB à 2,5 (3,2) et un modèle à 1,8 (3,2) ont les mêmes perfs visibles...

Pour etre plus precis la fenetre actuelle est de 28 secondes sur la plupart des plateformes , et tu n'ignores pas le TDP, tu augmentes juste la limite a L*TDP (L etant generalement 1.25). Donc sur une fenetre de 28 seconde tu auras moins de power disponible dans un IVB 17W que dans un IVB 45W, mais du a la nature non lineaire des augmentations de power avec la frequence, ca permet de se rapprocher en terme de performance. Etant donne que l'essentiel des actions ou l'utilisateur attend une reponse rapide de son ordinateur prennent moins de 20 secondes, ca permet d'ameliorer de maniere significative la performance visible par l'utilisateur.

Comment ca marche ? Tu utilises juste le fait que ton systeme n'est pas a la temperature maximale, et que tu peux depenser plus que les capacites de refroidissement de ton systeme pendant un temps limite, le temps que ca prendra pour le chauffer a la temperature limite. Si tu ne mettais pas de limite au power pendant cette periode la, tu chaufferais beaucoup plus vite qu'en 30 secondes et prendrais aussi des risques d'endommager le ssteme de power delivery (ou tu aurais besoin de VR/batterie cappable de sourcer beaucoup plus de courant).

[Dandu]

OK, merci pour les détails.

Reste que du coup, ça m'a frappé avec les récents Mac portables, les perfs dans les benchs (courts) d'un dual core 2,5 GHz et d'un dual core 1,8 GHz sont les mêmes, alors que dans la durée, c'est pas exactement le cas.

Pour en revenir à ARM, j'espère juste que le temps entre les annonces et la dispo va un peu se rétrécir, parce que ça fait bizarre l'annonce du successeur d'un truc pas dispo

[Alexko]

Pour en revenir à ARM, j'espère juste que le temps entre les annonces et la dispo va un peu se rétrécir, parce que ça fait bizarre l'annonce du successeur d'un truc pas dispo

Un peu comme AMD qui donnait plein de détails sur Steamroller alors que Piledriver n'était pas encore dispo sur desktop. Mais c'est un peu normal quand on a des choses à prouver ou qu'on débarque sur un nouveau marché.

[newbie06]

Pour en revenir à ARM, j'espère juste que le temps entre les annonces et la dispo va un peu se rétrécir, parce que ça fait bizarre l'annonce du successeur d'un truc pas dispo

Qu'est-ce qui est pas dispo ?

[fefe]

Je me suis pose la meme question. A15 est dispo mais pas particulierement "courant".

[Møgluglu]

Et big.LITTLE avec des Cortex A7 et A15, on l'achète où ?

[Dandu]

Le Cortex A7 est pas réellement disponible sur le marché et le A15 vient à peine d'arriver, non ?

[newbie06]

Le Cortex A7 est pas réellement disponible sur le marché et le A15 vient à peine d'arriver, non ?

Certes, mais en terme de CPU A15 est là sur le marché et ARM annonce le suivant, le A57 A7 et A53 ne sont pas très intéressants, ce sont les Atom d'ARM

[fefe]

Vu la progression des numeros des Cortex AXX, j'ai cru un instant qu'il suivaient une serie de Fibonacci (ca aurait ete une super idee !). Mais en fait, non ca va encore plus vite !

[Dandu]

Certes, mais en terme de CPU A15 est là sur le marché et ARM annonce le suivant, le A57 A7 et A53 ne sont pas très intéressants, ce sont les Atom d'ARM

Je trouve les A7 et A53 intéressant, moi, pour les appareils d'entrée de gamme et y a pas mal de SoC annoncés en A7 qui semblent pas mal

[Møgluglu]

Oui, ils ont merdé, le prochain aurait du être le Cortex A16 ou A11 :
http://oeis.org/search?q=5%2C7%2C8%2C9%2C15

L'A7/A53, ça me parait surtout intéressant pour les multicores hétérogènes. Après tout le buzz sur big.LITTLE, on aimerait bien voir le truc marcher en vrai… (car bien sûr, ça marche forcément si le marketing le dit )

[newbie06]

Je sais, c'est une news pas vraiment technique : ARM participe a un consortium qui va acheter une grosse partie des brevets de MIPS.
MIPS continuera cependant a pouvoir utiliser ces brevets gratuitement.

[Møgluglu]

Le reste du consortium, c'est Imagination Technologies ?
http://www.nasdaq.com/article/mips-t...20121106-00030

[newbie06]

http://www.anandtech.com/show/6536/a...-real-showdown

Pas tres glorieux pour l'A15

[Dandu]

C'est que je soupçonnais quand j'avais vu le ChromeBook.

Après, c'est le premier design, je suppose qu'il y a pas d'optimisations ni une gestion très fine du CPU. J'aimerais voir la même chose sur du Cortex A7, ce core me semble intéressant pour l'entrée de gamme et le milieu de gamme.

[fefe]

Pour le GPU, il devrait montrer Energy / frame , montrer une comparaison d'energie sur des benchmarks a temps d'execution constant c'est un peu inutile pour comparer les architectures (bien sur ca te dit combien de temps tu peux jouer sur cette machine).

[Dandu]

Tiens, le big.LITTLE annoncé par Samsung.

Que je me plante pas : un CPU de ce type, même s'il a 8 cores physiques, il en montre que 4 au système, c'est ça ?

[newbie06]

Non, tu peux parfaitement avoir les deux clusters de 4 CPU utilises simultanement. Apres avoir un OS qui supporte ca efficacement est probablement une autre histoire...

[Møgluglu]

Ah oui, ce sont bien 2 clusters de 4 CPU homogènes.

Pour les scénarios visés (migrations entre A7 et A15), avoir 4 clusters de 2 CPU hétérogènes ne serait pas plus efficace ? Même si ça paraît bien plus compliqué à mettre en place.

D'un autre côté, en mode basse conso tous les A15 sont inactifs, donc on peut en profiter pour éteindre ou endormir le cache L2 du cluster.

[newbie06]

Ah oui, ce sont bien 2 clusters de 4 CPU homogènes.

Pour les scénarios visés (migrations entre A7 et A15), avoir 4 clusters de 2 CPU hétérogènes ne serait pas plus efficace ? Même si ça paraît bien plus compliqué à mettre en place.

Pas sur qu'il y aurait un interet reel a ca. Apres tout tu peux toujours eteindre les coeurs d'un cluster dont tu ne te sers pas.

D'un autre côté, en mode basse conso tous les A15 sont inactifs, donc on peut en profiter pour éteindre ou endormir le cache L2 du cluster.

Oui, c'est le but : couper les coeurs et la L2. Le probleme de cette approche est aussi qu'il faut flusher la L2 avant de couper le jus ce qui implique une reduction de la frequence a laquelle tu peux migrer (dans le modele migratoire bien sur).

[Møgluglu]

Je pensais justement au coût de migration. Mon raisonnement est que si tu migres plus souvent entre A7<->A15 qu'entre A7<->A7 et A15<->A15, tu dois avoir intérêt en théorie à former des clusters entre couples de cœurs différents.
Si un A7 et un A15 sont dans le même cluster et partagent un L2, la migration de l'un à l'autre ne coûte pas cher. Maintenant le gain en conso est certainement plus limité, parce que du coup tu dois garder le L2 alimenté, et tu ne peux pas non plus tuner chaque L2 différemment pour la perf/conso.

Après, mon hypothèse peut être fausse, si tu as des applis multi-thread avec beaucoup de communications entre threads.

[newbie06]

Tu ne peux pas avoir deux CPU differents dans le meme cluster. Enfin disons que pour le moment ce n'est pas le cas.

[Lissyx]

En tout cas ça correspond parfaitement à des travaux présentés cet été par un ingénieur R&D de Samsung Corée