Des Mac ARM en perspective, Réactions à la publication du 09/05/2011

[iAPX]

Si tu veux...

Mais qu'est ce qui qualitife pour toi une CPU pour être RISC ou pas?
Y a t'il une caractéristique ou plusieurs qui puisse faire dire que c'est RISC ou CISC?
Parceque de l'avis de pas mal de monde, ce mot est uniquement commercial depuis une bonne dizaine d'année, ne recouvrant plus aucun concept réel...

[xpech]

Si tu veux...

Mais qu'est ce qui qualitife pour toi une CPU pour être RISC ou pas?
Y a t'il une caractéristique ou plusieurs qui puisse faire dire que c'est RISC ou CISC?
Parceque de l'avis de pas mal de monde, ce mot est uniquement commercial depuis une bonne dizaine d'année, ne recouvrant plus aucun concept réel...

Même sur le PPC 970 (G5) le core utilise un jeu d'instruction réduit par rapport au PowerPC avec une étape de décodage.

[Maconnect]

Si tu veux...

Mais qu'est ce qui qualitife pour toi une CPU pour être RISC ou pas?
Y a t'il une caractéristique ou plusieurs qui puisse faire dire que c'est RISC ou CISC?
Parceque de l'avis de pas mal de monde, ce mot est uniquement commercial depuis une bonne dizaine d'année, ne recouvrant plus aucun concept réel...

Il me semble que le RISC a une taille d'instruction constante, alors qu'elle est variable pour le CISC (c'est le cas quand en fait de l'assembleur). Ce qui implique de faire je ne sais trop quoi en CISC pour pouvoir mettre les instructions dans les pipelines. Ça aide pas trop mais c'est déjà une piste ^^

Ce message a été modifié par Maconnect - 10 May 2011, 20:30.

[iAPX]

@Maconnect Non ça n'est pas valable pour la plupart les processeurs affublés du qualificatif de "RISC"

Et c'est évidemment infaisable, et une perte incroyable d'espace mémoire et d'espacxe de cache code-L1 (architectures Harvard) ainsi que de bande-passante pour l'interprétation des instructions:
Pour une instruction qui permette de charger une constante 64bits dans un registre, codée au minimum en 72bits (9 octets), il faudrait que toutes les instructions soient codées en 72bits aussi, ça serait donc des instructions plus longues en moyenne qu'avec le "mauvais" jeu d'instruction x86-64...

@xpech tu veux expliquer que l'architecture Power d'IBM n'est aps "RISC" mais le PowerPC G5 l'est ?!? Va être dur ça!

[SartMatt]

C'est le codeop qui est généralement de taille fixe sur les RISC, pas le coupe codeop + opérandes, qui est bien entendu toujours variable, ne serait ce que parce que les instructions ne prennent pas toutes le même nombre d'opérandes...

Ce message a été modifié par SartMatt - 10 May 2011, 21:54.

[Pom2Ter]

@Maconnect Non ça n'est pas valable pour la plupart les processeurs affublés du qualificatif de "RISC"

Et c'est évidemment infaisable, et une perte incroyable d'espace mémoire et d'espacxe de cache code-L1 (architectures Harvard) ainsi que de bande-passante pour l'interprétation des instructions:
Pour une instruction qui permette de charger une constante 64bits dans un registre, codée au minimum en 72bits (9 octets), il faudrait que toutes les instructions soient codées en 72bits aussi, ça serait donc des instructions plus longues en moyenne qu'avec le "mauvais" jeu d'instruction x86-64...

@xpech tu veux expliquer que l'architecture Power d'IBM n'est aps "RISC" mais le PowerPC G5 l'est ?!? Va être dur ça!

Surtout que grosso modo le PPC 970 c'est une version légèrement modifiée du Power 4 avec des pipelines d'executions plus long et des petites différences.

[omega2]

On peut toujours rêver mais si cela était réel Lionel, cela sentirait le brûlé chez la pomme.

On parle de la pomme, ça ne sentira le brulé que pendant quelques jours ou semaines et après on sera tous écœuré de la bonne odeur émanant d'une pomme parfaitement caramélisé. C'est ça la magie Apple (alias champ de distorsion SJ ?)

