Rosetta 4 sera-t-elle bientôt indispensable ?

[Sethenès]

J'aimerais attirer votre attention sur un point qui à mon avis échappe à de nombreuses personnes.

Ces 30 dernières années, le monde informatique a bénéficié d'une forme de protection. De plus cette durée est telle que je pense que tous tiennent cela pour acquis. Or, je ne suis pas sûr que ce soit le cas. Je m'explique.

Le x86 offre une garantie de compatibilité ascendante et descendante. Dis comme ça, c'est bien. Mais concrètement qu'est-ce que cela signifie ?

Je vais prendre un exemple avec un software que j'ai acheté et qui pilote une CNC (les imprimantes 3D sont des CNC). Ce soft a maintenant 5 ans et je l'ai installé sur un vieux PC acheté en 2008. Ce soft est compatible Windows 7, 10 et 11. Autrement dit, j'ai la garantie que si dans 5 ans, j'achète un PC, je pourrais toujours installer ce software, même si la société n'assure plus le suivi, qu'elle a fait faillite, ...

Vous vous rendez compte de l'énorme avantage que cette situation apporte ? Le même soft (avant on aurait parlé de binaire) peut indifférement tourner sur un PC de 2008 et sur un PC de 2028.

"La" question à laquelle je n'ai pas de réponse est de savoir ce qu'il en est du côté des puces ARM. Sont-elles compatibles de manière ascendante et descendante ? Comme ce n'est jamais mis en avant ... j'ai un doute (mais qui ne présume de rien).

Ici, avant de continuer, je dois préciser certains éléments. Le PC de 2008 était livré avec Vista ainsi que les drivers pour revenir à XP si nécessaire. Heureusement, j'ai pu installé Windows 7 et c'est grâce à cela que j'ai pu installer le soft car je pense qu'il n'était compatible Windows XP ou Vista. Vous le voyez, il faut une double compatibilié. D'une part, le processeur doit être compatible et d'autre l'OS doit permettre de faire tourner le programme. D'ailleurs pour utiliser ce même programme sur Windows 10 ou 11, l'OS fourni une couche de compatibilité car le soft initial est compilé en 32 bits. Mais grâce à "Wow64" (Wow = Windows on Windows, à comprendre Windows 32 on Windows 64) il est possible de faire tourner une application 32 bits sur un OS 64 bits.

Ici, il faut bien comprendre que Wow64 est totalement à l'opposé de Rosetta 3. Rosetta 3 pallie non pas le problème d'OS mais bien le problème de processeur. C'est au fond une passerelle qui permet d'exécuter 2 softs macOS (même OS) sur 2 HW différent (x86 "on" ARM).

Alors ceux qui me répondraient que c'est le problème d'Intel. Oui et non. D'abord si Rosetta 3 prend en charge tous les x86 sur lesquels on peut installer une version de macOS qui contient Rosetta 3, c'est justement parce que les x86 sont compatibles entre eux. Imaginez si Apple avait du développer une version Rosetta 3 pour les PC de moins de 3 ans, de moins de 5 ans, ... Je suis certain que le support des x86 "un peu trop vieux" aurait été absent.

D'ailleurs tant qu'à parler de Rosetta 3, ça doit démanger Apple d'en arrêter le support et sait bien ce qu'il se passer ce jour là. Ceux qui auront besoin d'un soft qui n'est nativement supporté sur ARM ... garderont la dernière version de macOS qui supportera Rosetta 3. Exactement comme il en fut avec Rosetta ... je n'invente rien !

Plus fondamentalement, si les génération de puces ARM ne sont pas compatibles entre elles ... je suppose que vous voyez où je veux en venir ? Oui, il sera nécessaire à Apple d'offrir un Rosetta 4 qui permettra (par exemple) de faire tourner les binaires compatibles M1, M2, M3, M4 sur des architectures M5, M6, ... 

[Fred4]

