Les CPU des Mac : Intel 80860, Réactions à la publication du 10/01/2024

[Paul Emploi]

En 1990, pendant qu'Apple explorait les différentes options permettant de sortir de la famille "CISC" Motorola 68k la tête haute en préservant l'avenir du Macintosh, et de la même manière que Motorola explorait les CPU "RISC" avec sa nouvelle famille 88k, Intel avait fait un choix plus original avec le 80860 VLIW.

Et Apple l'a essayé, parmi d'autres idées assez farfelues comme le Scorpius du projet Aquarius, pour en faire la CPU principale de potentiels Macintosh.

80860 ou i860, on comprend dès le nommage que cette nouvelle famille Intel avait été conçue pour remplacer les x86, ce qui évidemment n'arriva pas.

i860 "64 bits"

Intel présenta le i860 comme 64 bits, mais il était en fait une CPU 32 bits avec un bus de données 64 bits ainsi que des capacités vectorielles qu'on retrouvera plus tard dans le MMX du Pentium.
Le bus de données 64 bits était indispensable au vu de ses performances théoriques, atteignables dans certains rares cas d'usage.

Pour le reste, on retrouvera un cache d'instruction de 4Ko et un cache de données de 8Ko avec un bus interne carrément 128 bits destiné à accélérer les traitements vectoriels, une unité de calcul entier, une unité de calcul flottant capable de réaliser une multiplication et une addition en parallèle ainsi qu'une unité graphique dédiée à la manipulation d'images.
Et un beau volume de registres, avec 32 registres entiers 32 bits auxquels s'ajoutent 32 registres flottants 32 bits aussi utilisables comme 16 registres 64 bits ou 8 registres 128 bits.

VLIW: exécution parallèle "dual-instruction"

On a abordé le "CISC" et le "RISC" au cours de cette série, mais VLIW quésaco?!?

Le plus intéressant est le mode dual-instructions où deux d'entre elles sont empaquetées dans un mot 32 bits, permettant d'utiliser à la fois l'unité "core" entière et soit l'unité flottante ou l'unité "graphique" à la fois, l'unité flottante pouvant exécuter une multiplication et une addition en parallèle, permettant alors d'exécuter 3 instructions à la fois!

De là vient le nom VLIW, car les deux micro-instructions sont empaquetées dans un mot 32 bits, ce qui pour l'époque était assez énorme si on compare cela avec les x86 32 bits où beaucoup d'instructions sont 8 bits.
Un immense progrès théorique: jusqu'à 3 opérations lancées par cycle via 2 instructions!

Plus de détails dans le manuel de référence du i860, mais en Anglais.

Optimisations par le compilateur et le développeur

Le premier problème c'est que le compilateur doit optimiser le code pour regrouper des instructions entre elle de manière efficace, et au début c'était très loin d'être parfait pour le i860.
On termine donc avec de l'optimisation à la main du code, on retrouvera cela chez NeXT par exemple avec ses routines graphiques, pour essayer de s'approcher des performances théoriques promises par Intel.

On peut y rajouter les "delayed branch", où l'instruction de branchement se trouve avant une ou plusieurs instructions qui sont quand-même exécutées dans tous les cas, des fois même au début de la boucle, et où il est quasi-impossible d'appeler une routine entre celle-ci et le saut effectif

Totalement ingérable pour les compilateurs de l'époque: la génération de code dépends du code suivant et non uniquement précédent. Un casse-tête pour les Dev en assembleur.

Performances théoriques et réelles

Les performances théoriques du i860 étaient incroyablement prometteuses, mais dans la pratique les compilateurs étaient incapable de délivrer plus qu'une fraction de ces performances car non-conçus pour ce type d'architecture, un problème qui ne se résoudra pas vraiment et qui affectera aussi l'Itanium 64 bits des années plus tard!

Même optimisé à la main, le code sera loin de tourner aussi vite que promis, et seules certaines routines spécifiques dont des routines graphiques, permettront d'exploiter son potentiel, mais en aucun cas des logiciels généralistes.

Non seulement le i860 est plus lent du coté CPU que ses concurrents RISC ou CISC mais aussi plus complexe à programmer!

Unité graphique

Outre le fonctionnement VLIW avec deux micro-instructions empaquetées et lancées par cycle, le i860 contient une unité graphique orientée vers la génération d'image 2D, avec des capacités 3D limitées par rapport à ce que l'on connait depuis 25 ans.

Cette unité est probablement sa plus grande force, permettant de gérer des rendus en monochrome, 256 couleurs et plus encore 16 millions de couleurs, avec des performances inégalées et surtout entièrement programmable.

Apple

Apple a créé un prototype, probablement comme pour d'autres sur la base des performances théoriques mais aussi des capacités de gestion de mémoire graphique de cette CPU, permettant d'avoir des rendus de qualité en 16 millions de couleur sans trop de ralentissements, promettant de pouvoir créer une station de travail graphique avec une superbe intégration.

Très certainement Apple s'est heurté aux limites de l'exercice, c'est à dire des performances pratiques moyennes voire inférieures en tant que CPU même si bien meilleures en terme de rendus graphiques sur du code optimisé à la main et invariant.

