[Discussion] La technique et les smartphones/tablettes (ex-topic Cortex A15)

[HoM3r17]

ARM n'as pas de licence x86 ... ou alors je ne suis pas au courant ... Pour les possesseurs de cette Licence a part Intel, AMD (grace a Global Foundries) IBM (qui ne produit plus de processeurs X86) et VIA (meme chose qu'IBM il me semble) je ne voit pas d'autres acteurs

Modifié 6 mars 2013 par HoM3r

[Alex98]

Les jeux d'instructions qui composent le X86 appartiennent à Intel. Comme ARM avec Qualcomm et Apple, ils vendent des licences architectures qui permettent à AMD de créer leurs propres architectures utilisant les jeux d'instructions d'Intel.

ARM pourrait bien entendu acquérir une licence de ce type et développer des cores X86 mais à ce jeu là, Intel sera toujours le meilleur car il dispose de leurs propres fabriques et d'un budget bien plus important.

Après, pour les A15, il faut tout de même bien comprendre que le TDP ne nous indique rien sur la consommation en usage "normal".

Si on prend 2 CPU A et B avec A qui consomme 2 fois plus mais esy 3 fois plus rapide alors pour une même tâche à effectué, le A sera le plus économe.

L'important en usage normal c'est la notion de perfs/watt

[Infernus]

Ca va de soi, une TDP n'indique pas que tu vas dégager tout le temps autant de chaleur, mais c'est un indicateur.

Mais je trouve les architectures hybride big.LITTLE très intéressante car cela permet de bénéficier du meilleur des 2 mondes, au prix d'une complexité structurelle plus importante.

Comme dit on à rien sans rien.

D'ailleurs je me pose une question, pourquoi Nvidia a choisi des A9r4 pour son Tegra 4i à la place des A7.

