Swift Concurrency se prépare à un calcul distribué très prometteur

Florent Morin |

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

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.


avatar Florent Morin | 

@YetOneOtherGit

J’ai testé plein de casques VR. et je comprend bien le soucis avec la latence. Ça se déconnecte du cerveau.

avatar ya2nick | 

@YetOneOtherGit

Justement, un iPad/iPhone qui charge les datas en amont afin d’avoir une latence réduites quand on en a besoin, une sorte de proxy proactif intelligent.

avatar YetOneOtherGit | 

@ya2nick

"Justement, un iPad/iPhone qui charge les datas en amont afin d’avoir une latence réduites quand on en a besoin, une sorte de proxy proactif intelligent."

Justement ? je ne vois pas en quoi un calcul déporté pourrait “qui charge les datas en amont afin d’avoir une latence réduites” 🤔🤔

Tu as conscience que sur de l’AR les mouvements de tête implique un tracking du changement de point de vue en temps réel et un recalcule de la part 3D CGI à superposer dans les délais les plus brefs ?

Je ne vois pas comment ce que tu sembles décrire serait une solution au pb au contraire 🤔🤔

Tu peux expliciter en détail le processus que tu imagines mis en œuvre et comment il pourrait réduire la latence en étant deporté ? 😮

avatar ya2nick | 

@YetOneOtherGit

Je passe sur les Champs Élysée en allant au taf (et pour y aller cool avec la data je suis à pieds), je suis juste a coté de mon taff donc le casque commence a me montrer les rendez-vous, les documents sur lesquels je dois commencer a bosser, je passe pas loin du drugstore, je tourne la tête vers l’Apple store / la Fnac.

Toutes les données liés à ces enseignes, plans / produits / photos / 3d / carte du resto + affiche et bande annonce des films, si elles sont chargés dans l’iPad, pour la latence, en théorie (le wifi 6 suffirait ?) prêtes à être envoyées et présentées dans le casque quand je tourne la tête, et comme l’iPad a un bon neural engine et connais mes habitudes, il chargera peut être plus de data pour le drugstore et la Fnac que pour Dior ou Zara, mais les calculs effectués sur l’iPad, et donc Dior, Zara, la Fnac et le Drugstore ignorent que je les regardes, “sacro-sainte protection des données” d’apple et l’iPad servant de proxy, pas besoin de tout charger à chaque fois, la 5g c’est bien mais c’est pas gratuit et dispo partout.

Ce que je décris est proche du metaver de Meta, proche de ce qu’on peut supposer de ce que proposera apple

Donc avec tout ce que je vient de dire, si en plus apple veux un casque léger et une bonne autonomie, les calculs, le regroupement des datas (je sais plus comment ca s’appelle) doivent être déportés, et rien de mieux qu’un iPhone/iPad.

Je me vois pas faire confiance à Méta pour accéder à ce type de technos, j’aurais déjà plus confiance en apple, mais si les traitements (faut que j’arrête avec le mot calcul) ne sont pas effectués en local (sur le casque ou sur l’iPhone/l’iPad) apple se transformera de facto en copie de facebook pour ce qui est de la collecte de data.

avatar YetOneOtherGit | 

@ya2nick

Ok tu fais de la SF mais tu ne parle pas d’enjeux tech qui visiblement t’échappent un peu 😉

Je comprends pourquoi, je ne comprenais pas tes propos.

Pour faire court : tu te trompes totalement d’enjeux sur ce qui fait la consommation de ressources de calcul lié à l’AR 🤓🖖

avatar ya2nick | 

@YetOneOtherGit

Je fais de la SF ok, en utilisations professionnelles je vois pleins de nouveaux usages et une démocratisation de l’AR, pour le particulier je n’en vois pas beaucoup, je vois mal les gens se balader avec de grosses lunettes sur le nez juste pour avoir un affichage tête haute de son trajet ou pour jouer à Pokémon Go, pour un livreur/chauffeur ok.

Le jour ou je me balade avec ca sur le nez dans la rue, je veux que ca pète et que ce soit instantané, quand je regarde des affiches de cinés je veux les bandes annonces en surimpression, quand je regarde la route je veux mon trajet en surimpression, je regarde le ciel j’ai la météo… et tout ca en simultané, personnalisé… oui, j’attends, et je sais que ce ne sera pas pour tout de suite, une interface / utilisation à la minority report, et voir a travers un monde à la ghost in the shell / blade Runner.

Quels seront les premiers usages de ce type de casques/lunettes pour les particuliers selon vous ? Autre que ce que l’on peut déjà faire en AR avec un iPhone/iPad ?

avatar oomu | 

c'est très bien tout cela

mais comme avec Grand Central, c'est aux développeurs d'en faire quelque chose et de me le proposer.

Moi je suis tout disposé à les payer et les utiliser, si elles existent, ces solutions iphone-mac-distribués-local-etc.

avatar hirtrey | 

Donc apple réinvente le calcul distribué mais avec son logo

avatar YetOneOtherGit | 

@hirtrey

"Donc apple réinvente le calcul distribué mais avec son logo"

Hormis une provocation à deux balles tu veux en venir où ?

Ça apporte quoi d’interessant cette remarque ?

Quelqu’un ici à crié à l’invention disruptive d’Apple ? 🙄🙄🙄🙄