Si même une version préliminaire de Windows 8 a été présenté en version ARM c'est que c'est bel et bien une tendance que MS et Apple comme d'autres veulent suivre ...

En même temps, ça fait tellement longtemps que windows ne se borne pas à l'x86 que la seule conclusion à en tirer, c'est que Microsoft continue de garder ouverte des portes vers d'autres possibilité. En fait, il a juste changé de porte.
Pour Apple : 68000 => PPC => PPC & x86 => x86 (ou bien PPC & x86 & ARM, je vous laisse choisir) => x86 & ARM (et oui, les iDevices) . Je ne sais pas si changer une fois de plus d'architecture démontre un mouvement de fond ou la supériorité d'une architecture face à une autre ou bien rien d'autre qu'une meilleure correspondance avec ce qu'Apple considère comme le plus rentable pour eux sur le moyen terme.

[iAPX]

C'est le codeop qui est généralement de taille fixe sur les RISC, pas le coupe codeop + opérandes, qui est bien entendu toujours variable, ne serait ce que parce que les instructions ne prennent pas toutes le même nombre d'opérandes...

Pas vrai pour tous, le opcode peut -aussi- être variable, notamment avec l'ajout successifs d'instructions que les architecture à usage générales ont du supporter au fur et a mesure

C'est une propriété souhaitable, mais elle n'est ni suffisante ni nécessaire. En fait tout ça c'est du discours marketing, surtout que les architectures "RISC" ont souvent recours à la même astuce qu'Intel passé un certain stade: avoir un décodeur qui rempli le pipeline d'instructions "natives", les CPU n'exécutant pas nativement le jeu d'instruction qu'elles supportent, mais l'émulant grace à un jeu d'instruction différent, et de type VLIW!

Seules les architectures peu efficaces en nombre d'instruction par cycle (ARM par exemple, anciens x86, 68xxx, etc) pouvaient fonctionner en interprétant directement le jeu d'instruction cible!

Ce message a été modifié par iAPX - 10 May 2011, 22:21.

[xpech]

@xpech tu veux expliquer que l'architecture Power d'IBM n'est aps "RISC" mais le PowerPC G5 l'est ?!? Va être dur ça!

Surtout que grosso modo le PPC 970 c'est une version légèrement modifiée du Power 4 avec des pipelines d'executions plus long et des petites différences.

je l'avais pas vue comme ça mais effectivement ...

C'était pour illustrer la confusion cisc/risc, avec des processeur qui utilisent un jeu d'instruction interne avec un étape de décodage. Même les PowerPC font ça. Donc effectivement le coeur d'un G5 et RRISC :-)

Ce n'était pas le cas d'un G3 ou d'un G4, qui eux implémentaient totalement le jeux d'instruction PPC.

[Maconnect]

C'est le codeop qui est généralement de taille fixe sur les RISC, pas le coupe codeop + opérandes, qui est bien entendu toujours variable, ne serait ce que parce que les instructions ne prennent pas toutes le même nombre d'opérandes...

beuh comment ça ? Quand j'analyse du code PPC, toutes les opérations ont la même taille avec l'adresse de destination/source comprise. Si t'as pas la place pour mettre ton adresse, alors tu la mets dans un autre registre et tu appelles une instruction différente. Chaque ligne d'assembleur fait exactement 32bits. J'ai peut-être mal compris, question de vocabulaire...

[SartMatt]

C'est le codeop qui est généralement de taille fixe sur les RISC, pas le coupe codeop + opérandes, qui est bien entendu toujours variable, ne serait ce que parce que les instructions ne prennent pas toutes le même nombre d'opérandes...

beuh comment ça ? Quand j'analyse du code PPC, toutes les opérations ont la même taille avec l'adresse de destination/source comprise. Si t'as pas la place pour mettre ton adresse, alors tu la mets dans un autre registre et tu appelles une instruction différente. Chaque ligne d'assembleur fait exactement 32bits. J'ai peut-être mal compris, question de vocabulaire...

Effectivement, je me suis trompé. Mon assembleur est un peu rouillé et j'ai surtout fait du IA-64 et du 68k, je savais pas que sur les PPC et ARM on peut pas passer des valeurs immédiates en 32 bits.

[iAPX]