Les A9 permettent de monter plus haut en fréquence ? meilleur bus ? etc... (j'ai pas regardé)

Modifié 6 mars 2013 par Infernus

[Alex98]

Les A7 ne peuvent pas aller au-delà de 1.2Ghz. Après ce point ils perdent rapidement en perfs/Mhz. En fait cette architecture est vraiment optimisé pour un pique de performances qui correspond au gros des usages d'un mobile.

Parlant d'ARM et du big.LITTLE, avec la concurrence d'Intel et d'AMD, je pense que l'avenir d'ARM sera fortement lié à celui de cette technologie.

Ils n'ont pas, à mon sens, les moyens financiers et logistique de lutter contre les autres acteurs du marché. Jusque là ils avaient surtout piquer des idées chez Intel/AMD.

[Infernus]

Déjà que je m'inquiète de l'avenir d'AMD... si en plus Intel viens écraser ARM...

On se retrouvera avec uniquement du x86 de partout.

Sinon, il me semble qu'au niveau de leurs APU, AMD est plutôt parmis les bon élèves en terme de perfs GPU.

Sur ce point ils ont encore de l'avance sur Intel.

[Alex98]

Le problème d'AMD est le meme que celui qui va se poser pour ARM : comment faire pour produire des architectures capables de conccurrencer Intel sans avoir des process de gravure équivalents ?

Avec le FD-SOI, peut-être que la concurrence a une chance.

[Infernus]

Ce serait bien, parce que si on se retrouve avec un monopôle global de Intel...

[lolobarjo]

Perso c'est pas pour me déplaire d'avoir un appareil sous intel, si seulement c'était supporter par CyanogenMod ou que ça serait dans un Nexus

Je sais pas si la question a déjà été poser mais c'est quoi le mieux ? x86 ou ce que fait ARM pour les mobiles ?

[HoM3r17]

Perso c'est pas pour me déplaire d'avoir un appareil sous intel, si seulement c'était supporter par CyanogenMod ou que ça serait dans un Nexus

Je sais pas si la question a déjà été poser mais c'est quoi le mieux ? x86 ou ce que fait ARM pour les mobiles ?

Déja qu'intel abuse sur sa politique tarifaire avec le peu de concurrence que lui fait AMD sur les PC, alors si ils n'ont plus personne pour les freiner les prix vont flamber ... sur un marché c'est toujours mieux d'avoir le choix, crois moi ... je suis passé chez Intel aussi sur mon PC parce que ca correspond mieux a mes besoins a l'heure actuelle, mais pour le principe je continue a acheter régulierement du matos AMD quand il font quelque chose de bien (leurs GPU sont très bons, que ca soit sur une carte dédiée ou sous forme d'"APU" comme ils aiment a les appeler, d'ailleurs c'est la dessus qu'intel est a la traine, le chipset Intel HD 4000 que l'on trouve dans les derniers I7 a 300€ est moins performant que les Radeon HD 7540D présents dans un AMD A6 de dernière génération que l'on trouve a 60€ sur le net ...)

[lolobarjo]

Déja qu'intel abuse sur sa politique tarifaire avec le peu de concurrence que lui fait AMD sur les PC, alors si ils n'ont plus personne pour les freiner les prix vont flamber ... sur un marché c'est toujours mieux d'avoir le choix, crois moi ... je suis passé chez Intel aussi sur mon PC parce que ca correspond mieux a mes besoins a l'heure actuelle, mais pour le principe je continue a acheter régulierement du matos AMD quand il font quelque chose de bien (leurs GPU sont très bons, que ca soit sur une carte dédiée ou sous forme d'"APU" comme ils aiment a les appeler, d'ailleurs c'est la dessus qu'intel est a la traine, le chipset Intel HD 4000 que l'on trouve dans les derniers I7 a 300€ est moins performant que les Radeon HD 7540D présents dans un AMD A6 de dernière génération que l'on trouve a 60€ sur le net ...)

C'est clair qu'avoir le choix est essentiel. Ne plus avoir de choix serait quelque chose d'horrible et sa donnerait au constructeur le monopole ce qui est catastrophique.

Je disais juste mon avis sur le fait d'avoir un mobile sous Intel qui puisse être supporter par l'aosp. Que quand je le razr i je suis toujours impressionner par la fluidité du système et l'autonomie (mais après sa vient peut être pas du CPU finalement).

Sur PC je préfère éviter de donner mon avis pour le moment vu que je suis en train d'essayer d'approfondir mes connaissance dans ce domaine.

Envoyé avec mon SGS2 Citizy accro à CM10.1 -> Tapatalk

[Alex98]

Je crois qu'on aimerait tous avoir une une réponse à cette question lol.

Ce qui est sûr c'est que les jeux d'instructions des X86 sont bien meilleurs et prennent en compre bien plus de choses que l'ARMv7 (actuellement utilisé par tous les designs ARM).

Le problème c'est que les architectures qui permettent de gérer ces jeux d'instructions sont au final bien plus complexes que les designs d'ARM, ce qui signifie que la consommation est aussi bien plus élevés.

Pour arriver à un niveau de consommation raisonnable sur mobile, Intel a dû sacrifier de nombreuses extensions. C'est là toute la difficulté de transformer une architecture haute performance en une architecture basse consommation.

ARM de son côté est partie d'une feuille blanche et en a sortie une véritable architecture basse consommation. Adapté à la cible en question. Sauf que depuis ils ont du augmenter les performances de leurs architectures et pour se faire ils ont repris les idées d'Intel.

Le problème pour ARM c'est qu'ils sont arrivés à un point (les A15) où pour augmenter les performances de leur architecture ils ont dû sacrifier sa consommation.

Dans le même temps, Intel semble lui faire preuve d'aisance quand il s'agit de diminuer la consommation de ses Atoms sans en sacrifier les les performances.

A ce stade, les performances d'architectures semblent très nettement à l'avantage d'Intel tandis que l'avantage d'ARM sur la consommation semble fondre aussi vite qu'un bout de beurre en plein milieu du Sahara (c'est dire). Les Clover Trail+ seront un bon test pour juger de la situation.

ARM a toutefois encore une carte dans sa manche. Si le big.LITTLE est un succès alors ils seront capables de produire des architectures qui pourront à la fois descendre très bas en termes de consommation et monter très haut en termes de performances. Chose qu'Intel ne peut pas faire actuellement avec ses X86.

L'autre atout d'ARM c'est l'ARMv8. Leur futur jeu d'instructions pour architectures 64bits. Bien conçu, ils pourront peut-être égaler Intel sur les architectures monocores (ce dont ARM est actuellement incapable) pour mobiles et même les attaquer sur d'autres marchés.

Par contre, du côté d'Intel, difficile de voir ce qui pourrait les arrêter. Jusque Là ils ont fait preuve de manque d'ambition (peu de partenariats, GPU moyens, gravure 40nm, ...) et surtout de prix exorbitant (60 $ l'Atom. Le double des architectures ARM les plus haut de gamme) mais je ne pense pas que l'état de grâce dure éternellement pour ARM.

Après je suis à 300% d'accord avec HoM3r. Un monopole d'Intel serait l'une des pires choses possibles.

[Infernus]

Pour compléter ce qu'Alex98 dit.

Il faut savoir qu'a l'"origine", les architectures ARM étaient de type RISC (Reduced Instruction Set Computing) contre CISC (Complex Instruction Set Computing).

Ces dénominations montre bien les choix antagonistes qui avaient été fait.

Sauf que pour réussir à remonter en performance arm s'est complexifié.

[lolobarjo]

C'est quoi 'RISC' et 'CISC ?

L'ARMv8 apportera quoi de plus ? C'est comme les A15 ?

[Infernus]

Risc = jeu d'instructions réduits, le processeur peut exécuter moins d'instructions en dur, mais il est de fait plus simple à construire, moins cher, consomme moins.

Cisc = l'inverse.

Ne pas confondre A15 et armv8.

A15 est un type de coeur, crée par ARM. Il implémente le jeu d'instruction armv7, c'est à dire qu'il est capable d'exécuter par des portes logiques les instructions spécifiées dans armv7.

ArmvX correspond à un jeu d'instructions.

Pour les spécificités d'armv8, je laisse la place à Alex qui te répondra bien plus précisément que moi, d'ailleurs ça m'intéresse aussi.

[Alex98]

RISC et CISC sont des types d'architectures circuits.

Le RISC consiste à n'utiliser qu'un jeu d'instructions réduit avec uniquement des instructions simples et faciles à décoder. Le CISC par contre consiste à utiliser un jeu d'instructions bien plus vastes et souvent beaucoup plus compliquées à décoder.

Pour les ARMv8 on a pas encore grand chose si ce n'est qu'ils passeront aux 64bits et (en extension ?) des unités de crypto.

Edit : en gros avec l'ARMv8, ARM se rapproche de ce que fait Intel

Modifié 7 mars 2013 par Alex98

[Lannig]

Sauf que la frontière entre CISC et RISC, aujourd'hui, hein, ça devient assez subtil.

Les vrais RISC purs et durs, avec 20 instructions et 3 modes d'adressage (oui je sais j'exagère) ça a disparu.

Un des derniers c'était l'Alpha de Digital (successeur du VAX... bon je cause aux > 35 ans là :P ). Ils ont réalisé à quel point c'était une galère d'écrire des compilateurs qui génèrent du bon code sur ces CPUs. Ca devenait de vraies usines à gaz.

[Infernus]

Bien pour ça que je précise à l'origine ;)

[lolobarjo]

Mais en ce raprochant de ce que fait intel, leur architecture vont pas voir leur consommation augmenter ? Et comme l'ARMv8 est un jeu d'instruction, c'est possible que des A9 sorte en v8 tout comme des A7/15 ?

[Alex98]

Ça devait être marrant de coder en assembleur avec 20 instructions.

[Infernus]

Si, justement c'est bien pour ça que la consommation à tendance à augmenter, même si l'effet est compensé en partie par l'augmentation de la finesse de gravure.

Refaire des coeurs avec un nouveau jeu d'instructions oblige à modifier la structure. Rajouter des circuits. Donc tu pourras toujours l'appeler A7 si tu veux. Mais ça n'aurait plus grand chose à voir avec l'origine

Edit : C'est déjà pas ce que l'on pourrait appeler marrant de coder en asm x)

Modifié 7 mars 2013 par Infernus

[Alex98]

Et c'est la raison pour laquelle les A5x sont prévu pour du 20nm et que la devboard devrait même être en 16nm

[Lannig]

Ah si moi j'adore... coder en assembleur sur le VAX c'était un régal. Un jeu d'instructions superbe, carré, facile à apprendre.

Même le x86, bah, même si je n'ai plus codé d'assembleur depuis le 386, c'est quand même plutot plaisant.

Et avant y'avait le 8080 (la je cause aux > 40 ans ce coup-ci !), beau jeu d'instructions (le x86 en est une version abatardie).

Par contre les RISC, dur. J'ai essayé sur SPARC (Sun) je n'y arrivais pas.

Modifié 7 mars 2013 par Lannig

[Alex98]

@ Infernus

Tu es vraiment de mauvaise foi. Coder en assembleur c'est aussi amusant que de construire une muraille de chine avec des cailloux... ça prend autant de temps d'ailleurs

[Lannig]

Pfff ça dépend ce qu'on code bien sûr. Si c'est un clone de Word ça ne fait aucun sens. Mais z'avez jamais codé un driver ? ça c'est fun et quand même plus facile en assembleur (oui je sais y'en a plein en C).

[Alex98]

Je ne code que par "amusement" donc ma vision de l'assembleur ressemble à "c'est tellement plus rapide en C".

Même si j'admets que le résultat en assembleur est tellement plus satisfaisant qu'en C.