Les deux entités sont des partenaires de longue date, mais Arm semble décidé d’aller encore plus loin. La société vient en effet d’annoncer l’acquisition d’une « participation minoritaire dans Raspberry Pi ».
« Cet investissement cimente un partenariat qui a débuté en 2008 et qui a vu la sortie de nombreux produits Raspberry Pi basés sur Arm populaires pour les étudiants, les passionnés et les développeurs commerciaux », explique Arm.
Cette annonce intervient alors que les premiers exemplaires du nouveau Raspberry Pi 5 commencent à arriver chez les clients.
Commentaires (23)
Peu de chances de voir apparaître un “Raspberry V” après cela…
C’est la 1ère chose qui m’a traversé l’esprit :(
Pardon, mais qu’est ce que le raspberry V ( sachant qu’on est au raspberry 5. Soit V)
L’année de ARM sur le Desktop…
Probabilité que ARM Ltd veuille utiliser Raspberry comme vitrine ?
Hors Apple, qui maîtrise HW+SW dans un mode compatibilité source (plus proche de Linux) et non binaire (sauf phases de transition), je ne pense pas. Cela fait pas mal d’années que Qualcomm promets sans tenir avec Microsoft qui est dans un modèle économique totalement orthogonal à une sortie rapide du x86.
Rosetta marche plutôt bien, non ? La compatibilité n’est pas qu’au niveau source.
Rosetta, c’est efficace, mais ça ne fait pas de miracles non-plus, ça ne remplace certainement pas les perfs natives.
La force des outils comme FX!32, Rosetta et autres, c’est de recompiler partiellement les applications et de rebrancher les appels API vers les librairies natives, ce qui fait que les applications pas trop gourmandes question CPU en interne et s’appuyant sur des librairies existant en natif ont l’air de tourner à des vitesses quasi-natives (par exemple, la démo Qualcomm de Davinci Resolve x86 utilisait bien une librairie native utilisant le NPE pour les calculs intensifs)
Une application faisant du calcule intensif aura des performances aux alentours des 5-10% en émulé par rapport à la version native.
En terme de prix/dispo/format , c’est vrai que j’ai pas encore vu sur ce créneau d’offre risc-v viable.
Mais ça va arriver…
La vrai question c’est sur l’industrialisation & le support de l’écosystème. Si ils sont pas mauvais, les challengeurs devront créer un OS 1:1 avec entre autre un bon support des DTS & tout…
A mon avis et malgré le fait que le risc-v me séduit on en est pas du tout là encore.
Je me suis fait la même réflexion. Ca me paraît être le côté “stratégique”.
Bon, après il y a les clones.
Ca a l’air d’arriver. Et beaucoup d’applis ont des parties en .Net ou même python, ces applis ne souffrent pas de changer d’archi.
Les émulateurs Box64 et FEX ont des performances correctes en binaire. Mais voici un élément de comparaison: en gros, entre lancer une appli en ARM natif et compiler l’appli en x64 et la lancer sous l’émulateur, on perd 50 à 70% de perfs CPU (parfois plus, parfois moins).
Par contre si on est peu lié au CPU, on peut arriver à quasi 100% de la perf “ressentie” (exemple: en comptant le nombre d’images / secondes d’un jeu)
C’est testable sous Android (Winlator) et SBC comme les RPI (box64)
Sur Mac, Microsoft propose “Windows 11 ARM” pour Parallels Desktop.
On n’est donc pas très loin de pouvoir acheter une licence “Windows 11 ARM” auprès de Microsoft et l’installer sur la plateforme ARM de son choix.
Techniquement, tu peux installer Windows ARM sur n’importe quel device (à condition d’avoir les bon pilotes et de gérer le bootloader), mais vu que les modèles se comptent sur les doigts de la main… le boulot est déjà fait.
Sinon, j’ai essayé les dernières versions sur emulateur (qemu), c’est hyper lent (forcément)… mais ça fonctionne.
Windows on ARM a depuis fin 2020 un émulateur pour les apps win32 en 64 bits et avant ça était déjà compatible en 32 bits.
La dispersion d’ARM qui entrave son développement serait évitable si le problème est pris tôt côté RISC-V: Tout est déjà là depuis longtemps dans l’alternative Device-Tree pour permettre la standardisation type énumération PCIe+UEFI, sans l’usine à gaz associée.
Ce qui manque à mon sens, c’est leur intégration de manière standardisée dans le matériel même, par exemple un bout de flash SPI, afin de sortir cela de tables hardcodées au boot-loader (voir à l’OS) qui n’aurait plus que la découverte de ces bouts de DT à réaliser et le merge de tous ces DT et leur mapping global à assurer avant de les passer à l’OS démarré.
Puis Raspberry venant de doubler ses tarifs historiques, d’autres pourraient choisir d’éviter de payer des royalties à ARM. AMHA, la nature va vite avoir horreur du vide tarifaire laissé (et sans négliger l’aspect logiciel comme les chinoiseries existantes)…
Pour une phase de transition, quand bien géré ça fait le job comme je le disais. Mais même chez Apple c’est pas l’objectif de long terme quand ils changent d’architecture.
Chez Apple, quand on parle de changement de famille de processeurs, ce n’est pas forcément le “long terme” qui me vient à l’esprit.
En se limitant aux macs :
en même pas 40 ans !
Et pour faire tourner de l’applicatif x86, ce qui est le gros des attentes sous windows, on aura une brouette poussée par une usine à gaz…
Pour faire ce genre de pile logicielle capillotractée sur un Mac, faut être un peu tordu quand même!
C’est sans aucun doute l’attente des vieux power-users accoutumés à leur panoplie d’outils/applis historiques. Et aussi pour les utilisateurs “pro” qui ont besoin d’un logiciel spécifique (CAO, compta…).
Pour un usage domestique, Windows c’est principalement Office, Web et Jeux.
Et encore, les jeux c’est de plus en plus sur console et smartphone :/
Avoir un Windows 11 ARM avec Office et Web en natif ARM, et le reste traduit à la volée façon rosetta… ca pourrait être acceptable.
Non, c’est juste la conséquence de tout un écosystème qui a basé 40 ans de succès sur la compatibilité de binaire (dont certains ne seraient même plus compilables, si toutefois on n’en a pas carrément perdu les sources, mais sont encore au cœur de bien des usages surtout industriels il est vrai) et qui se retrouve coincé par ceux qui sont dans la compatibilité de source (d’une cross-compilation sur toute plateforme que gcc supporte) et n’ont pas à traîner ce pesant boulet de dette technique.
Et les utilisateurs domestiques sont aussi formatés à ce modèle, même sans réelle nécessité, car ils ont cet historique gravé en eux et… windows au taf!
Sinon Linux aurait bien mieux percé sur le desktop depuis 8⁄10 ans que les derniers problèmes resté longtemps pénibles (imprimantes/scanners: Désormais c’est sous Windows que j’ai été emmerdé ces dernières années quand une Debian bien basique faisait le job direct) sont de l’histoire ancienne.
Windows a même réussi à faire préférer la console au PC pour le jeu, justement, c’est dire: Y’a un moment ou la config au p’tits oignons OS/graphique d’un jeu qui fait merder l’autre et inversement, cela gave même des accrocs et ils vont vers un truc ou d’autres se tapent l’intégration du foutoir (facilitée par la standardisation matérielle) à leur place.
Raspberry (RISC-)V
Dans le domaine, 4 architectures en 40 ans cela fait quand même 10 ans/archi en moyenne! C’est pas du court-terme ni même du moyen, surtout dans un domaine qui a évolué vite.
Mais cela a par contre été assez pour avoir à l’esprit l’intérêt d’avoir un écosystème SW facilement portable pour Apple/partenaires, plus encore sans doute depuis le passage à une base BSD (modèle de compatibilité de source, comme Linux, mais sans la licence métastasante qui hérissait Steve Ballmer!).
Non mais c’est surtout qu’Apple c’est de la niche sur le marché qu’occupe le x86 à savoir le grand public et les serveurs hors mainframe. Apple c’est pour du cadre moyen/sup de moyenne/grande ville mais pas plus et bien sûr inexistant dans le monde du serveur.
L’arm en grand public je n’ai rien contre, c’est très bien pour faire des ordinateurs basse conso type chromebook ou smartphone mais on est à des années-lumières de la richesse d’instructions de x86 et donc de sa polyvalence.
Par ailleurs, je rappelle qu’intel tire la moitié de ses revenus de sa branche PC pour un bénef total de 7-8Mds/an c’est à dire 2-3 fois le CA (j’ai bien dit le CA) d’ARM, donc la mort du x86 certainement un jour mais pas tout de suite.
En réalité, c’est un tas de m… qui oblige à se boucher le nez quand on a bossé sur autre chose… Mais hélas, le poids des années…
C’est clair que le x86, question élégance, on peut repasser… J’ai fait du M68k et du 6502 et quand, au début des années 90, j’ai finalement commencé l’assembleur x86, c’était un peu le choc esthétique.
Enfin bon, tout ça de nos jours est généralement masqué par de bons compilateurs et je ne fais plus d’assembleur x86 que très occasionellement, par exemple lorsque je fais du débugging de pilotes.
Euh, non. ARM a des instructions pour tout ce qui est “utile”. x86/x64 continue à se traîner des instructions plus oumoins marketing ou venant de l’époque ou la RAM était chère et le cycle CPU aussi (genre les comparaisons de chaîne, le calcul en BCD)…
Pour être honnête, il faudrait comparer le CA d’ARM + des fondeurs de puces ARM à celui d’intel - qui est alors dans les choux…