Alors taille toujours fixe ou variable? lol!
Ça n'est pas du RISC tout ça, pas propre a du RISC, vous allez le retrouver (les deux cas) dans du RISC et du CISC.

En plus le plus drole c'est que nos cpu "RISC" sont en fait des VLIW

[Maconnect]

Ben je sais pas. Le mieux que j'aie trouvé, chez wikipedia:

The term "reduced" in that phrase was intended to describe the fact that the amount of work any single instruction accomplishes is reduced – at most a single data memory cycle – compared to the "complex instructions" of CISC CPUs that may require dozens of data memory cycles in order to execute a single instruction.[8] In particular, RISC processors typically have separate instructions for I/O and data processing; as a consequence, industry observers have started using the terms "register-register" or "load-store" to describe RISC processors.

[SartMatt]

En plus le plus drole c'est que nos cpu "RISC" sont en fait des VLIW

Euh non. VLIW c'est les processeurs Itanium par exemple, qui travaillent avec des instructions de 3km de long ^^
Des instructions sur 32 bits, on peut vraiment pas appeler ça du VLIW...
L'Itanium par exemple, il travaille sur des "instructions" de 128 bits (3 instructions de 41 bits + 5 bits qui servent à indiquer les unités de calcul utilisées par les instructions, et à indiquer s'il y a des dépendences, pour que le cœur puisse déterminer si il peut ou non traiter les trois en même temps).

[Pom2Ter]

@xpech tu veux expliquer que l'architecture Power d'IBM n'est aps "RISC" mais le PowerPC G5 l'est ?!? Va être dur ça!

Surtout que grosso modo le PPC 970 c'est une version légèrement modifiée du Power 4 avec des pipelines d'executions plus long et des petites différences.

je l'avais pas vue comme ça mais effectivement ...

C'était pour illustrer la confusion cisc/risc, avec des processeur qui utilisent un jeu d'instruction interne avec un étape de décodage. Même les PowerPC font ça. Donc effectivement le coeur d'un G5 et RRISC :-)

Ce n'était pas le cas d'un G3 ou d'un G4, qui eux implémentaient totalement le jeux d'instruction PPC.

Je suis pas certain d'avoir compris ce que tu compares entre les G3/G4 et le G5, tu peux développer?
J'ai travaillé chez IBM entre 2005 et 2008 sur des System P / Power Systems et l'architecture Power me fascine énormément.
Le PPC 970 supporte nativement le jeu d'instructions PowerPC en 32 et 64 bit, je vois pas le rapprochement entre le G3/G4 et le G5.
Je suis pas le plus calé mais j'ai posé un max de questions aux ingénieurs / programmeurs avec qui je travaillais et j'arrive vraiment pas à comprendre ce que tu as essayé de dire.

Ce message a été modifié par Pom2Ter - 11 May 2011, 19:32.

[xpech]

Je suis pas certain d'avoir compris ce que tu compares entre les G3/G4 et le G5, tu peux développer?
J'ai travaillé chez IBM entre 2005 et 2008 sur des System P / Power Systems et l'architecture Power me fascine énormément.
Le PPC 970 supporte nativement le jeu d'instructions PowerPC en 32 et 64 bit, je vois pas le rapprochement entre le G3/G4 et le G5.
Je suis pas le plus calé mais j'ai posé un max de questions aux ingénieurs / programmeurs avec qui je travaillais et j'arrive vraiment pas à comprendre ce que tu as essayé de dire.

Apparemment les Power4 sont aussi comme ça (logique vue la parenté avec le 970). Les instructions PPC sont en partie traduites en iOPS qui sont ensuite traitées.
On a bien un jeu d'instruction interne plus ou moins proche du jeu exposé, comme pour les X86 modernes.

Maintenant c'est ce qui est décrit dans pas mal de doc, peut-être ai-je mal compris.

Pages 5 :
http://web.cecs.pdx.edu/~alaa/courses/ece5...otes/power4.pdf

Para. 4 :
http://ixbtlabs.com/articles/ibmpower4/


http://books.google.com/books?id=Q1zSIarI8...ops&f=false

iops are internal instructions mostly 1-1 for RISC operations but some instructions have more than one iop, like lmw or load/store with update.

