ARM, architecture, news, etc.

[ylyad]

C'est bien pourquoi j'ai dit que j'hésiterai certainement pour le prochain. Quand j'ai acheté mon iPhone, Android sortait tout juste...

[Dandu]

J'ai rien hésité du tout... La POSSIBILITE de bidouille sur Android ne signifie pas que il faut absolument bidouiller pour s'en servir. Les HTC, notamment, grâce à Sense, fonctionne remarquablement en stock.

C'est pas le cas de tous les modèles, malheureusement, et les MAJ se font parfois attendre. Mais c'est sur que HTC fait un très bon boulot.

Ma femme, qui n'est certainement pas une bidouilleuse, a pris un Samsung Galaxy S et elle n'a aucune difficulté à l'utiliser. Pour faire une vraie comparaison il faudrait lui mettre un iPhone dans les mains, mais bon...

Faut essayer avec un iPhone, mais le Galaxy S est plutôt un bon téléphone, mais on est loin de la fluidité d'un iPhone 4, qui pour le coup a pas encore de réel concurrent sur ce point. Quand tu passes d'un iPhone 4 à autre chose, ça « choque ».

Sinon, mes expériences Android sont pas top : j'ai testé des applis sur un truc particulier (les lapins Nabaztag) et en dehors du fait que le Market est pas top, les applis étaient infects. Les devs. préfèrent visiblement l'iPhone (et je parle pas de la galère pour les captures).

J'ai vraiment du mal sur Android avec les applications. Autant le surf, la téléphonie et les applications de base sont pratiques (et au-dessus d'iOS sur pas mal de point), autant la partie applicative me semble très moyenne, même si au-dessus de Palm/Nokia/BlackBerry

[newbie06]

J'ai vraiment du mal sur Android avec les applications. Autant le surf, la téléphonie et les applications de base sont pratiques (et au-dessus d'iOS sur pas mal de point), autant la partie applicative me semble très moyenne, même si au-dessus de Palm/Nokia/BlackBerry

Est-ce dû aux développeurs ou à l'environnement de développement (on peut supposer qu'en terme de fonctionnalités de l'OS ça se vaut puisque les apps de base sont du même niveau selon ce que tu dis) ?

[ylyad]

Faut essayer avec un iPhone, mais le Galaxy S est plutôt un bon téléphone, mais on est loin de la fluidité d'un iPhone 4, qui pour le coup a pas encore de réel concurrent sur ce point. Quand tu passes d'un iPhone 4 à autre chose, ça « choque ».

J'ai pas d'iPhone 4, et je m'en tiens autant aussi éloigné que possible, car je sais que sinon, je craquerai mais là, c'est pas une histoire d'OS, mais le matos, l'écran en particulier

[Dandu]

J'ai pas d'iPhone 4, et je m'en tiens autant aussi éloigné que possible, car je sais que sinon, je craquerai mais là, c'est pas une histoire d'OS, mais le matos, l'écran en particulier

L'écran est le plus intéressant, les perfs, en pratique, mon 3GS est aussi rapide. Et c'est une question d'optimisation, parce que des appareils android avec une plateforme matérielle meilleure, y en a. ce que propose Apple, c'est classique, Cortex A8 + PowerVR (600 MHz dans le 3GS, 800 MHz dans le 4)

Est-ce dû aux développeurs ou à l'environnement de développement (on peut supposer qu'en terme de fonctionnalités de l'OS ça se vaut puisque les apps de base sont du même niveau selon ce que tu dis) ?

De ce que j'ai pu avoir comme infos, plusieurs raisons.

La première, c'est l'environnement de dev., de fait. C'est ouvert, mais pas comparable à Visual Studio ou xCode, faut un peu d'expérience.

La seconde, c'est que les gens ne veulent pas payer, ce qui démotive les devs. C'est con, mais sur iOS, les gens payent facilement 0,80 €, sur Android, les applis payantes marchent mal.

La dernière, c'est la fragmentation, en terme de versions d'OS (même si ça tend à changer, une bonne partie des appareils sont maintenant en 2.x) mais surtout en terme de matos. Y a énormément de taille/définition d'écran, de plateforme matérielle en terme de CPU/GPU, etc. Sous iOS, y a réellement 2 OS, avec des fonctions proches (et en pratique, iOS 3.x est abandonné) et en gros 2 plateformes matérielles (Cortex A8/PowerVR SGX et ARM11/MBX Lite) et trois définitions d'écrans (480, 960 et 1024), sachant que la compatibilité est simple.

Ca me plairait qu'Android bouge un peu plus sur ce point, que ça fasse réagir Apple, en fait

[newbie06]

La première, c'est l'environnement de dev., de fait. C'est ouvert, mais pas comparable à Visual Studio ou xCode, faut un peu d'expérience.

