La réalité augmentée dans le viseur de Swift 6 ?
Avec une trajectoire de plus en plus claire et un objectif de finalisation pour cette année, Swift 6 pourrait bien arriver avec une des versions d'iOS 17. Si l’essentiel des améliorations côté syntaxe a déjà été progressivement apporté avec les versions successives de Swift 5, le véritable bond en avant devrait se situer au niveau du code exécutable, avec un bénéfice majeur au service (entre autres) de la réalité augmentée. Explications.
Prenons d’abord en considération les contraintes pour une expérience de réalité augmentée réussie. Il faut analyser l’image en temps réel et y incruster du contenu virtuel instantanément. Cela nécessite des puces rapides qui communiquent bien entre elles. Il faut également une analyse précise, ce qui implique d’utiliser des capteurs précis tels qu'un LiDAR. Ce dernier va représenter l’environnement réel sous forme d’un nuage de points. Il faudrait donc que les données du LiDAR et de l’analyse d’image se croisent à un moment donné pour un résultat optimal. Et, de préférence, il faut mieux que ces données soient au plus proche de ce que voit l’utilisateur à l’instant T. Un décalage dans l’affichage peut facilement ruiner l’expérience.
Au niveau du matériel, on sait qu’Apple maîtrise son sujet avec les puces M1 et M2. La mémoire est partagée, sans copie, entre le CPU, GPU, le moteur neuronal et les différents capteurs. On ne peut guère aller plus vite dans le traitement de l’information. Ces puces disposent de nombreux cœurs qui peuvent travailler de concert. Mais comme on dit : sans maîtrise, la puissance n’est rien. Avec du bon matériel, il faut un bon logiciel. Surtout quand on a des contraintes aussi fortes que celles évoquées précédemment.
Ça tombe bien, avec ces nouveaux MacBook Pro et leurs puces M2 , on va avoir tout ce qu’il nous faut pour bien développer ! 🤗
“… avec un objectif de finalisation durant cette année…”
Certainement pas, d’après un membre de la core team (réponse donnée au cours d’une discussion sur le forum): https://forums.swift.org/t/design-priorities-for-the-swift-6-language-mode/62408/15
@6ix
Les spécifications dans l’année.
C’est vrai que passé la threat, c’est la cavalerie qui débarque, dès le lancement d’un sémaphore … Menfin ! Ça fait des dizaines d’années qu’on connaît le biais, d’où l’avènement des systèmes temps-réel, Rongtudjuuu ! Ça reste difficile à comprendre pour les faiseurs chez Apple où bien ?
À leur décharge, les systèmes étaient rarement sécurisés en interne, tout en restant ouvert vers l’extérieur … en gardant la même réactivité !
Cependant, l’architecture à (co)processeur à mémoire partagée, est bien arrivée en même temps que les premiers Mac !
@fleeBubl
La mémoire partagée est assez ancienne en effet. Mais la mémoire partagée unifiée sur des SoC, c’est beaucoup plus récent. Et c’est ce qui permet de ne pas avoir à copier l’information en mémoire : CPU et GPU travaillent sur la même donnée.
Le protocole Sendable, interprété au niveau runtime, permet de s’affranchir des contrôles sur cette donnée partagée. Pas de contrôles : gain de performances.
Et niveau tâches concurrentes, ca n’a rien à voir avec les anciens threads POSIX. Il y a un contrat runtime qui permet de s’affranchir des contrôles. Le système ne va pas créer plus de threads qu’il n’y a de coeurs CPU. La création d’une tâche dans un thread ne coûte pas plus qu’un appel de fonction. Il y a aussi le système de priorité de tâches que l’on a connu avec GCD et qui permet d’exploiter au mieux les différents coeurs CPU (performance / basse conso). Et il n’y a plus de système de lock à proprement parler. C’est géré va des actors au niveau du langage qui lui-même est directement imbriqué au niveau de LLVM, pas via une surcouche logicielle.
On est très loin de la gestion « à la main » qui existait jusqu’à récemment. Tout se joue au niveau du compilateur qui va non seulement faire le boulot côté frontend en optimisant le code du développeur, mais surtout côté backend en se plaçant au plus proche du matériel.
@FloMo
Merci pour toutes ces bonnes descriptions.
(À SUIVRE)