Pour Ming-Chi Kuo, il faudra attendre 2025, 2027 voire 2028 pour la voiture Apple
Ce n'est ni demain la veille, ni en 2024 que l'on pourra demander à Siri de nous conduire quelque part dans une voiture Apple flambant neuve. Ming-Chi Kuo rebondit sur les folles rumeurs de ces derniers jours en y jetant un gros paquet d'eau froide : selon l'analyste-qui-voit-tout, l'Apple Car ne sortira pas du garage de Cupertino avant 2025 à 2027, au plus tôt. Il y a deux ans, le même Kuo estimait que ce véhicule pouvait sortir « entre 2023 et 2025 ».
Si Ming-Chi Kuo est revenu sur son estimation, c'est que le calendrier d'Apple n'est « pas clair ». Si le développement a effectivement été lancé cette année, alors la voiture pourrait être disponible entre 2025 et 2027. Mais l'analyste de TF Securities ne serait pas étonné que la commercialisation du véhicule soit repoussée à 2028, voire plus tard encore, en fonction de l'évolution du marché des voitures électriques et autonomes.
Kuo pense qu'Apple n'a pas nécessairement toutes les cartes en main pour réussir à s'imposer dans ce secteur, en prenant exemple sur le semi-échec du HomePod (l'analyste écrit même que la demande pour le HomePod mini a été « plus faible que prévu »). La concurrence dans le secteur automobile est bien plus féroce que sur celui des enceintes connectées, ajoute-t-il. Penser qu'une voiture Apple connaitra forcément le succès est « périlleux » à ce stade, selon lui, car si le constructeur peut en remontrer à n'importe qui sur le plan matériel, il serait moins bien armé que d'autres dans le domaine de l'intelligence artificielle et du big data.
« L'une de nos préoccupations concernant la voiture d'Apple est que lorsqu'elle sera lancée, les autres constructeurs de voitures autonomes auront accumulé au moins cinq ans de données et elles seront mieux adaptées pour l'apprentissage automatique. Comment Apple parviendra-t-elle à surmonter ce retard ? »
Ce point d'interrogation concernant les capacités AI d'Apple, c'est peut-être ce qui a poussé le constructeur à donner à John Giannandrea, le grand manitou de l'apprentissage automatique, les rênes du projet Titan (lire : John Giannandrea reprend le projet Titan, et Bob Mansfield sa retraite).
Aujourd’hui, cette idée paraît aussi dingue et irréalisable qu’un Mac ARM en 2015.
@FloMo
La comparaison est sphériquement incorrecte : fausse, quel que soit l’angle sous lequel on l’examine.
La seule idée dingue et saugrenue en 2015 eût été de ne pas prédire le remplacement des CPU x86/x64 par des architectures ARM plus efficaces et plus performantes, à plus ou moins brève échéance, ainsi que l’harmonisation matérielle et logicielle de toute la gamme qui en découlerait.
À un niveau plus général — et Kuo met le doigt dans la plaie avec une précision toute clinique — il s’agit, d’un côté, de choses qu’Apple maîtrise parfaitement ; de l’autre, de domaines où Apple doit absolument faire ses preuves à l’échelle requise : Big Data, ML, AI.
@occam
Je suis pas sûr qu’il fallait prendre à ce point ce commentaire au premier degré.
@Furious Angel
Sphériquement.
Sous tous les angles d’incidence concevables, y compris compris celui du degré.
Sinon, pourquoi aurais-je pris soin de placer une formule more geometrico ? 😎
@occam
Concernant la partie ML, des chercheurs du CNRS qui travaillent sur des réseaux de neurones électroniques ont fait le constat inverse par rapport au M1.
@FloMo
"Concernant la partie ML, des chercheurs du CNRS qui travaillent sur des réseaux de neurones électroniques ont fait le constat inverse par rapport au M1."
Occam ne remet pas en cause, il me semble, les ressources de traitement ML proposées par Apple que ce soit au niveau hardware ou outil de développement.
C’est du côté des usages qu’Apple n’est pas forcément au pinacles comparé à ses concurrents. En grande partie par justement un manque de données disponible en comparaison avec ces concurrents, différences de modèle économique oblige.
@YetOneOtherGit
Je pense qu’Apple vise l’apprentissage non-supervisé à moyen terme.
À court terme, la clé sera le Private Federated Learning.
Apple a juste pris son propre chemin.
Après, je peux me tromper. On est dans de la prospective pure. 😁
@FloMo
"Après, je peux me tromper. On est dans de la prospective pure. 😁"
Je ne me risquerais pas à la moindre prospective sur le sujet ;-)
@YetOneOtherGit
On se fait un peu plaisir. 😁
Ça me donne envie de me pencher sur des sujets un peu plus bas niveau.
C’est un peu le soucis en ce moment : on peut difficilement être sur la connaissance des frameworks macOS / iOS qui évoluent à grande vitesse (Swift, SwiftUI, Combine, Core ML, ...). Et en même temps sur des sujets comme Metal, Accelerate, Core ML « bas niveau », LLVM.
@FloMo
"C’est un peu le soucis en ce moment : on peut difficilement être sur la connaissance des frameworks macOS / iOS qui évoluent à grande vitesse (Swift, SwiftUI, Combine, Core ML, ...). Et en même temps sur des sujets comme Metal, Accelerate, Core ML « bas niveau », LLVM."
Il y a toujours un moment où pour continuer à monter en abstraction il faut paradoxalement descendre pour connaître le sous-jacent ;-)
@FloMo
Peut on lire cette étude du CNRS quelque part? Ça m’intéresse bcp
@jopaone
Ce n’est pas une étude. C’est une émission d’une heure dans la Méthode Scientifique sur France Culture.
J’avais posé la question du M1 via Twitter par rapport à l’intérêt du Neural Engine. Et plus tard dans l’émission le sujet de la mémoire unifiée a aussi été évoqué.
https://www.franceculture.fr/emissions/la-methode-scientifique/la-methode-scientifique-emission-du-mercredi-09-decembre-2020
@FloMo
Merci beaucoup 🙏
@FloMo
Il faut voir à quelle échelle se situent les problèmes actuellement traitables sur M1 (et plus généralement sur Apple Silicon) par les moyens développés chez ou pour Apple et dont on a pu avoir une idée au moins indirecte.
Il faut contraster cette échelle avec celle des problèmes à traiter pour intégrer les données fournies par tout un parc de véhicules (ou, disons pour nous placer au niveau d’abstraction du laboratoire, d’« agents autonomes »). Sans parler de ceux liés à la gestion d’un tel parc en temps réel.
En schématisant, nous sommes devant un système à cadres concentriques : DL < ML < autonomous AI.
Apple possède une assise remarquable en DL, dont nous venons de voir les premiers fruits. Les iBidules vont l’intégrer de plus en plus. Les possibilités vont s’accroître en conséquence, et elles vont surprendre plus d’un.
Dans le cadre ML élargi, Apple commence à intégrer dans Silicon les capacités que vous évoquez. Reste à voir les logiciels, reste surtout à voir la question décisive de l’échelle.
Là encore, il faudra se décider : eau sucrée, ou Masters of the Universe. C’est une décision industrielle plus que conceptuelle.
Le dernier cadre, autonomous AI, est celui où Ming-Chi Kuo note l’apparent retard d’Apple par rapport à la plupart des autres acteurs, connus du grand public ou moins. (Je dis « apparent » pour le cas où Apple aurait caché l’équivalent d’un MegaWatson dans un silo balistique désaffecté de l’Arizona.) C’est le domaine où la concurrence possède l’expérience indispensable des problèmes liés à l’échelle, à la multiplication des agents et aux multitudes de données à traiter, données dont elle dispose également déjà.
@occam
Sur le logiciel, entre Catalina et Bug Sur (mais aussi entre iOS 13 et iOS 14), Apple a quasiment multiplié par deux ses performances sur la partie entraînement de modèles. Ce qui l’a amené à passer d’un retard vis à vis de TF2 à une avance.
Sachant que sur la partie entraînement accessible aux développeurs, le GPU n’est pas sollicité. Mais il l’est dans Create ML. Et on n’en sait rien pour le Neural Engine.
Aujourd’hui, Apple exploite son réseau pour ré-entraîner des modèles localement puis en centralisant les résultats avec une anonymisation au passage. C’est un peu commencer par le plus compliqué là où d’autres acteurs ne s’embarrassent pas du sujet vie privée.
Je pense qu’aujourd’hui on n’a encore rien vu sur le potentiel d’Apple en terme de ML.
Chacun avance ses pions et, comme à son habitude, Apple dévoilera son jeu en fin de partie.
Après, concernant les IA autonomes telles que survendues par Tesla et qui doivent toujours arriver en fin d’année, je n’y crois pas un seul instant. Du moins, pas avec nos connaissances actuelles du sujet. On n’a pas l’ombre d’une piste de travail.
On est sur une vision à 5-10 ans avec Apple Silicon. Le temps d’exploiter le matériel et d’optimiser le logiciel. Tout en montant en compétences sur les points de faiblesse.
D’ici là, je pense qu’on saura faire du non-supervisé. C’est dans le domaine du plausible vu la vitesse à laquelle les travaux avancent. Sans atteindre le niveau d’une IA autonome, ça pourrait changer la donne.
Les années à venir s’annoncent passionnantes. 😁
@occam
"est sphériquement incorrecte : fausse, quel que soit l’angle sous lequel on l’examine"
🍻santé aussi 🤪
@occam
Voilà donc le sachant spécialiste des puces x86. Et donc des véhicules connectés...
...Tous ces spécialités qui sont justes là pour donner des leçons. C’est fatiguant.
@Malouin
Reposez-vous. Vous en avez bien besoin.
@occam
Si tu le dis... ça me conforte du contraire !
@FloMo
Il y avait déjà des Mac ARM avant cela, et dans le M1 il n’y a que les 8 cœurs qui sont ARM, le reste c’est des accélérateurs divers. Et les cœurs custom Apple sont juste un peu plus rapides que ceux de qualcomm par ex.
@Adodane
Il y avait des Mac ARM avant 2015 ?
Concernant les 8 coeurs, il me semblait qu’il y avait 8 coeurs CPU, 8 coeurs GPU et 16 coeurs Neural Engine, le tout dans une architecture ARM avec mémoire unifiée.
@FloMo
Oui les Mac avec puce T2 donc l’accélération matérielle H264/265 doit être équivalente à la puce M1.
Pourquoi le GPU serait ARM ? Et le neural engine ? Quel rapport avec des instructions ARM ?
@Adodane
Euuuuh entre une puce T2 et une puce M1 il y a quand meme un minde hein?
@raoolito
Pas pour l’encodage H264/265.
@Adodane
Le H265 est géré par les processeurs Intel de 6ème génération.
Le traitement de l’image du T2 était utilisé pour améliorer la qualité de la webcam. (Exposition automatique, etc)
@FloMo
Le T2 permet de faire de l’encodage hardware, avec handbreak par ex.
@Adodane
Oui.
@Adodane
En 2015, le T1 n’existait pas. Il est sorti en 2016.
Et surtout, il avait son propre OS : bridgeOS.
L’architecture en tant que telle était x86_64. Avec un GPU éventuellement intégré. Mais ni mémoire unifiée, ni neural engine.
Les architectures ARM sont radicalement différentes des architecture x86_64
https://fr.wikipedia.org/wiki/Architecture_ARM
Et évidemment, les instructions ARM envoyée au CPU sont distinctes des instructions envoyées au GPU.
Ceci étant, le M1 sait interpréter certaines instructions x86. Ce qui le différencie des autres systèmes sur puce.
@FloMo
Tout ça pour dire que j’ai raison à propos des cœurs ARM ?
@Adodane
J’ai dit :
> Aujourd’hui, cette idée paraît aussi dingue et irréalisable qu’un Mac ARM en 2015.
Et vous :
> Il y avait déjà des Mac ARM avant cela, et dans le M1 il n’y a que les 8 cœurs qui sont ARM, le reste c’est des accélérateurs divers.
Non, les Mac ARM n’existait pas avant 2015. Il n’y avait même pas de co-processeur ARM.
Non, il n’y a pas que 8 coeurs dans l’architecture ARM du M1, mais 32. C’est un système sur puce, donc les composants sont indissociables. D’autant que la mémoire est ici unifiée. C’est l’énorme différence avec l’architecture x86_64.
Et les accélérateurs sont inclus dans chacun des composants : CPU, Neural Engine et GPU. Ils sont exploités via Metal (GPU), Accelerate (CPU) et Core ML (Neural Engine + appels aux 2 frameworks précités).
Et surtout, tout ça n’a aucun rapport avec le fait que cette idée de voiture Apple est aussi dingue et irréalisable qu’un processeur ARM dans les Mac en 2015. 🙂
@FloMo
2015, 2016 je me suis trompé de un an ? 😁
Et dans le M1 il n’y a que 8 cœurs ARM et non 32 ! 😁
ARM c’est un jeu d’instructions, 32 cœurs ça en ferait du multithreading !
Les processeurs Intel peuvent aussi avoir une mémoire unifiée puisque qu’ils ont un gpu intégré.
La mémoire unifiée existe depuis toujours( consoles, smartphones, tablettes, Amsterdam, Spectrum, atari 2600).
@Adodane
> 2015, 2016 je me suis trompé de un an ? 😁
Et un peu tout le reste, oui. 🙂
> Et dans le M1 il n’y a que 8 cœurs ARM et non 32 ! 😁
> ARM c’est un jeu d’instructions, 32 cœurs ça en ferait du multithreading !
Les 32 coeurs sont actifs en Machine Learning.
Et oui, ça dépote ! 👍
Pour la définition d’une architecture ARM, je vous laisse corriger Wikipedia.
https://fr.m.wikipedia.org/wiki/Architecture_ARM
> Les processeurs Intel peuvent aussi avoir une mémoire unifiée puisque qu’ils ont un gpu intégré.
La mémoire unifiée existe depuis toujours( consoles, smartphones, tablettes, Amsterdam, Spectrum, atari 2600).
Ce n’est pas de la mémoire unifiée mais partagée dans les processeurs Intel. Le fonctionnement est complètement différent. En mémoire partagée, la taille mémoire allouée est fixe. Et si le CPU souhaite accéder aux données du GPU, la donnée doit d’abord être copiée.
En architecture M1, chaque cœur du SoC, qu’il vienne du CPU, du GPU ou du Neural Engine, accède au même espace mémoire immédiatement.
@FloMo
Je me trompe tout le reste ? 🧐
Ça dépote peut être mais c’est ne sont pas des cœurs ARM, et ils ne sont pas 32 mais 16 !
D’ailleurs le dernier snapdragon est deux fois plus puissant en IA que le M1 (plus du double de TOPS).
A quoi pourrait me servir le lien de Wikipedia sur ARM ? Ils parlent du neural engine d’Apple ? Du dsp ? Du gpu ? De l’isp ?
La mémoire allouée n’est pas fixe, elle est dynamique.
Le igpu partage le cache L3.
Sur les consoles et smartphones/tablette c’est de la mémoire unifiée.
Ce qu’il faut surtout retenir c’est qu’on ne peut pas upgrader la mémoire, après les promesses marketing...
@FloMo
"Et surtout, tout ça n’a aucun rapport avec le fait que cette idée de voiture Apple est aussi dingue et irréalisable qu’un processeur ARM dans les Mac en 2015. 🙂"
La seule chose qui pourrait être dingue et irréalisable, ce serait d’imaginer Apple fabriquer ses voitures.
Apple sous-traitera la fabrication en Chine, comme elle sous-traite la fabrication de la totalité de ses produits.
Ceci n’a rien d’irréalisable.
Il y aura peut-être assemblage sur place pour des questions logistiques, mais sans doute sous-traité également.
@fte
Complètement.
Je pense qu’Apple peut profiter de l’expérience industrielle des autres. Et mettre à profit ses compétences informatiques dans le véhicule.
Aujourd’hui, c’est difficile à imaginer. Mais d’ici quelques années, ça pourrait sembler « évident ».
@FloMo
"Les architectures ARM sont radicalement différentes des architecture x86_64"
Il y a beaucoup plus de points communs que de différences, mais bon.
@fte
Je parle d’un point de vue matériel (système sur puce, mémoire unifiée). Côté logiciel, ça tend à se rapprocher.
Surtout sur le M1 qui intègre des instructions x86.
Après, Microsoft galère quand même pas mal avec Windows ARM. Et la virtualisation reste compliquée.
@FloMo
« Côté logiciel, ça tend à se rapprocher. »
Nope vraiment pas l’ISA ARM et x64 c’est le jour et la nuit.
« Surtout sur le M1 qui intègre des instructions x86. »
Pas vraiment, le M1 sait reproduire certains mécanismes d’accès mémoire out-of-order des cpu intel mais cela ne passe nullement par l’ajout d’éléments de l’ISA intel.
@YetOneOtherGit
Quand je dis que ça se rapproche côté logiciel, c’est à assez haut niveau. Grâce à LLVM notamment.
Par contre, j’étais persuadé que des jeux d’instructions x86 étaient traités par le M1 pour faciliter la transition. Robert Graham avait relevé que la gestion de mémoire était « simulée », mais les instructions x86 sont « traduites » en arm64 par Rosetta 2. J’étais persuadé que cette traduction était faite sur puce.
Après, je ne bosse pas beaucoup sur du bas niveau. Je n’ai donc pas trop de légitimité pour en juger dans l’absolu. Même si ça m’intéresse énormément. 😁
En tant que développeur « haut niveau », la transition s’est passée sans douleur. Mais clairement les capacités sont incomparables.
@FloMo
"Quand je dis que ça se rapproche côté logiciel, c’est à assez haut niveau. Grâce à LLVM notamment. "
Cela ne se rapproche pas particulièrement plus sur des langages de haut niveau qui par définition visent à s’abstraire du sous-jacent matériel depuis John Backus et Fortran au milieu des années 50.
En ce qui concerne le remarquable LLVM ce n’est pas plus un élément de rapprochement des ISA mais de renforcement du découplage entre le front et back d’un langage de haut niveau et l’exécution.
LLVM à permis des gains de performances sur la phase d’optimisation que ce soit pour la génération de code statique ou au run-time.
@YetOneOtherGit
Côté LLVM, je voyais encore plus haut niveau. ^^
L’aspect « transportable » du bitcode est bluffant. Et l’optimisation directement depuis l’App Store pour chaque matériel à partir du bitcode a un côté magique.
@FloMo
"Côté LLVM, je voyais encore plus haut niveau. ^^"
LLVM en soit c’est du bas niveau abstrait et virtuel.
Le cœur de LLVM c’est une ISA abstraite indépendante du matériel, c’est un code « machine » intermédiaire.
Le front-end de la chaîne de compilation transforme le code source d’un langage de haut niveau en LLVM.
Le back-end transforme en l’optimisant le LLVM en code exécutable sur une architecture dédiée.
On peut considérer cela comme un pivot entre de nombreux front pour divers langages de haut niveau et divers back pour diverses architectures matérielles.
Et en plus LLVM permet des approches de type JIT.
@FloMo
"En tant que développeur « haut niveau », la transition s’est passée sans douleur. Mais clairement les capacités sont incomparables."
On sent effectivement un intérêt pour ces questions mais aussi un manque de connaissances profondes.
Je te conseil quelques classiques :
https://www.amazon.fr/Computer-Architecture-Quantitative-John-Hennessy/dp/0128119055
https://www.amazon.fr/Computer-Organization-Design-Hardware-Interface/dp/0128201096
Les deux sont des classiques régulièrement mis à jour et les liens concernent les dernières éditions 🤓
@YetOneOtherGit
Merci pour les liens. 😁
Simple curiosité : vous le mettez vous-même en pratique au quotidien ? Si oui, quel type de projet ?
@FloMo
"vous le mettez vous-même en pratique au quotidien ?"
Bien moins aujourd’hui que dans le passé au niveau opérationnel.
Le type de décision que je suis encore amené à prendre professionnellement sur des enjeux de dev sont d’ordre architecturale principalement.
Ce que je produit encore comme code est de l’ordre de la veille technologique bien plus que de la production.
Mais je suis d’une génération qui a produit beaucoup de choses en assembleur, créé des compilateurs, créé des générateurs de code machine en meta-programmation ... particulièrement sur des DSP.
Je ne suis absolument pas dans la position idiote d’opposer bas niveau à haut niveau bien au contraire, mais comprendre ce qui se passe à bas niveau est toujours un vrai avantage, même si l’on ne travaille fort heureusement aujourd’hui quasiment plus qu’avec des langages permettant de manipuler des abstractions complexes et de faire ainsi face à la complexité incroyable des projets.
@YetOneOtherGit
« comprendre ce qui se passe à bas niveau est toujours un vrai avantage »
Complètement d’accord. C’est d’ailleurs un peu frustrant de ne pouvoir approfondir ces sujets.
Mais c’est humainement impossible. Avoir une connaissance de base est envisageable, au-delà c’est de la spécialisation.
Généralement, je profite des opportunités professionnelles pour approfondir les sujets. Mais ça reste ponctuel et c’est un sacré investissement personnel.
@FloMo
"Mais c’est humainement impossible"
c’est totalement possible, juste une question de curiosité, de travail et de volonté.
Un des deux livres que je t’ai donné en référence te donnera de sérieuses fondations.
🧠💪🤓😉🖖
@YetOneOtherGit
La théorie ne m’inquiète pas.
Par contre, la pratique... c’est ça qui prend beaucoup de temps !
Après, rien que pour la culture, c’est intéressant.
@FloMo
"Après, rien que pour la culture, c’est intéressant."
Sur ce type d’enjeux tu peux te contenter de mini-projets ;-)
@FloMo
Et un immense classique dont la lecture vaut toujours la peine :
Le dragon book :
https://en.wikipedia.org/wiki/Compilers:_Principles,_Techniques,_and_Tools
Alfred V. Aho, Monica S. Lam, Ravi Sethi, and Jeffrey D. Ullman
Des monstres 🧠
Pages