Oui, mais il faut un Mac pour développer pour iBidule, c'est un pur scandale. En tout cas de mon point de vue, c'est rédhibitoire. Résultat mes idées d'application pour iPad ne prendront jamais vie sauf si on m'offre un Mac

(mode se la pète) On m'avait proposé de bosser chez Google sur une partie de l'env de dév Androïd ; j'ai décliné, je préfère le design de CPU

Sinon pour le point de la fragmentation HW, c'est en effet un vrai souci. Mais cela existe aussi chez Apple comme tu le dis : tailles d'écran différentes, CPU très différents, GPU très différents. Pour des applis un peu pointues chacune de ces différences est extrêmement sensible, parce qu'on parle de facteurs 2 à 4 minimum... Les différences sont gérées différemment chez Android ?

[Dandu]

Oui, mais il faut un Mac pour développer pour iBidule, c'est un pur scandale. En tout cas de mon point de vue, c'est rédhibitoire. Résultat mes idées d'application pour iPad ne prendront jamais vie sauf si on m'offre un Mac

(mode se la pète) On m'avait proposé de bosser chez Google sur une partie de l'env de dév Androïd ; j'ai décliné, je préfère le design de CPU

Sinon pour le point de la fragmentation HW, c'est en effet un vrai souci. Mais cela existe aussi chez Apple comme tu le dis : tailles d'écran différentes, CPU très différents, GPU très différents. Pour des applis un peu pointues chacune de ces différences est extrêmement sensible, parce qu'on parle de facteurs 2 à 4 minimum... Les différences sont gérées différemment chez Android ?

C'est sur que Mac (récents) obligatoire ça aide pas. Ca fait vendre des Mac mini.

Sur iOS, de ce que j'ai pu voir, les devs font pas 50 versions, et se contentent généralement de prendre l'iPhone 3G comme base et de faire une version iPhone 4 (ce qui est simple, suffit en gros de doubler les graphismes). Ou alors, ils font une version limitée aux modèles en A8/SGX.

Le seul qui a fait un gros boulot, c'est Carmack avec Rage : y a une version multimachine et une autre pour les modèles SGX, avec les trois définitions gérées.