Dans quelle mesure un outil comme Merge VM Professional (s'il tient ses promesses) (ou un autre comme UTM) peut palier à ces situations ? 

A mon modeste niveau, j'ai installé une machine virtuelle Windows XP avec VirtualBox sur mon MBP intel 2018 Ventura, donc un cas très simple.

Je constate néanmoins qu'il est assez facile de disposer ainsi d'un vieux logiciel (financier en l'occurrence) sur du matériel récent et un OS distinct. 

S'il est possible de procéder de façon analogue avec les principales versions de plusieurs OS sur les déclinaisons des puces Silicon, il semble envisageable de palier aux éventuelles futures incompatibilités entre elles. 

[pehache]

Il y a 7 heures, Sethenès a dit :

Le x86 offre une garantie de compatibilité ascendante et descendante.

Pas exactement. Le jeu d'instruction d'un Pentium des années 1990 est toujours présent dans les tout derniers Xeon (donc un binaire des années 1990 peut toujours être exécuté actuellement), mais l'inverse n'est pas vrai. Par exemple les instructions vectorielles AVX512 sont forcément absentes des CPU x86 conçus avant 2013 (donc un binaire qui exploite ces instructions ne peut pas tourner sur un vieux PC).

Il y a 8 heures, Sethenès a dit :

"La" question à laquelle je n'ai pas de réponse est de savoir ce qu'il en est du côté des puces ARM. Sont-elles compatibles de manière ascendante et descendante ? Comme ce n'est jamais mis en avant ... j'ai un doute (mais qui ne présume de rien).

J'ai le même doute... Dans les téléphones Android ce ne sont pas des binaires qui sont sont distribués pour les app, mais du bytecode portable qui est traduit en instructions binaires au moment de l'installation sur le téléphone. Pourquoi feraient-ils ça si n'est pour des histoires de compatibilité binaires...

[Sethenès]

Il y a 6 heures, Fred4 a dit :

Dans quelle mesure un outil comme Merge VM Professional (s'il tient ses promesses) (ou un autre comme UTM) peut palier à ces situations ? 

A mon modeste niveau, j'ai installé une machine virtuelle Windows XP avec VirtualBox sur mon MBP intel 2018 Ventura, donc un cas très simple.

Je constate néanmoins qu'il est assez facile de disposer ainsi d'un vieux logiciel (financier en l'occurrence) sur du matériel récent et un OS distinct. 

S'il est possible de procéder de façon analogue avec les principales versions de plusieurs OS sur les déclinaisons des puces Silicon, il semble envisageable de palier aux éventuelles futures incompatibilités entre elles. 

Ce que suggères est une approche concurrente à Rosetta 4.

J'utilise d'ailleurs la même astuce entre Windows 7 et Windows 10 car j'ai écrit énormement de programme en VB6 (tout simplement car on m'avait offert la licence) et malgré pas mal d'essais je n'ai jamais réussi à installer le programme VB6 sur Windows 10. Alors que les programmes compilés, eux, fonctionnent parfaitement sur Windows 10 (à conditions de "régistrer" certains composants, mais ça c'est peanuts).

Edited November 7 by Sethenès

[Sethenès]

il y a une heure, pehache a dit :

Pas exactement. Le jeu d'instruction d'un Pentium des années 1990 est toujours présent dans les tout derniers Xeon (donc un binaire des années 1990 peut toujours être exécuté actuellement), mais l'inverse n'est pas vrai. Par exemple les instructions vectorielles AVX512 sont forcément absentes des CPU x86 conçus avant 2013 (donc un binaire qui exploite ces instructions ne peut pas tourner sur un vieux PC).

Tu fais bien de relever, mais c'est quand même très particulier comme usage.

Je sais qu'il ne faut pas réécrire l'histoire non plus. Au moment de passer au 64 bits, Intel a tenté la rupture avec les Itaniums. C'était aussi l'occasion de repartir d'une page blanche. Et c'est là qu'AMD les a court-circuité en étendant les instructions x86-32 (bits) aux x86-64, qui sont utilisées aujourd'hui (c'est un comble) par tous les processeurs ... Intel (et AMD bien sûr).

Les choses sont toujours plus subtiles, mais ici, c'est une réflexion que je voulais initier. Et en même temps, expliquer pourquoi je suis si réticent vis-à-vis de l'approche ARM qui va se généraliser, je pense.

Edited November 7 by Sethenès

[pehache]

il y a 44 minutes, Sethenès a dit :

Tu fais bien de relever, mais c'est quand même très particulier comme usage.

Peut-être, ou pas... A moins d'empêcher explicitement le compilateur de générer ces instructions (ce qui est parfaitement possible), il est difficile de compter sur le fait qu'elles ne seront pas utilisées. Mais c'est un faux problème la plupart du temps en pratique : les logiciels grand-public courants sont compilés la plupart du temps de façon très conservative, du genre en n'utilisant pas d'instructions introduites il y a moins de 10 ans. Et en général c'est souvent le besoin inverse qu'on a : faire tourner un ancien logiciel sur une machine récente.

il y a 50 minutes, Sethenès a dit :

Je sais qu'il ne faut pas réécrire l'histoire non plus. Au moment de passer au 64 bits, Intel a tenté la rupture avec les Itaniums. C'était aussi l'occasion de repartir d'une page blanche. Et c'est là qu'AMD les a court-circuité en étendant les instructions x86-32 (bits) aux x86-64, qui sont utilisées aujourd'hui (c'est un comble) par tous les processeurs ... Intel (et AMD bien sûr).

Oui. Ca montre aussi que pour l'industrie, la solution rétro-compatible AMD était beaucoup plus attractive que repartir d'une feuille blanche. Après, Intel s'est aussi tiré une balle dans le pied avec cette affaire car les performances des premiers Itanium étaient vraiment mauvaises. S'ils avaient été 2 fois plus rapides que la solution AMD ils auraient peut-être (mais même pas sûr) emporté la partie.

[Sethenès]

"Ailleurs", quelqu'un a mentionné le Raspery Pi qui apparemment n'aurait de problèmes de compatibilité. A l'ocassion, j'investiguerai.

[Mout]

Le 07/11/2023 à 20:28, pehache a dit :

Dans les téléphones Android ce ne sont pas des binaires qui sont sont distribués pour les app, mais du bytecode portable qui est traduit en instructions binaires au moment de l'installation sur le téléphone.

Quelle est la diversité des architectures microprocesseurs sur les téléphones Androids ? 

Avec mon cloisonnement tout Apple, je ne vois que les iPhones qui sont ARM depuis le début, et ARM-version-Apple depuis l'A4 sur iPhone 4 (puis Apple Silicon pour les mac), et je suis un total n00b en technos et architectures Android. D'où ma question : Sur quoi peut-on installer Android ?

[pehache]

Le 29/11/2023 à 14:54, Mout a dit :

Avec mon cloisonnement tout Apple, je ne vois que les iPhones qui sont ARM depuis le début, et ARM-version-Apple depuis l'A4 sur iPhone 4 (puis Apple Silicon pour les mac), et je suis un total n00b en technos et architectures Android. D'où ma question : Sur quoi peut-on installer Android ?

En pratique je pense que tous les smartphones actuels ont des puces ARM. Il y a eu quelques curiosités avec des puces Atom x86 mais Intel a lâché l'affaire il y a un moment. AOSP (le code source d'Android) étant libre, rien ne s'oppose à ce qu'il soit compilé pour n'importe quelle plateforme, et il existe une version x86 pour PC (mais qui n'a pas l'air activement développée).

[LolYangccool]

Le 08/11/2023 à 14:38, Sethenès a dit :

"Ailleurs", quelqu'un a mentionné le Raspery Pi qui apparemment n'aurait de problèmes de compatibilité. A l'ocassion, j'investiguerai.

Avec les Raspberry Pi il est parfaitement possible de flasher un OS sur une microSD, Raspberry Pi OS dernière version, de l'utiliser sur un Pi 4 puis de prendre la microSD et de l'utiliser dans un Pi 3B par exemple, ça fonctionne parfaitement.
Attention quand même, Raspberry Pi OS est disponible en 64 bit depuis pas si longtemps que ça, donc cette technique marcherait avec un 32 bit pour à peu prêt tous les Pi je crois (à confirmer), mais pas avec les versions 64 bit qui nécessitent un Pi 3B ou 2B je ne sais plus, au minimum.

Edited November 30 by LolYangccool

[LolYangccool]

Ceci dit, pour répondre à la question en titre de ce topic, dans mon usage, je n'utilise déjà plus Rosetta depuis au moins une bonne année, tous mes logiciels ont maintenant une version disponible soit en binaire universel, soit Apple uniquement.