http://www.cse.unsw.edu.au/~cs9244/06/seminars/10-gvdl-t.pdf

[iAPX]

En plus le plus drole c'est que nos cpu "RISC" sont en fait des VLIW

Euh non. VLIW c'est les processeurs Itanium par exemple, qui travaillent avec des instructions de 3km de long ^^
Des instructions sur 32 bits, on peut vraiment pas appeler ça du VLIW...
L'Itanium par exemple, il travaille sur des "instructions" de 128 bits (3 instructions de 41 bits + 5 bits qui servent à indiquer les unités de calcul utilisées par les instructions, et à indiquer s'il y a des dépendences, pour que le cœur puisse déterminer si il peut ou non traiter les trois en même temps).

En interne, les Core2 Duo et autres Core Ix créent des instructions VLIW (différentes pour chaque architecture et leurs compte d'unité spécialisées ou semi-spécialisées genre "load/store" ou autres), qu'ils stockent dans un cache d'accélération de boucles (de taille variable entre Core2 Duo et Core iX un peu plus grand), et techniquement ce sont les instructions VLIW qui sont exécutées, après traduction depuis le jeu d'instruction x86 et autres opération comme la macro-fusion et la génération d'instruction intermédiaires pour les instructions complexes.

Au sein d'une boucle courte, l'unité de décodage x86 n'est d'ailleurs pas utilisé sur ces CPU, mais uniquement le cache d'instruction VLIW. Il me semble que les Core iX en pack 5 ou 6 par cycle au maximum (je peux vérifier si ça te dis), obtenant en moyenne un débit de plus de 3 instructions par cycle qui rentrent et sortent du pipe.

Le premier a adopter ce modèle fut le Pentium IV chez Intel, dissociant complètement la traduction de l'exécution, plus encore que les dernières générationspuisque le décodeur alimentait un cache d'instructions larges qui servait génériquement. Un défaut état la bande-passant demandé depuis ce "gros" cache (comparé aux Core2 et sucesseurs limités probablement à moins de 500 octets internes), d'où des limitations dans les boucles courtes où la CPU ne pouvait pas débiter au maximum ,et donc le remplacement par un modèle avec un micro-cache limité mais capabale dans 90% des cas d'alimenter la CPU à 100% de ses ressources de calcul.

Et le plus fun c'est que toutes les architectures modernes de processeurs très performants par core sont peu ou prou basés sur le modèle VLIW interne, avec un décodeur d'instruction séparé, afin de permettre d'avoir un modèle d'exécution et de parallélisation des instructions qui soit le moins dépendant possible du jeu d'instruction qu'ils émulent (oui il s'agit d'émulation dans le sens ou une instruction n'est pas interprété et exécuté, mais bien traduite dans un autre jeu d'instruction en intermédiaire, très similaire à de que fait un compilateur JIT en plus simple).

J'étais un fan du i860 premier 64bits d'Intel, et CPU VLIW et de la possibilité de confier au compilateur la tâche d'optimiser un logiciel pour la machine-cible. Las il sera tombé dans l'oubli alors que maintenant grâce à LLVM on dispose d'outils permettant de réaliser ce rêve d'avoir des logiciels optimisés sur n'importe quelle plateforme et s'adaptant à l'arrivée de nouvelles architectures de CPU... Je n'avais pas saisi à l'époque le problème que cela posait en terme de bande-passante de cache L1-code (dans une architecture Harvard), de gachis de place dans ce cache très couteux, et de l'occupation mémoire qui allait avec.

La traduction de jeu d'instructions bien plus compacts (comme le x86, ça vaut aussi pour celui du PowerPC ou ce que vous voudrez) permet de limiter l'occupation mémoire, de limiter l'occupation du cache de code L1, ainsi que des cahces L2 et L3, en gardant l'efficacité du VLIW sur les boucles courtes grace au micro-cache spécifique du Core2 et Core iX (différent du cache L1-code!) et permettant un gros ré-ordonnancement des instructions. AMD fait d'ailleurs peu ou prou la même chose (l'implémentation est différente, la notion de traduction et VLIW aussi présente)

Ce message a été modifié par iAPX - 11 May 2011, 23:50.

[zero]

