Swift Concurrency se prépare à un calcul distribué très prometteur
L’annonce est passée il y a quelques semaines sur le blog de la communauté Swift et mérite qu’on s’y attarde un peu. Avec Concurrency, le langage s’est enrichi de multiples mécanismes permettant d’optimiser la gestion des tâches parallèles au sein d’une application, notamment grâce au modèle d’acteur. L’objectif de cette nouvelle évolution est de faire travailler les acteurs entre différentes applications et différentes machines.
Swift fait jouer la concurrence pour exploiter la puissance des processeurs Apple
Pour rappel, le mécanisme d’acteur introduit dans Swift 5.5 est le suivant :
- un acteur se présente comme une classe ;
- un acteur effectue des opérations asynchrones ;
- les données de l’acteur sont protégées contre les accès simultanés par plusieurs tâches parallèles.
Si plusieurs tâches parallèles accèdent à la même donnée au même moment, l’application peut planter violemment. Les mécanismes de protection d’accès aux données ont en général tendance à bloquer l’exécution des tâches, tout en étant complexes à gérer. Le nouveau mécanisme introduit par les acteurs résout ce problème.
Cette architecture me paraît parfaite pour développer des applications tournant sur des lunettes de réalité augmentée ayant un SOC faiblard (d’Apple Watch?) qui déléguerait les tâches lourdes de rendering à votre iPhone via Ultra Wide Band (pour faire transiter des images de retour en 4K par Oeil, il faudra de la bande passante).
Cela servira aussi à déléguer les actuateurs détectant les mouvements de votre main à votre Apple Watch. Il y a juste un truc qui me turlupine. Les droitiers devront ils porter leur Apple Watch à la main droite plutôt qu’au poignet gauche, comme c’est le cas usuellement.
@Brice21
Aujourd’hui, Core ML reconnaît très bien une main dans le champs visuel.
https://developer.apple.com/documentation/vision/detecting_hand_poses_with_vision
@FloMo
Oui mais je ne pense pas malin de mettre de la puissance de calcul dans les lunettes (comme sur l’Oculus Quest 2) et envoyer les flux des caméras depuis les lunettes vers l’iPhone prendra beaucoup de bande passante, sans parler du fait qu’il faudra des caméras qui filment vers le bas pour cela (comme sur le Quest) et que cela bouffera les batteries. Hors il est trivial de reconnaître les mouvements de la main, et les pincements de doigts avec un simple bracelet ou une montre.
Article qui a l’air vraiment très intéressant et vraiment prometteur.
Le rédacteur de l’article (qui semble vraiment maîtriser son sujet) à l’air très enthousiasme sur cette évolution, donc je ne peux que lui faire confiance 😋.
Mais c’était trop technique pour moi lol 😋😋!
Ça m’a vite perdue 😊.
Ce que j’ai retenu, c’est que ça va permettre de faire des applications très optimisées pour les processeurs Apple de manière plus facilement pour les développeurs (j’espère que j’ai bon jusque là 😋😅?)
@cecile_aelita
C’est exactement ça.
Swift Concurrency a permis aux développeurs de ne pas se casser la tête pour traiter les tâches en parallèle, ce qui est un sujet complexe.
Avec cette amélioration, c’est l’exécution de tâches entre applications et entre appareils qui est simplifiée : une énorme usine à gaz en temps normal.
Et, comme vous le soulignez, le tout exploite le matériel de façon optimale : meilleures performances, consommation d’énergie moindre.
@FloMo
Cool! bonnes nouvelles pour tout le monde alors 😋:
- les devs qui vont pouvoir faire des meilleures applis plus facilement
- les utilisateurs qui vont avoir des applis qui ne vont pas trop pomper la batterie
- moi qui (malgré mon côté blonde lol 😛) a compris l’essentiel de ton article
- toi qui a réussi à vulgariser un sujet complexe au point que même une blonde a pu le comprendre lol 🤣!
Le dimanche se passe pas trop mal alors 😋😘🤣
@cecile_aelita
"Ce que j’ai retenu, c’est que ça va permettre de faire des applications très optimisées pour les processeurs Apple de manière plus facilement pour les développeurs (j’espère que j’ai bon jusque là 😋😅?)"
Je te parlais l’autre jour de l’historique de l’évolution des architectures vers du parallélisme.
Du côté hardware c’est largement en place mais du côté software il y a beaucoup de défis.
Penser, programmer et maintenir un programme qui “fait plusieurs choses à la fois” est loin d’être une tâche simple pour les dev.
C’est en partie ce qui explique que nombre d’applications ayant des fondations anciennes sous-exploitent le potentiel de traitement parallèle de nos machines actuelles.
Les langages de programmation sont un des outils permettant de rendre ce défis plus facile à relever.
De nombreux langages ont petit à petit adoptés des modèles de programmation simplifiant la confrontation à cette complexité.
Et là s’ajoute des moyens plus simple de distribuer le calcul dans une vision assez moderne et tendance
@YetOneOtherGit
Et oui 😋.
Moi je ne m’arrête qu’à « SCRATCH » pour la programmation! C’est pas glorieux je sais, mais bon, c’est fait pour l’éducation en même temps😊.
@cecile_aelita
"Moi je ne m’arrête qu’à « SCRATCH » pour la programmation! C’est pas glorieux je sais, mais bon, c’est fait pour l’éducation en même temps😊."
Il ne faut pas sous-estimer Scratch. Okay, il y a des limites et contraintes rapidement atteintes. Mais c’est de la programmation. C’est de l’algorithmique. Vraiment. Real deal.
@fte
Bah c’est surtout qu’avec des CE1, tu peux difficilement faire + (et puis même sans mettre la faute sur eux… je ne serais pas capable de faire mieux moi même 😋😋)
@cecile_aelita
Tu as d’autres trucs marrants utilisables pour les premiers apprentissages. Algobox par exemple, ou divers Serious Games. Scratch est un petit cran au dessus. :)
@fte
Ne va pas me chambouler mes habitudes lol !
J’ai déjà bien assez à gérer avec toutes les autres matières !😛
L’algorithmique n’en est qu’une parmi la grosse dizaine que je dois m’occuper 😛😘
@cecile_aelita
" va pas me chambouler mes habitudes lol !"
Rien de tel que de sortir de sa zone de confort pour se renouveler ! Go go go.
@fte
😉😉
@fte
"Go go go."
GoLang en CE1 ? 🤔😄😉
@YetOneOtherGit
Déjà que j’en ai un nombre non négligeable qui ne sont pas encore lecteurs, on va prioriser les choses 😉.
@YetOneOtherGit
"GoLang en CE1 ? 🤔😄😉"
Rhoo, non, pas toi et pas cette erreur. GoLang est le site. Le langage s’appelle Go tout court. 😜
@fte
"Rhoo, non, pas toi et pas cette erreur. GoLang est le site. Le langage s’appelle Go tout court. 😜"
Je sais mais c’était pour que notre camarade comprenne le clin d’œil et le jeu de mot. En faisant juste référence à Go ça me semblait moins évident de comprendre avec une simple recherche 😉
@YetOneOtherGit
Je n’ai pas voulu m’aventurer sur un terrain glissant dans l’article.
Mais on sait que Apple Silicon et sa mémoire unifiée permet d’éviter les coûteuses copies d’éléments en mémoire.
Serait-il possible qu’il en soit de même pour le tampon de la mémoire des composants réseau ? En gros, que le tampon se fasse dans la mémoire unifiée pour éviter la copie. Ce serait alors vraiment optimal.
@FloMo
"Serait-il possible qu’il en soit de même pour le tampon de la mémoire des composants réseau ? En gros, que le tampon se fasse dans la mémoire unifiée pour éviter la copie. Ce serait alors vraiment optimal."
Là j’ai du mal à te suivre, sur du calcul distribuer réseau les données doivent forcément circuler et sortir de la machine.
Tu peux clarifier ton point de vue?
@YetOneOtherGit
Pour moi, le contrôleur réseau a sa propre mémoire tampon (buffer) qu’il valide avant de fournir la donnée au CPU via la RAM.
Si la donnée du contrôleur réseau passait du contrôleur au CPU sans copie grâce au partage d’un espace mémoire commun, ce serait optimal. A l’instar de ce qui est fait entre CPU et GPU qui partagent la même mémoire pour éviter la copie.
Honnêtement, ça fait un moment que je n’ai pas suivi l’évolution des architectures matérielles. D’où mon extrême prudence.
@FloMo
"Honnêtement, ça fait un moment que je n’ai pas suivi l’évolution des architectures matérielles. D’où mon extrême prudence."
Un mouvement de fond actuelle est le travail sur des unités de traitement dédiée au réseau (assez souvent basées sur des architectures ARM), on a sur les serveurs aujourd’hui de vrais co-processeurs dédiés qui montent sur des couches élevées pour le traitement.
Sur les SOC Apple je n’ai pas exploré ce qui a été mis en œuvre.
@YetOneOtherGit
l'idée est de rapprocher toujours plus le réseau du processeur. Le réseau copiant directement dans la mémoire pour le processeur, ou des smartlink faisant toujours plus de traitement réseau. Cela va jusqu'à NVME par dessus tcp et autre nvme-roce.
Je vois des produits ARM se développer pour tout ça, mais je n'ai pas encore bien saisi si ça porte leur fruit, en terme de rapport/qualité prix. J'ai des retours un peu mitigés de la part de collègue.
Je ne crois pas que le rachat de Mellanox et ARM (c'est finalisé ça d'ailleurs?) par Nvidia a donné lieu à une nouvelle génération de produits pour le moment.
@oomu
"l'idée est de rapprocher toujours plus le réseau du processeur. Le réseau copiant directement dans la mémoire pour le processeur, ou des smartlink faisant toujours plus de traitement réseau. Cela va jusqu'à NVME par dessus tcp et autre nvme-roce.
Je vois des produits ARM se développer pour tout ça, mais je n'ai pas encore bien saisi si ça porte leur fruit, en terme de rapport/qualité prix. J'ai des retours un peu mitigés de la part de collègue.
Je ne crois pas que le rachat de Mellanox et ARM (c'est finalisé ça d'ailleurs?) par Nvidia a donné lieu à une nouvelle génération de produits pour le moment."
C’est un secteur qui bouge pas mal côté serveur mais effectivement les évolutions dont nous avions parlé ensemble lors de l’annonce du rachat d’ARM par NVidia, tardent à sortir.
Cela dit il y a déjà eu de grandes évolutions sur ce qui est aujourd’hui pris en charge par des coprocesseur réseaux sur les serveurs.
Mais comme souvent il y a loin de la coupe aux lèvres en matière de promesses technologiques 😉
@oomu
L’Europe a lancé une enquête sur le rachat d’ARM récemment. C’est loin d’être finalisé du coup.
@FloMo
Je viens de vérifier le contrôleur réseau est bien externe au SOC et communique en PCIe
@YetOneOtherGit
Merci !
@FloMo
"Merci !"
Vu la part des machines Apple ayant seulement une connectivité Wifi cela laisse peu de place pour les approches agressives du traitement réseau de toutes façon.
@YetOneOtherGit
Certes. Mais sur du Mac mini / Mac Pro serveur, pourquoi pas.
@FloMo
"Mac Pro serveur"
Un Mac Pro Server ? 🤔
Tu y crois, toi ?
@YetOneOtherGit
"Tu y crois, toi ?"
Non. Vu la grosse blague qu’est devenu macOS Server, pas une seule seconde.
@YetOneOtherGit
"Vu la part des machines Apple ayant seulement une connectivité Wifi"
Thunderbolt - Ethernet. Ils ne peuvent pas avoir oublié cette option !
Mvouais. Si. Ils peuvent.
@fte
"Thunderbolt - Ethernet. Ils ne peuvent pas avoir oublié cette option !"
Effectivement, d’autant qu’Ethernet Over TB fonctionne plutôt bien aussi
@YetOneOtherGit
"Je viens de vérifier le contrôleur réseau est bien externe au SOC et communique en PCIe"
Ce qui n’interdit pas le DMA, sur le papier. Ça dépend de l’implémentation d’Apple, matérielle et logicielle. Je serais époustouflé si ce n’était pas le cas.
@fte
"Ce qui n’interdit pas le DMA, sur le papier. Ça dépend de l’implémentation d’Apple, matérielle et logicielle. Je serais époustouflé si ce n’était pas le cas."
Effectivement il y a de grandes chances que ce soit en DMA mais notre camarade voulait savoir si c’était intégré au SOC 😉
@FloMo
Je ne trompe ou tu réinventes le DMA ?
Je l’avais déjà souligné, mais la "mémoire unifiée" ou ici le DMA n’ont rien d’innovant ou de spécifique à la Pomme.
S’il fallait espérer quelque chose (je suis si peu concerné que soyons honnête je m’en fiche complètement), c’est une implémentation d’un équivalent de la mémoire virtuelle unifiée proposée par CUDA par exemple.
Bonjour, merci de cette explication.
Mais il y a un truc qui m'obsède, la sécurité et la privatisation de la data. Si on reprend votre idée d'application photo qui fait travailler à distance les photos, est-ce que un tiers Apple ou autres peut accéder aux images? Car Apple nous parler de vérifier les photos sur les mobiles à discance. Est-ce que cette fonction ne ferrait pas la même chose aussi? Car si je suis Michelin, ou un autre, je voudrais pas qu'un tiers ou état étranger puisse accéder à mes data.
@morpheusz63
La sécurité est un autre sujet. Et il n’est en rien opposé aux performances.
Ici, on pourrait chiffrer les données de bout-en-bout (via Chacha20-Poly1305 pour les performances), on aurait le même résultat.
L’avantage est que l’équipe sécurité pourrait mettre en place les mécanismes sous-jacents. Il y aurait moins de risque pour que l’équipe principale face une erreur qui ouvre une faille de sécurité.
Au moins sur Swift ils autorisent la concurrence, au contraire de l'App Store 🥁.
Intéressant !
Est-ce que le sens de partage des données est défini (comme dans l’exemple, de l’iPhone vers le mac) ou est-ce que potentiellement, n’importe quel device peut être considéré comme un nouveau processeur dans le réseau (et ainsi profiter de la puissance de calcul supplémentaire d’un iPhone, ipad, Apple Watch ou autre pour un calcul démarre sur un Mac, et ainsi constituer une sorte de ferme de calcul local et hétérogène pour des besoins ponctuels)?
@mne
Ça fonctionnerait potentiellement entre appareils Apple, mais aussi Linux ou même dans un navigateur web via WASM.
En extrapolant, je me balade avec les lunettes Apple, j’ai une surcouche AR «Light», si j’ai l’iPhone dans la poche la surcouche est plus jolie, si je me trimbale avec l’iPad pro je me crois dans minority report et si je suis chez moi avec l’iMac/MacBook/Mac Pro je suis dans ready player one ?
@ya2nick
C’est ça. Sauf que d’ici peu, je pense que les iPhone auront la puissance des M1 de 2020.
@FloMo
"C’est ça. Sauf que d’ici peu, je pense que les iPhone auront la puissance des M1 de 2020."
Il faut quand même relativiser la possibilité de ce type de calcul distribués sur des approches Temps Réel comme l’AR où la latence est une clé de l’efficacité.
@YetOneOtherGit
Si le dispositif est capable d’afficher de la 3D, le volume de données est limité. Sur le M1, le ratio de compression pour les textures 3D est de x10.
@FloMo
"Si le dispositif est capable d’afficher de la 3D, le volume de données est limité. Sur le M1, le ratio de compression pour les textures 3D est de x10."
Je ne parle pas de streaming de la vidéo, mais de distribution du calcul 😉
Et la latence est bien plus pénalisante que les enjeux de BP sur du temps réel plus encore en AR où pour que la sensation d’hybridation virtuelle/ réelle soit efficace il faut une latence très réduite 😉
@YetOneOtherGit
En AR, c’est moins critique qu’en VR.
Après, je pense que le problème va surtout de poser au niveau autonomie.
@FloMo
"En AR, c’est moins critique qu’en VR."
Nope sur des dispositifs de type casque c’est absolument essentiel, le moindre décalage temporel entre un mouvement de tête et l’adaptation de la 3D superposée est rédhibitoire.
C’est très différent de l’AR au travers d’un smartphone ou d’une tablette 😉
@YetOneOtherGit
Remarque, j’ai jamais testé avec un casque. Du moins, seulement avec de la vidéo, mais c’est plus ou moins de la VR.
@FloMo
"Remarque, j’ai jamais testé avec un casque"
Tu comprends le pb conceptuellement même si tu ne l’as jamais éprouvé?
S’il y a une latence entre les mouvements de tête et le recalcule de la 3D pour le nouveau point de vue: c’est mort 😉
Pages