Discussion :

[dourouc05]

Julia est un langage de programmation qui cherche à apporter la facilité d'utilisation des langages dynamiques (comme Python ou Ruby) à la performance de langages comme C, C++ ou Fortran. Cela semble marcher, vu que le langage gagne des places dans des classements comme TIOBE ou en comptant le nombre d'étoiles du dépôt sur GitHub.

La version 1.2 n'est pas encore finalisée (on en est actuellement à la RC 2), mais la 1.3 commence d'ores et déjà à pointer le bout de son nez. Les nouveautés syntaxiques sont très limitées : le nouveau caractère d'Unicode 12.1 est utilisable (il représente la nouvelle dynastie japonaise, suite à l'abdication de l'empereur Akihito) ; plus important, on peut ajouter des méthodes à des types abstraits. Ainsi, on peut rendre un type abstrait appelable comme une fonction (auparavant, on ne pouvait le faire que sur des types concrets).

Au niveau du parallélisme, la bibliothèque standard fait de gros progrès. Toutes les opérations d'entrée-sortie sont sûres en contexte multifil, que ce soit sur des fichiers ou des sockets réseau, à l'exception des opérations d'entrée-sortie effectuées en mémoire (comme IOBuffer, même si BufferStream est sûr). La même propriété a été apportée au générateur global de nombres aléatoires. La macro @spawn peut s'utiliser pour exécuter une tâche sur un fil d'exécution disponible, même si elle est marquée comme expérimentale.

Source : notes de versions.

Voir aussi :

Gen, un langage probabiliste universel dans Julia, il ambitionne de faciliter l'utilisation d'intelligence artificielle pour tous
Mozilla finance un portage de Julia en WebAssembly, afin d'effectuer des calculs lourds au sein du navigateur
Julia dispose désormais de deux moteurs de débogage, Debugger.jl et Rebugger.jl, disponibles depuis l'EDI Juno

[wolinn]

Ca fait quelques mois que je joue avec Julia, et je n'ai pas eu trop de mal à atteindre des performances comparables au C++ dans mes applications typiques (alors que dans d'autres langages évalués, je n'y suis jamais arrivé, ce qui était éliminatoire).
Même si je ne suis pas encore prêt à l'utiliser pour des applications pérennes, globalement les caractéristiques techniques et performances sont bonnes pour mes applications scientifiques, donc je continue à investir sur ce langage.
Dans le détail : pour la gestion de la mémoire, je ne suis pas vraiment adepte des ramasse-miettes automatiques, mais pour l'instant, sur de petites applications, cette caractéristique ne m'a pas trop gêné.

[dourouc05]

Lors de la sortie de la première préversion de Julia 1.3, les développeurs se sont montrés fort peu diserts en ce qui concerne les vraies fonctionnalités qui sont arrivées. Les notes de version montraient principalement qu'une très bonne partie de la bibliothèque standard était sûre dans un contexte multifil, mais la vraie bonne nouvelle est que Julia gère désormais le multifil comme prévu dès le début de la conception du langage (l'objet Task était disponible bien avant la première version publique de Julia). Tous les outils nécessaires pour effectuer des calculs à très grande échelle sont donc disponibles : avec plusieurs processus, de manière distribuée sur un réseau, sur des cartes graphiques, mais aussi avec plusieurs fils d'exécution dans un même processus (la documentation n'est pas encore vraiment à jour).

En quoi consiste donc cette nouvelle fonctionnalité ? Julia implémente une forme de parallélisme de tâches : tout morceau de code peut être marqué comme parallélisable ; lors de son exécution, il est lancé dans un autre fil d'exécution. Un ordonnanceur dynamique gère l'exécution de tous ces fils d'exécution. Par exemple, ce morceau de code calcule la suite de Fibonacci de manière récursive et très inefficace, mais surtout sur autant de processeurs que l'on souhaite (si on demande un élément suffisamment éloigné dans la suite) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
import Base.Threads.@spawn
 
function fib(n::Int)
    if n < 2
        return n
    end
    t = @spawn fib(n - 2)
    return fib(n - 1) + fetch(t)
end

La chose importante à remarquer est @spawn : cette commande permet de lancer un bout de code sur un autre fil d'exécution. Le résultat n'est pas immédiatement retourné, mais bien une référence qui permet de le récupérer une fois qu'il est disponible (à travers fetch).