Avec Android, y a bien plus de fragmentation, et surtout y a des plateformes entrée de gamme qui se vendent en masse (HTC Wildfire, par exemple) alors que le gros des iPhone est en A8/SGX. Un hit comme Angry Birds sur Android (et c'est pas un truc lourdingue) est pas supporté sur du matos récents, parce que trop lent.

[ylyad]

Oui, l'écran est grave classe. Par contre, je te suis sur la fragmentation. Déjà, ça permet une cohérence logicielle énorme: en gros, les devs peuvent considérer que les users upgradent, et les users peuvent se dire que leur bécane est mise à jour. Sérieux, ça joue vachement pour moi: mon téléphone reste à jour. Et ça, ça change beaucoup de choses par-rapport au Nokia de base.
Et c'est clair que sur le matos, ce sont deux approches très différentes: Apple privilégie la cohérence là où Google privilégie le choix du user. Les deux ont leurs avantages et inconvénients.

[newbie06]

Performance de la tablette Viewsonic G avec son Tegra2.

[fefe]

Pas degueu, je suis plus interresse dans la la comparaison avec un Atom+SGX parce que il me semblait assez evident que le A9 allait exploser le A8 (c'est l'effet OOO )

[newbie06]

Et voilà, c'est officiel : Windows sur ARM...

nVidia se lance dans le CPU pour desktop/serveur avec de l'ARM : projet Denver

[fefe]

Que des bonnes nouvelles, enfin un peu de piment.

[newbie06]

Un produit grand public à base d'A9 : http://www.scei.co.jp/corporate/release/110127a_e.html

[Møgluglu]

Intéressant survey des processeurs tenus-à-la-main sur Beyond3D:
http://www.beyond3d.com/content/articles/111

[newbie06]

Il y a quelques petites erreurs, mais ca reste une interessante lecture.

[hellsing]

presence-pc fait aussi une petit overview des ARM en ce moment.
Ca reste sympa a lire.

[Dandu]

Oui, d'ailleurs, si certains ici voient des erreurs et des trucs à corriger dans mes papiers sur les puces ARM, dites-le, hein, c'est pas un sujet que je maitrise à 100 %, y a des masses d'infos.

[Dandu]

Je reviens du MWC et j'ai rencontré pas mal de gens qui font du ARM, et j'ai une question pour les experts : NVIDIA utilise pas NEON dans Tegra 2 et c'est en gros les seuls (Tegra 3 y passe).

Y a une raison valable selon vous, autre que l'officiel du genre "ça prend de la place et notre GPU fait mieux" ? Parce que vu le code optimisé NEON, genre dans les décodeurs WebM, ça peut poser des problèmes

[newbie06]

Je reviens du MWC et j'ai rencontré pas mal de gens qui font du ARM, et j'ai une question pour les experts : NVIDIA utilise pas NEON dans Tegra 2 et c'est en gros les seuls (Tegra 3 y passe).

Y a une raison valable selon vous, autre que l'officiel du genre "ça prend de la place et notre GPU fait mieux" ? Parce que vu le code optimisé NEON, genre dans les décodeurs WebM, ça peut poser des problèmes

Mon avis personnel qui n'engage que moi...

NEON est devenu indispensable en partie à cause des faiblesses de la FPU non pipelinée de Cortex-A8. Donc même en-dehors des applications standard d'une unité SIMD (codec, affichage 2D, etc.) qui auraient pu être remplacées par des IP tunées, hé bien tout l'ecosystème logiciel s'est retrouvé à utiliser du NEON pour ne pas pâtir d'une FPU pourrie. Donc impossible de passer outre sur Tegra 3 quelles que soient les perfs de leur GPU et/ou de leurs IP video.

Donc même si NEON est aussi gros qu'un coeur A9 (cf. ici), il est juste devenu indispensable.

AMHA c'est une bonne chose

[Dandu]

oui, j'avais bien compris, mais pourquoi pas le mettre à la base ? Parce du coup, sur Tegra 2, y a eu pas mal de boulot sur Flash par exemple (qui a besoin de Neon, de base)

Sinon, Kraits chez Qualcomm a l'air sympa, et l'OMAP5 aussi

[newbie06]

Ben je l'ai dit : c'est bien gros quand même. Si tu ne le mets pas, tu pourrais par exemple doubler tes tailles de L1 ce qui bénéficierait à bien plus de programmes que NEON.

L'A9600 de ST-E est sympa aussi

[Dandu]

j'ai malheureusement pas pu aller chez ST-E ni chez Renesas

[Møgluglu]

NEON est devenu indispensable en partie à cause des faiblesses de la FPU non pipelinée de Cortex-A8. Donc même en-dehors des applications standard d'une unité SIMD (codec, affichage 2D, etc.) qui auraient pu être remplacées par des IP tunées, hé bien tout l'ecosystème logiciel s'est retrouvé à utiliser du NEON pour ne pas pâtir d'une FPU pourrie.

Tu peux nous faire un petit rappel des specs de la FPU, VFP et NEON?

De ce que j'avais cru comprendre VFP gère la simple et la double IEEE, a un mode vectoriel (au sens Cray) dont personne ne se sert, et ses implémentations sont archi-lentes.

Neon gère un format qui ressemble à la simple précision, mais n'est pas conforme IEEE (flushe les sous-normaux à zéro et ne connaît qu'un mode d'arrondi). Ses implémentations sont du SIMD pipeliné.

Donc en fait on a le choix entre une FPU lente et une qui calcule faux, c'est bien ça?
(Face à ce dilemme les programmeurs ont naturellement tous adopté celle qui calcule faux sans se poser de question. )

Il y a un espoir qu'on ait un truc correct un jour, avec un FMA?

[Foudge]

Intel à l'assault des ARM avec son futur Medfield :
http://www.hardware.fr/news/11315/in...eld-meego.html
nVidia Tegra 3 :
http://www.hardware.fr/news/11314/nv...core-2011.html

"Une chose est sûre, le monde des smartphones, des tablettes, et des autres MIDs, sera animé dans les mois et les années à venir." HFR

[newbie06]

De ce que j'avais cru comprendre VFP gère la simple et la double IEEE, a un mode vectoriel (au sens Cray) dont personne ne se sert, et ses implémentations sont archi-lentes.

Le mode vectoriel est obsolète et n'a jamais été implémenté efficacement
En revanche la FPU de l'A9 est tout à fait correcte (même si je crois que ce n'est qu'une DP tous les 2 cycles).

Neon gère un format qui ressemble à la simple précision, mais n'est pas conforme IEEE (flushe les sous-normaux à zéro et ne connaît qu'un mode d'arrondi). Ses implémentations sont du SIMD pipeliné.

Exact.

Donc en fait on a le choix entre une FPU lente et une qui calcule faux, c'est bien ça?
(Face à ce dilemme les programmeurs ont naturellement tous adopté celle qui calcule faux sans se poser de question. )

T'as tout compris ! Enfin c'est ainsi que ça s'est passé sur l'A8, qui a commis AMHA l'impardonnable erreur de coller une FPU minable. Voilà comment NEON est devenu indispensable (avec le côté bénéfique que j'espère que les gens vont arrêter les conneries en fragmentant les supports de jeu d'instructions, on peut rêver).

Il y a un espoir qu'on ait un truc correct un jour, avec un FMA?

Ptet dans ARMv8, va savoir

---------- Post ajouté à 23h12 ----------

Intel à l'assault des ARM avec son futur Medfield :
http://www.hardware.fr/news/11315/in...eld-meego.html

Un truc qui m'a vachement étonné est que le type d'Intel semble avoir insisté sur la puissance consommée en mode actif. Sauf que le CPU d'un téléphone est presque tout le temps inactif, même quand on croit s'en servir (hors certains cas bien sûr ). Par exemple pour téléphoner il est soit complètement éteint soit à très basse fréquence, le boulot étant fait ailleurs. Bon c'est sûr si on joue ou qu'on surfe sur des pages gourmandes, ça change tout, mais ça reste minoritaire comme usage même pour un smartphone, non ?

[Foudge]

Un truc qui m'a vachement étonné est que le type d'Intel semble avoir insisté sur la puissance consommée en mode actif. Sauf que le CPU d'un téléphone est presque tout le temps inactif, même quand on croit s'en servir (hors certains cas bien sûr ). Par exemple pour téléphoner il est soit complètement éteint soit à très basse fréquence, le boulot étant fait ailleurs. Bon c'est sûr si on joue ou qu'on surfe sur des pages gourmandes, ça change tout, mais ça reste minoritaire comme usage même pour un smartphone, non ?

Du coup je comprend mieux la remarque de Guillaume dans sa news :

Intel profite évidemment de ses procédés de fabrication très avancés, mais il reste à voir si Medfield améliorera la consommation au repos assez élevée de Moorestown. Le jeu d’instruction x86 requiert en effet des décodeurs particulièrement couteux en puissance par rapport à l’architecture RISC d’ARM. Quasi négligeable sur les architectures PC modernes, le cout de l’architecture x86 redevient un problème à très basse puissance.

[Møgluglu]

Concernant la deuxième phrase, ça ne me semble pas terriblement convainquant comme argument. Le cache d'instructions consomme nettement plus que le décodage il me semble, donc c'est la compacité du code qui fait la différence.
Entre x86 et Thumb, je veux bien croire que Thumb gagne, mais entre x86 et ARM c'est moins clair.

La différence en conso statique et dynamique sont surtout dues à des différences de micro-archi et de process à mon avis.

Et puis il dit qu'il voit pas le rapport avec la conso au repos. Quand il est au repos le CPU ne décode pas d'instructions, ni ARM ni x86. (À la conso statique des décodeurs près.)

[Møgluglu]

T'as tout compris ! Enfin c'est ainsi que ça s'est passé sur l'A8, qui a commis AMHA l'impardonnable erreur de coller une FPU minable. Voilà comment NEON est devenu indispensable (avec le côté bénéfique que j'espère que les gens vont arrêter les conneries en fragmentant les supports de jeu d'instructions, on peut rêver).

OK merci.
On a une idée des raisons qui ont rendu le mode vectoriel de VFP obsolète?
Quand on voit la surface prise par NEON et si tu dis qu'il est utilisé en mode scalaire la plupart du temps, ça semble parfaitement raisonnable d'avoir une seule FPU scalaire entièrement pipelinée et de remplir le pipeline avec des vecteurs. Du point de vue conso, ça parait intéressant (moins d'instructions lues et décodées en mode vectoriel).

Il y avait des problèmes de conception qui ont fait qu'on a préféré repartir quasi from scratch avec NEON? En particulier, qu'est-ce qui empêchait une implémentation SIMD "horizontale" de VFP?

[fefe]

Au repos, un core est power gate, donc qu'il soit enorme et inefficace ou petit et super efficace, il n'y a qu'une seule difference: la qualite de la power gate qui est autour. Ca leake toujours un peu une power gate, mais ca ne sera certainement pas une difference de decodeurs qui changeral le power d'un core au repos...

Tout ce qui n'a pas ete eteint correctement oui, par contre...

[Alexko]

Au repos, un core est power gate, donc qu'il soit enorme et inefficace ou petit et super efficace, il n'y a qu'une seule difference: la qualite de la power gate qui est autour. Ca leake toujours un peu une power gate, mais ca ne sera certainement pas une difference de decodeurs qui changeral le power d'un core au repos...

Tout ce qui n'a pas ete eteint correctement oui, par contre...

Mais en pratique, le "repos" pendant la navigation web par exemple, est fréquemment interrompu par des phases de charge faible, non ? Le scrolling, les pubs en Flash, les images qui mettent trois plombes à se charger, les applications en tâche de fond…

Concrètement, les cores sont-ils vraiment power gatés souvent en utilisation bureautique ? Rien que faire clignoter le curseur dans un éditeur de texte… Enfin je suis peut-être à l'ouest sur l'ordre de grandeur des latences pour le power gating.