De plus tous cela est en licence Open Appache 2.0

Swift.org n’est pas Apple

avatar fornorst | 

@YetOneOtherGit

C’est très bien que ce soit intégré à Swift mais ça ressemble effectivement aux principes derrière la VM Erlang qui est déjà capable de fonctionner sur plusieurs noeuds distribués avec une mise en avant du modèle acteur. Mais pour être honnête : on invente peu de choses en informatique, on améliore souvent l’existant. Et c’est une excellente chose qu’Apple amène cette mécanique dans un langage plus developer-friendly qu’Erlang 😅

avatar hirtrey | 

@fornorst

Je suis bien d’accord mais lorsqu’il y a le tampon Apple, c’est toujours la révolution, une fantastique invention.

Je peux comprendre l’enthousiasme de l’auteur à l’article mais gardons les pieds sur terre.

avatar fte | 

@fornorst

"plus developer-friendly qu’Erlang 😅"

Il y a Scala. Tu as regardé ? Je le trouve assez friendly.

avatar fornorst | 

@fte

Oui je l’utilise avec Spark pour faire connecteur entre mongodb et BigQuery. C’est effectivement plus agréable à utiliser qu’Erlang mais pas non plus dingue (de mon point de vue). Par contre ça tourne sur la JVM donc ce n’est pas comparable à ce que la VM Erlang peut faire :(

avatar fte | 

@YetOneOtherGit

"Hormis une provocation à deux balles tu veux en venir où ?"

Il veut en venir qu’il existe N frameworks pour cette exacte application, et qu’il en existe maintenant N+1.

avatar YetOneOtherGit | 

@fte

"Il veut en venir qu’il existe N frameworks pour cette exacte application, et qu’il en existe maintenant N+1."

Ça on sait 😎

Cela n’a rien d’atypique justement que de créer une solution de ce type et il n’y a aucune raison de rabaisser la solution sous prétexte que c’est un Yet Another ce qui est on ne peut plus classique en informatique au point d’en être devenu un gag 😉

avatar fte | 

@YetOneOtherGit

"et il n’y a aucune raison de rabaisser la solution"

Je je rabaissais pas, ni l’autre contributeur je pense. Je mettais juste en doute la portée d’une nième solution de ce genre.

avatar YetOneOtherGit | 

@fte

"Je je rabaissais pas"

Pas toi le commentaire initial 😉

avatar YetOneOtherGit | 

@fte

"Je mettais juste en doute la portée d’une nième solution de ce genre."

Tout dépend dans quoi cela s’inscrit.

Si c’est un élément clé d’une prochaine offre ou pas.

Je ne crois pas que ce soit gratuit comme mouvement.

Wait&See 👀

avatar fte | 

Apple réinvente Akka/Scala, lui même fortement inspiré d’Erlang/OTP.

Ouai. Pourquoi pas. Si on se limite au petit verger de la pomme, je suppose que c’est intéressant. Qui se limite encore ainsi ? Pour du distribué qui plus est.

Je sais déjà que j’y porterai un intérêt académique mais que jamais je n’écrirai des lignes de code de production avec cette librairie. Et qu’aucun de mes collègues dans le calcul distribué n’en écrira non plus. 🤷

avatar Florent Morin | 

@fte

En fait, la proposition concerne toutes les plateformes Apple, mais aussi Linux, WASM et potentiellement Windows.

Il faut bien voir ça comme une extension de Concurrency dont l’objectif à terme est d’avoir un « contrat » entre le système et runtime qui stipule que le runtime ne va jamais créer plus de threads qu’il n’y a de coeurs à disposition.

Pour ce faire, il s’agit de gérer tout ça côté langage (exit GCD) et ainsi éviter le surcoût de création de tâches parallèles ainsi que les différentes problématiques de gestion actuelle des tâches concurrentes (threads explosion, data race, etc).

Évidemment, avec des puces Apple Silicon à mémoire unifiée, le fonctionnement est optimal. Mais ça fonctionne aussi sur Linux et autres.

Et là-dessus se greffe le calcul distribué, qui est une optimisation côté langage qui va exploiter la nouvelle syntaxe afin d’éviter les pertes.

Niveau langage, Apple n’invente rien. Niveau runtime, c’est autre chose.

avatar fte | 

@FloMo

"En fait, la proposition concerne toutes les plateformes Apple, mais aussi Linux, WASM et potentiellement Windows."

En théorie.

En pratique, ça ne concerne que l’écosystème Apple. Soyons réalistes.

"Niveau langage, Apple n’invente rien. Niveau runtime, c’est autre chose."

Presque rien.

Blague à part, la question n’est pas d’inventer. On invente pas grand chose en programmation depuis 50 ans. L’outillage est relativement cohérent, et relativement riche. Et il s’enrichît. C’est bien.

Mais soyons réalistes également : la portée est très limitée, écosystème Apple, et la quantité de productions tierces excessivement faible comparativement à des plateformes comme JavaVM ou .NET/CLR, ou encore Python. Ou Go.

C’est classique cependant. N frameworks. N+1 frameworks. Jusqu’à la prochaine mode.

avatar YetOneOtherGit | 

@fte

"Mais soyons réalistes également : la portée est très limitée"

Sauf à se demander pourquoi et pourquoi maintenant ?

Pages

CONNEXION UTILISATEUR