NeXTDimension pour NeXTCube

Next a aussi utilisé l'Intel i860, mais pour le coup là où il brille vraiment en créant une carte graphique 2D+3D en 16 millions de couleurs, avec en plus des entrées/sorties vidéo et de l'incrustation en temps réel.

Une bête, le véritable marché du i860 et sa grande force.

Pour résumer

Le i860 est une des premières CPU avec une GPU (2D + 3D limitée) intégrée, extrêmement capable, qui lui ouvrira des marchés comme sur la carte couleur NeXTDimension pour les NeXTCube, mais en aucun cas une CPU capable de se mesurer aux meilleures.
Je comprends pourquoi Apple l'a essayé, avoir un ensemble CPU avec des capacités de GPU même partiellement 3D, intégrée et permettant de pousser les Macintosh en avant sur les marchés nécessitant ce type de fonctionnalité.

Le Intel i860 n'aura aucun avenir comme CPU générale et surtout pas comme remplaçant du x86, et son successeur VLIW Itanium qui était pour Intel l'avenir en 64 bits via IA-64 (Intel Architecture 64 bits) se heurtera aux mêmes limites du VLIW et sera la fin de ce type d'architecture chez Intel avec encore un échec cuisant, qui permettra à AMD d'offrir une architecture x86 64 bits qu'Intel adoptera un an plus tard.

Il y aura beaucoup plus lourd dans le prochain épisode, où Apple s'attaque à NeXT!

Lien vers le billet original

[solex46]

C'est quand même incroyable tout ce qu'on découvre dans ces brèves sur les CPU.
En gros, si je comprends bien, les concepteurs lancent des trucs sur la foi de performances théoriques, sans même développer au préalable des compilateurs adaptés aux softs existants et aux manières classiques de programmer, pouvant directement être utilisés pour faire des mises à jour performantes de ces softs.

J'ai pas mal programmé dans ma vie, et si j'ai souvent fait attention à optimiser à mort le code pour que ça aille le plus vite possible, je ne me suis jamais occupé d'optimisations directement adaptées à une architecture particulière de CPU.
D'ailleurs, j'imagine qu'en C ou objective C, on ne peut pas faire ça.
C'est le compilo qui s'occupe de tout.
Me trompe-je ?

[jeandemi]

est-ce qu'il y a un lien entre ce i860 et les cartes graphiques i740 AGP?
https://en.wikipedia.org/wiki/Intel740

[Paul Emploi]

Tu es dans le vrai, mais aujourd'hui et encore avec des jeu d'instruction pas aussi délirants!
À cette époque là, les compilateurs n'étaient pas aussi avancés, et les architectures délirantes pour essayer de sortir le maximum de performances.