Derrière, l'ordonnanceur fait en sorte que l'exécution soit la plus efficace possible, peu importe le nombre de tâches qu'on lui demande d'exécuter. Il est prévu pour monter à plusieurs millions de tâches à effectuer, de telle sorte que le programmeur est vraiment libéré de tous les détails pratiques (lancer, synchroniser des fils d'exécution). L'implémentation fonctionne aussi de manière composante : à l'intérieur d'une tâche exécutée en parallèle, on peut appeler des fonctions qui, elles-mêmes, font appel à des tâches parallèles. Toutes ces tâches sont ordonnancées de manière efficace, de telle sorte qu'on ne doive pas se demander comment chaque fonction est codée.

Jusqu'à présent, en Julia, quand on appelait une fonction qui pouvait exploiter une forme de parallélisme à l'intérieur d'une section parallèle, on pouvait très vite remarquer une dégradation de la performance. L'explication est un conflit de ressources (oversubscription) : l'application veut se lancer sur bien plus de cœurs que disponible. Par exemple, sur un ordinateur à quatre cœurs, on divise un gros problème en quatre morceaux équivalents, chacun devant résoudre un gros système linéaire : cette dernière opération peut également se paralléliser de manière efficace ; jusqu'à présent, avec Julia (ou OpenMP, ou encore bon nombre d'autres environnements de programmation parallèles), seize fils d'exécution se chargent de résoudre quatre systèmes linéaires — sur quatre cœurs. Pour améliorer les temps de calcul, il vaut mieux alors désactiver le parallélisme au niveau des systèmes linéaires ! Le nouveau système, entièrement composable, gère ces situations en ne laissant que quatre fils s'exécuter en même temps.

Julia dispose aussi d'une série d'outils bien pratiques : des sémaphores, des verrous, du stockage par fil d'exécution (notamment utilisé pour la génération de nombres aléatoires : chaque fil dispose de son propre objet RNG).

En coulisses, ce système n'est pas d'une simplicité déconcertante à gérer. Les tâches de Julia ne sont pas implémentées de la même manière pour chaque système d'exploitation : Windows dispose de fibres, conceptuellement très proches, mais pas Linux (certaines bibliothèques implémentent ce genre de mécanisme, cependant). Chaque tâche nécessite sa propre pile d'appels de fonction pour gérer l'exécution, mais elle doit être gérée de manière particulière : le système d'exploitation se charge d'énormément de choses pour passer l'exécution d'un fil à l'autre, mais, en ce qui concerne les tâches, les applications doivent implémenter beaucoup de choses elles-mêmes. Pour le moment, Julia considère qu'une tâche ne peut s'exécuter que dans un seul fil d'exécution, sans possibilité de passer sur un autre fil pour mieux exploiter le processeur, mais cela arrivera dans le futur.

L'implémentation actuelle est complète d'un point de vue Julia, mais a une limitation majeure : les bibliothèques appelées par Julia (par exemple, pour la résolution de systèmes linéaires) sont écrites en C et ne gèrent pas nativement cette forme de parallélisme. Ce sera corrigé dans une version à venir. L'API n'est pas encore définitive et pourrait légèrement évoluer avant d'être entièrement stabilisée. La gestion des entrées-sorties n'est pas encore au point : un verrou global est imposé sur ces opérations, mais cela devrait changer. Une fois ces éléments améliorés, la bibliothèque standard pourrait commencer à exploiter le parallélisme de tâches de manière interne, par exemple pour trier des tableaux suffisamment grands.

Source : Announcing composable multi-threaded parallelism in Julia.

[Matthieu76]

J'ai à peine lu le titre que ça m'a donné mal au crâne

[dourouc05]

La première RC de Julia 1.3 vient de sortir. En réalité, la dénomination RC est un peu trompeuse, surtout qu'il n'y a pas eu de préversion Beta entre les deux : en fait, cette RC 1 devrait plutôt être considérée comme Beta. La version finale de Julia 1.3 n'est pas attendue avant plusieurs mois, pendant lesquels l'implémentation du langage et sa bibliothèque standard gagneront en maturité (mais pas en fonctionnalités) : depuis la première préversion, on compte presque cent soixante modifications !

Télécharger Julia 1.3 RC 1.

[dourouc05]

Voici venue la deuxième RC de Julia 1.3. Celle-ci n'est pas encore considérée comme proche d'une RC, mais plutôt d'une Beta, au niveau de sa stabilité : aucune fonctionnalité ne sera ajoutée à Julia 1.3, mais les développeurs souhaitent encore bénéficier de quelques mois pour stabiliser cette version, c'est-à-dire éliminer les défauts qu'elle contient encore. Par rapport à la RC 1, la RC 2 contient trente-huit changements, très peu concernant les nouvelles possibilités de parallélisme ajoutées à Julia 1.3. Trois supplémentaires sont d'ores et déjà prévus pour la RC 3.

Télécharger Julia 1.3 RC 2.

[dourouc05]

Julia est un langage de programmation cherchant à allier les avantages des langages dynamiques pour l'écriture facile de code et ceux des langages statiques en ce qui concerne la performance. Force est de constater qu'il y arrive raisonnablement bien, mais il manquait jusqu'il y a peu une bonne implémentation de l'exécution sur plusieurs fils d'exécution. Notamment, bon nombre d'objets de base ne géraient pas correctement les appels depuis plusieurs fils d'exécution. Julia 1.3 apporte une première implémentation complète des désirs des développeurs, notamment avec un ordonnanceur de fils d'exécution. Cela permet que chaque bibliothèque prévoie son exécution en parallèle, peu importe la manière dont l'utilisateur l'appellera (en parallèle ou pas) : Julia se charge d'ordonnancer les fils d'exécution pour garantir une performance maximale (plus de détails dans le reste du dossier).

Il reste encore du travail sur la planche au niveau de la performance. Plus précisément, la latence sera un des sujets prioritaires pour Julia 1.4. L'un des problèmes majeurs de Julia est le temps de démarrage de l'environnement, mais aussi la première exécution de certaines fonctions (le cas le plus courant était le paquet Plots.jl). La version de développement actuelle permet déjà de diviser par quatre le temps pour générer le premier graphique (qui passe sous les deux à trois secondes dans la majorité des cas).

Les binaires de Julia 1.3 ne sont pas encore disponibles, mais cela ne devrait pas trop tarder.

Voir le dépôt GitHub de Julia.

[Invité]

Pour les gens normaux, qui sont plus proches de l'informatique que de l'académie française, il s'agit là de parallélisme SMP, à base de threads donc. Julia supportait déjà le parallélisme à base de processus mais pas vraiment le SMP. Avec l'évolution de la lib graphique, cette version de Julia est effectivement très attendue dans la communauté. Merci beaucoup pour cet article qui traduit très bien ça.