@raoolito

Merci 😁

Au niveau de Swift Concurrency, ça existe dans des langages très spécialisés, notamment ceux utilisés pour les supercalculateurs afin de limiter la perte.

Mais pas dans du générique. En tout cas, ceux que je connais s’appuient en général sur les threads POSIX que tous les Unices connaissent ou leur propre système optimisé (façon Dispatch) qui sera plus performant que les threads POSIX mais aura toujours de la perte.

Aujourd’hui, Swift Concurrency est un frontend à Dispatch. Ça optimise le code des développeurs et ça utilise le backend Dispatch qui est multiplateformes. Ça doit utiliser un autre backend sur Windows d’ailleurs il me semble.

Bref. On peut d’ores et déjà passer à Swift Concurrency. Sachant que Swift 6 sera très exigeant dans son utilisation. Et pour cause.

De ce que j’ai compris des sessions WWDC, Apple travaille à un backend dédié qui exploitera finement les cœurs Apple Silicon. En gros, on élimine le coût de création d’une tâche dans un thread. Et on ne crée pas plus de threads qu’il n’y a de coeurs disponibles. C’est une optimisation rêvée qui pourrait donner un sacré coup de boost tout en limitant un peu la consommation.

Mais ça implique un « contrat runtime » qui dit au système : « OK, mon app est clean et ne va pas créer plus de threads que de cœurs disponibles ».

Et bien sûr, à mon avis, Apple a prévu d’exploiter au maximum la mémoire unifiée pour ça. Ça permettrait potentiellement un partage des données instantané entre tous les composants sur puce : CPU, GPU, NE, etc.

En tout cas, vu les évolutions vers Swift 6 et les petits ajouts qui viennent se greffer ici et là, ça en prend le chemin.