Les sauts notamment posent problèmes puisqu'obligeant à recharger le pipeline et faisant donc perdre nombre de cycles dépendant de la profondeur de celui-ci.
On avait vu l'exemple de l'instruction toujours exécutée après un saut, là-aussi un casse-tête pour un compilateur qui en fait mettait un NOP (pas d'opération) en général à la place, faisant perdre le bénéfice de cette optimisation technique.

Là on en arrive à du code qui marche sur la tête si je puis dire, un exemple pour une copie de x nombres flottants fp32:

Code

CLEAR LOOP:
    bra r5, r6, CLEAR LOOP     // Loop for the 16 times
    fst.l fO, 4(r4)++     // Write and auto increment

Oui la décrémentation associée à son test et au saut est au début de la boucle, et saute sur lui-même!

Pour le i740 catastrophique, il n'y a aucun rapport avec le i860.

[Hebus]

Intéressant !!! j'avais oublié que la fameuse carte, que je n'ai jamais eu l'occasion de voir en action, avait un proc Intel ... je regarderai dès que j'ai le temps dans mes vieux docs précieusement gardés de cette aventure si j'en trouve trace !

@solex46

jamais fait non plus excepté un peu d'assembleur inline , mais on faisait beaucoup ça dans le temps car les compilateurs pouvait générer du code vraiment pas optimisé... aujourd'hui rivaliser avec un compilateur en écrivant en assembleur ... ce doit être l'affaire d'experts

[Paul Emploi]

J'ai fait cela en essayant de chasser chaque cycle, chaque perte, mieux exploiter les registres, mais depuis une vingtaine d'année, gcc fait cela de manière bien plus consistante et efficace, je pense que c'est vers 2005 qu'il a commencé à me battre à plate-couture, à chaque fois.

Il y a quelques possibilités pour moi de m'exprimer avec AVX2 par exemple, Intel ayant enlevé AVX-512 de nombre de ses CPU à cause des cœurs Économiques ne le supportant pas.
Une partie avec les Intrinsics où le compilateur a des problèmes pour déterminer les dépendances, l'autre avec du code direct en se foutant du compilo!
Comme charger 256 bits alignés d'un coup au lieu de 4 ou 6 chargements mélangeant 64 bits et 32 bits via les registres AVX2 et gagner quelques cycles, en utilisant l'atomicité des transactions mémoires puisque unique grâce au modèle du x86.

Mais en tout état de cause, pour du code non-vectoriel, je ne pense pas que l'humain puisse lutter.
Pensez qu'on peut demander un code 32 bits compatible 386 mais optimisé pour un Core [1], ou 64 bits compatible Core 2 et optimisé pour une CPU récente, il y a un savoir énorme qui a été mis dans gcc et qui dépasse largement ce que 99.9% des développeurs peuvent absorber!

[amike]

Et Apple l'a essayé, parmi d'autres idées assez farfelues comme le Scorpius du projet Aquarius,

A ce propos, la specification est disponible. En voici le lien : https://mirrors.apple2.org.za/www.bitsavers..._1.0_198810.pdf

On peut y lire que le but était d'utiliser non pas une unique puce pour tout faire et traiter simultanément plusieurs programmes (cf. article de MacB sur le scorpius), mais

(From the operating system viewpoint, a Scorpius-based system perhaps should be considered as a form of distributed system.)

Soit une même brique de base pour différentes implémentations et compositions, avec une répartition de traitement en plusieurs UT.

Farfelu, certes, mais pour faire différents objets informatiques (ordinateur ou imprimantes, ...) avec une variété de conception, sans dépendre d'un fabriquant, et avec force bidouilles ...
---
Pour en revenir au I860 et au VLIW, je me rappelle qu'il était question d'aller jusqu'à des longueurs de mot de 128 bit.
Si vrai, n'eut ce pas été mieux ?

[Mac Arthur]

Et bien bravo !
J'ai assez hurlé au début avec les billets à la "Morandini" et les unes racoleuses qui n'avait rien à voir avec je pense l'esprit du forum pour apprécier à sa juste valeur ce revirement rédactionnel.
On a là depuis quelque temps toute une série de billets de haute volée technique et qui sont passionnant.
Laissez aux autres forums "commerciaux" les news à scandale et continuez dans cette voie.
Encore chapeau pour ce boulot

[Paul Emploi]

Et Apple l'a essayé, parmi d'autres idées assez farfelues comme le Scorpius du projet Aquarius,

A ce propos, la specification est disponible. En voici le lien : https://mirrors.apple2.org.za/www.bitsavers..._1.0_198810.pdf

On peut y lire que le but était d'utiliser non pas une unique puce pour tout faire et traiter simultanément plusieurs programmes (cf. article de MacB sur le scorpius), mais

(From the operating system viewpoint, a Scorpius-based system perhaps should be considered as a form of distributed system.)

Soit une même brique de base pour différentes implémentations et compositions, avec une répartition de traitement en plusieurs UT.

Farfelu, certes, mais pour faire différents objets informatiques (ordinateur ou imprimantes, ...) avec une variété de conception, sans dépendre d'un fabriquant, et avec force bidouilles ...
---
Pour en revenir au I860 et au VLIW, je me rappelle qu'il était question d'aller jusqu'à des longueurs de mot de 128 bit.
Si vrai, n'eut ce pas été mieux ?

Pour le Scorpius de 1989 que j'ai traité ici, le problème est qu'il fut conçu pour être la CPU de Macintosh avec une à quatre unité, pas pour des périphériques créés par Apple qui aurait alors contrôlé le logiciel s'y exécutant.
Ses difficultés de programmation et son modèle très différent des 68k, x86 et divers RISC souvent issus d'un mélange de Berkley et de Harvard aurait posé d'immenses problèmes pour les portages logiciels, l'époque n'étant d'ailleurs pas au multithread même si existant mais plutôt au multiprocessus où l'architecture à 4 thread par CPU était tout autant inadaptée.
Il faut quand-même rappeler qu'avec plusieurs CPU on conseille d'arrêter une thread sur quatre pour répondre plus vite aux interruptions générées par les échanges entre puces, on paye pour 16 threads mais ça va plus vite si on utilise seulement 12 threads!

Le i860 avait un bus interne de 128 bits, car sa grande force pour moi était son unité graphique incroyable capable de pousser des tonnes de pixels en 32 bits (24 bits RGB + 8 bits) sans s'essouffler, d'où aussi le bus externe 64 bits qui serait surdimensionné pour toute autre CPU 32 bits de l'époque.
J'aurais bien vu l'usage du i860 pour une machine intégrée et très graphique, mais il était aussi extrêmement cher car Intel et la première CPU à dépasser le million de transistors!

Le FMAD multiplication+addition lançables dans le même cycle de l'unité flottante est là aussi énorme pour des applications scientifiques, le i860 visait vraiment les stations de travail graphiques et scientifiques. Quand-même un marché de niche à l'époque.
Mais incapable de faire tourner du code entier aussi vite que ses concurrents, ce qui pour le coût...

Un bus de donnée 128 bits aurait été une suite logique quelques années plus tard pour pousser les pixels bien plus vite, comme pour les GPU dédiées.
Il me semble qu'aucune alternative sérieuse n'existait aussi performante et programmable à la fois, nécessaire pour Display Postscript du NeXTcube.

[hthomas]

(message supprimé)

Ce message a été modifié par hthomas - 13 Jan 2024, 11:23.