Intel avance aussi vite qu'ARM?? Pourtant en 5 ans (depuis le core duo) il n'y a eu que l'architecture "core i". Les core i à fréquence équivalentes sont _bien_ plus performant que les core 2 uniquement pour certains usages spécifiques en utilisant des instructions spécialisées.
Pas sûr qu'il y ait un gain aussi significatif pour des taches de calcul brute (de type ray tracing par exemple).

Si on regarde du côté d'ARM, entre le premier processeur de l'iPhone et l'A5 la puissance à du être quadruplée. Sans compter la partie graphique qui a était multipliée par 20. Tout ça en gardant une très faible consommation.

Si INTEL avait vraiment progressé, ses processeurs ATOM ne se ferait pas c'est le cas de le dire, atomiser par des ARMs.

Les RISC ont toujours été très supérieurs aux CISC, mais mis de côté par le monopole d'INTEL. Aujourd'hui ça change car INTEL ne se doutait pas de la révolution mobile qui s'est produite.

Exacte ! Sauf que je pense que INTEL a bien vu la révolution mobile mais le CISC a ses limites. INTEL a du faire ce qu'elle a pu et continuera tant que possible quitte a prendre des risques avec de nouvelles techno de gravure.

Ce message a été modifié par zero - 12 May 2011, 01:17.

[dandu]

iAPX et d'autres t'expliquent que RISC et CISC, c'est obsolète comme termes.

Techniquement, le seul truc " CISC " qui reste chez Intel, c'est le jeu d'instruction lui-même, et il est traduit en interne, pas exécuté tel quel comme il y a 25 ans.

Pour la consommation, c'est plus une question de puissance attendue : un Atom a une fréquence de CPU ARM, sans l'HyperThreading, ça consomme à peine plus qu'un ARM. Et faut bien se dire que c'est le bas de gamme d'Intel, fait avec de vieux process. Le problème vient plus des OS : personne veut une machine desktop/netbook avec un Atom à 1 GHz, ça reste lent. Mais personne veut non plus des netbooks avec un ARM, pour la même raison.

Avec Sandy Bridge, Intel arrive a des niveaux de consommation en idée très faible, plus faible que les Atoms. Le problème, c'est que la consommation explose dès qu'on fait un truc qui a besoin de performances. Et c'est déjà en partie le cas sur ARM, et l'augmentation des performances va induire le même problème.

[Cappuccino]

Et c'est déjà en partie le cas sur ARM, et l'augmentation des performances va induire le même problème.

C'est pas faux. Le vrai problème c'est l'OS, Mac OS X ou Windows 7 sont devenus des monstres obèses qui demandent 4 Go de RAM et un processeur 2 Ghz pour faire des choses basiques alors qu'un iPad sous ARM et iOS peut faire du GarageBand avec peu de RAM et un processeur basse conso.
Je pense que l'avenir est à ARM et des OS légers pour le grand public.

[xpech]

Et c'est déjà en partie le cas sur ARM, et l'augmentation des performances va induire le même problème.

C'est pas faux. Le vrai problème c'est l'OS, Mac OS X ou Windows 7 sont devenus des monstres obèses qui demandent 4 Go de RAM et un processeur 2 Ghz pour faire des choses basiques alors qu'un iPad sous ARM et iOS peut faire du GarageBand avec peu de RAM et un processeur basse conso.
Je pense que l'avenir est à ARM et des OS légers pour le grand public.

J'ai fait la somme rapide des process système et j'arrive à 735Mo dont 230Mo du server graphique (cache ..). Donc non, c'est pas vraiment les OS (en tout cas 10.6) qui ont besoin de quantité de RAM mirobolante.
Par contre, une pauvre page Web, consomme rapidement 50/100Mo. On en ouvre une 10zaine entre les navigateur, l'aide ... et là ça commence à faire.
ll ya quelques années j'avais fait une analyse rapide d'occupation d'un DOM en RAM d'une page WEB, et j'avais tiré une règle de 60 (html de 1Mo -> 60Mo de ram).

Ce sont principalement les besoins de chacun qui tirent la conso de RAM et de CPU. (ce week end j'ai traité +200 photo de 18Mpx, avec correction colorimétrique, yeux rouges ...)