Cela ne veut pas dire que les puces de 2022 ne seront toutes plus compatibles avec les instructions 32 bits, mais les tablettes et autres smartphones embarquant des SoC uniquement constitués de coeurs haut de gamme ne seront plus en mesure de les exécuter.
Les solutions mixtes, proposant des coeurs compatibles 64 bits et d’autres également capable d’exécuter du 32 bits en big.LITTLE pourraient prendre en charge ces applications mais cela veut dire qu’elles seraient alors exécutées beaucoup moins rapidement. Si seuls les coeurs LITTLE peuvent les prendre en charge, elles devraient être largement ralenties. Cela laisse tout de même deux ans et plus pour que les éditeurs se mettent à jour en basculant leur code en 64 bits. Je ne me fait pas trop de soucis pour les gros éditeurs et les applications récentes. Par contre, si vous êtes fan d’un jeu assez ancien ou si l’éditeur de votre application phare a disparu ou ne met plus à jour son travail, cela risque de poser problème.
Le but du jeu pour ARM étant de se focaliser sur le 64 bits, étape nécessaire pour améliorer les performances de ses solutions. Un gain en vitesse indispensable pour continuer à évoluer et faire face à des demandes de plus en plus lourdes et complexes. En particulier avec l’arrivée de plus en plus gourmande de l’Intelligence Artificielle et de la Réalité Virtuelle. L’abandon du 32 bits semble également être une demande des développeurs pour éviter d’avoir à travailler sur les deux formats. La démarche semble difficile mais elle semble nécessaire pour se débarrasser de branches mortes ou d’éléments ralentissant la croissance du système. D’autres concepteurs de processeurs n’ont pas eu ce courage ou cette volonté au fil des années et se retrouvent aujourd’hui dans des positions compliquées.
En 2021, la nouvelle génération baptisée Mattehorn marquera le début de cette transition. En 2022, l’arrivée de Makalu devrait se solder par une hausse de 30% de performances en plus par rapport aux Cortex-A78 actuels.
ARM en profite également pour rappeler l’arrivée du MTE désormais adopté par Google sur Android. Le Memory Tagging Extension est une solution de sécurité visant à empêcher les intrusions en mémoire. Une manière pour les développeurs de vérifier si les éléments appelés par les programmes correspondent bien à celles qui y ont été stockées. Sans altération par une application tierce…
| 2,5€ par mois | 5€ par mois | 10€ par mois | Le montant de votre choix |
Petite coquille : L’abandon du 64 bits semble également être une demande des développeurs…
32 plutôt non ?
@Jarre: Bien vu, merci :)
« D’autres concepteurs de processeurs n’ont pas eu ce courage ou cette volonté »…
Certes, mais parmi ceux là, certains ont eu un jeu d’instruction bien pensé dès le départ et le passage n’a rien révolutionné à ce niveau. Les registres généraux du coeur sont passé à 64 bits et le gros du problème du passage 32->64, c’était côté développeurs (casts cochons en C…) pas vraiment côté fondeur.
Faire du passé table rase était inéluctable pour ARM, car supporter un jeu d’instruction 32 bits, le Thumb qui va avec (jeu 32 bits avec taille d’instruction variable pour faire des programmes moins gros et gagner côté utilisation RAM), puis désormais le jeu 64 bits… Ca fait 2 de trop.
Et encore, google n’ayant pas voulu se lier pieds et poings à ARM avec Jazelle, cela aurait pu faire 3. Pour une architecture censée avoir l’efficacité dans les gênes, ça commençait à ressembler à l’accumulation de mauvaise graisse chez Intel…
Alors pour, au delà de la plateforme, faire tourner essentiellement du Java ou autre VM à bytecode peu dépendante de ce qu’il y a en dessous il est évident que faire du passé table rase était la meilleure option: Pas de vieux soft métier compilé dont on a paumé les sources dans les années 80 à faire tourner sous Android.
@Will: Non, sur Windows 32 bit, c’est l’OS lui-même qui empêchait de monter plus haut que 4 Go pas le processeur 32 bit.
Si je ne me trompe pas.
@yann iOS tourne aussi sous arm, ainsi que de nombreuses solutions non Android.
Il y a certes un grand nombre de périphériques Android, je ne suis toutefois pas convaincu que la majorité des développeurs ciblant arm visent une VM proposant une abstraction forte de l’adressage mémoire.
A titre personnel, je ne peux qu’applaudire a la fois le courage que ça nécessite et les gains de productivité probables pour les équipes arm.
@Le Breton En théorie on doit pouvoir concevoir un OS sur 32 bits qui gère plus de 4 Go de mémoire vive… mais concrètement ce serait assez compliqué. Avec 32 bits la taille de « l’espace d’adressage » (toutes les adresses qui peut écrire avec 32 bits) fait 4 Go. Donc c’est pratiquement une limite absolue.
Ceci étant, Qu’une partie du proc puisse fonctionner en 32 bits n’est pas un obstacle pour avoir un espace d’adressage > 4 Go. :-)
Ca reste une fuite en avant, des procs arm qui étaient présentés comme frugaux en ressources demandent au final autant que les bons vieux X86. C’est à croire qu’une fois encore on va produire et jeter pour produire plus rapide, plus puissant plus ce que vous voulez…
Personne semble-t-il n’a envie de parler optimisation du code, toujours le paradigme du petit vélo avec un gros musclé qui pédale très vite.
@Christophe:
Hello, ben en fait à part Windows, personne n’avait de problème pour gérer plus de 4Go de RAM avec les processeurs 32bits à partir du 486(pas sur pour le 386). Les processeurs calculaient en 32 bits mais avaient une gestion d’adressage mémoire en 36bits soit 2^36 = 64Go de mem possible. Linux et Unix (y compris Mac OSX) le géraient très bien. A priori la seule limitation était de 4Go par processus. En fait Windows en 32bits était tellement bien programmé que la mémoire utilisable était même limitée à 3Go il me semble, ils utilisaient le dernier giga pour gérer l’adressage d’autres trucs…
Une architecture (processeur + Windows) 32 bits ne peut gérer que 3.5Gio de mémoire vive. Je me souviens plus pourquoi (PB de BIOS ?).
@dadoo développer c’est compliqué en soit.
l’optimisation c’est ajouter de l’huile sur le feu.
En fait optimiser est parfois une erreur (on parle bcp par exemple d’early optimisation).
C’est pas que les entreprises et les développeurs ne veulent pas optimiser c’est que la complexité croit exponentiellement avec l’optimisation. Et développer c’est réussir à gérer la complexité.
@hle:
32 bits => 2^32 états possibles pour l’adressage = 4Go. Rien de compliqué là dedans. Comme les IO (plages PCI(e) pour les cartes d’extension, bridges/PCH… sur un PC) sont comprises dans ces 4GB, il en reste en réalité moins (variable selon la configuration de la machine) pour la RAM.
Mais la capacité d’adressage est un faux problème, car le PAE existe sur quasiment toutes les architectures 32 bits pour étendre l’adressage à 46 bits. Soit 64To, ce qui laissait quand même de quoi voir venir.
Ce qui devenait limitant, à une période ou plus grand monde ne sait encore coder un truc sans se lier à une tétrachiée de dépendances dont une bonne partie serait souvent évitable, c’est que les 4Go continuaient à s’appliquer pour ce qu’un processus est capable d’allouer.
Le problème du 32 bits devenait en réalité celui d’un applicatif de plus en plus obèse, mal architecturé, dépassant désormais de plus en plus souvent la taille de la plateforme sur laquelle il tourne…