L'équipe de développement de Julia a publié la première version admissible de Julia 1.7 en octobre de cette année. Un mois plus tard, les responsables du langage Julia ont annoncé la disponibilité de Julia 1.7. « Après 4 betas et 3 release candidates, la version 1.7 de Julia est enfin disponible. Nous voudrions remercier tous les contributeurs à cette version (plus de 79 personnes) et tous les testeurs qui ont aidé à trouver les régressions et les problèmes dans les préversions », a déclaré l’équipe de développement du langage. Cette version corrige les erreurs de synchronisation, affine le support de l'ordonnancement des charges de travail sur plusieurs threads, rend le générateur de nombres aléatoires par défaut plus convivial pour les threads, et ajouté les atomiques comme caractéristique du langage primitif.Julia est un langage de programmation open source et un écosystème pour le calcul scientifique de haute performance. Conçu par des chercheurs du MIT en 2009 et dévoilé pour la première fois au grand public en 2012, il est doté d’une syntaxe familière aux utilisateurs d'autres environnements de développement similaires. Julia connaît une croissance fulgurante depuis sa sortie et certains vont même jusqu’à dire qu’il s’agit du langage idéal pour le calcul scientifique, la science des données et les projets de recherche. Le langage s'est popularisé lorsque le projet est devenu open source en 2012. Il est actuellement disponible sous licence MIT.
À la base, ses concepteurs voulaient un langage avec une licence libre et renfermant de nombreux avantages surtout pour la communauté scientifique. « Nous voulons un langage open source, avec une licence libre. Nous voulons un langage qui associe la rapidité de C et le dynamisme de Ruby. En fait, nous voulons un langage homoïconique, avec de vraies macros comme Lisp et avec une notation mathématique évidente et familière comme MATLAB. Nous voulons quelque chose d’aussi utilisable pour la programmation générale que Python, aussi facile pour les statistiques que R, aussi naturel pour la gestion de chaîne de caractères que Perl, aussi puissant pour l’algèbre linéaire que Matlab et aussi bien pour lier des programmes que le shell. Nous voulons qu’il soit à la fois interactif et compilé », avaient-ils déclaré en 2012.
La plupart des versions de Julia sont programmées dans le temps et ne sont donc pas planifiées autour de fonctionnalités spécifiques. Voici, ci-dessous, quelques améliorations apportées à Julia dans la version 1.7 :
Générateur de nombres aléatoires par défaut
Depuis sa toute première version, Julia utilisait le populaire algorithme Mersenne Twister comme générateur de nombres aléatoires par défaut. « Nous savions que nous devions réévaluer ce choix à un moment donné, mais cela ne semblait pas particulièrement urgent jusqu'à ce que le programmeur Chet Hega nous fasse remarquer qu'en changeant d'algorithme nous pouvions non seulement obtenir une accélération significative, mais aussi rendre les flux de nombres aléatoires reproductibles dans les programmes multithreads », révèle l’équipe de développement de Julia.
Développé par Makoto Matsumoto et Takuji Nishimura en 1997, l’algorithme Mersenne Twister (MT) est basé sur un twisted generalised shift feedback register (TGSFR), un type particulier de registre à décalage et rétroaction et tient son nom d’un nombre premier de Mersenne. Il existe au moins deux variantes majeures, la plus répandue étant MT 19937, utilisant le nombre premier de Mersenne 219937-1 et présente les propriétés suivantes :
- sa période est de 219937-1 ;
- il est plus rapide que la plupart des autres générateurs ;
- il est uniformément distribué sur un grand nombre de dimensions (623 pour les nombres de 32 bits) ;
- il est aléatoire quel que soit le poids du bit considéré, suivant les tests Diehard, mais échoue systématiquement sur deux des tests BigCrush de TestU01.
Mersenne Twister est célèbre pour avoir une période exceptionnellement longue (219937-1), mais cela nécessite un état de taille correspondante, et n'est pas vraiment nécessaire pour toute application pratique. L’équipe Julia a également utilisé des états de générateur de nombres aléatoires locaux pour la sécurité des threads, ce qui apporte un peu de surcharge et rend les flux aléatoires dépendants de la planification des tâches.
La proposition de Chet a profité de l'état beaucoup plus petit de la famille Xoshiro256 des de générateurs de nombres aléatoires pour mettre un état dans chaque tâche, et le forker à chaque création de tâche. Ainsi, les nombres aléatoires ne dépendent que de la structure de création des tâches d'un programme, et non du programme d'exécution parallèle. « Il a fallu un peu de débat pour que nous soyons tous à l'aise avec l'idée de dépenser de précieux octets d'objets Task de cette manière, mais nous sommes de grands fans de la reproductibilité et la proposition a donc été finalement adoptée », souligne L’équipe de développement de Julia.
Gestionnaire de paquets
Avec la version 1.7 de Julia, si un paquet existe dans un registre mais n'est pas installé, une installation automatique est maintenant proposée lorsqu'un chargement de paquet est tenté dans le shell interactif de niveau supérieur ou de langage. Voici, cidessous, quelques paquets dans l'écosystème construire sur cette fondation pour fournir des abstractions thread-safe :
- tkf/ThreadsX.jl : Des versions parallélisées de certaines fonctions de Base ;
- JuliaConcurrent/ConcurrentCollections.jl : files d'attente et dictionnaires pour l'état partagé ;
- JuliaActors/Actors.jl : des modèles pour rendre la concurrence facile à comprendre et à raisonner ;
- JuliaFolds/FLoops.jl : génère une itération séquentielle et parallèle générique rapide sur des collections complexes ;
- JuliaFolds/Transducers.jl : parallélismes basés sur les threads (foldxt) et les processus (foldxd) avec la même API composable ; i.e. les transducteurs.
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | julia> using Foo
ERROR: ArgumentError: Package Foo not found in current path:
- Run `import Pkg; Pkg.add("Foo")` to install the Foo package.
Stacktrace:
[1] require(into::Module, mod::Symbol)
@ Base ./loading.jl:871
(@1.6) pkg> add Foo
...
julia> using Foo
julia> Foo
Foo |
peut désormais être réalisé avec seulement
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 | julia> using Foo │ Package Foo not found, but a package named Foo is available from a registry. │ Install package? │ (@v1.7) pkg> add Foo └ (y/n) [y]: y ... julia> Foo Foo |
Par défaut, le paquet sera installé dans l'environnement actif actuel, sélectionné par y ou par une simple pression sur la touche retour.
Nouveau format de manifeste
Chaque fois qu'un utilisateur ajoute un paquetage dans Julia, le gestionnaire de paquetage (Pkg) écrit un fichier TOML appelé manifest avec la version exacte de toutes les dépendances de ce paquetage. Différentes versions de paquetage peuvent être compatibles avec différentes versions de Julia et la sortie du resolver(l'algorithme qui calcule un ensemble de versions compatibles pour tous les paquetages et dépendances dans le projet) dépend donc de la version de Julia. Il n'est donc pas recommandé d'utiliser un manifeste créé dans une version de Julia avec une autre version de Julia. Il serait pratique que Pkg puisse vous avertir lorsque cela se produit.
Afin d'émettre un tel avertissement, Pkg aurait besoin de savoir quelle version de Julia a généré un manifeste donné. Cependant, le format actuel (ou schéma) du manifeste rend difficile l'ajout d'une telle information. La raison en est que le format est tel que les clés de premier niveau dans le fichier TOML sont les noms des paquets des dépendances. Cela signifie qu'il n'y a pas de place pour ajouter quelque chose comme une entrée julia_version. Bien sûr, il serait possible de créer une entrée spéciale avec ce nom (en supposant que personne ne nommera un paquet exactement julia_version) mais il serait beaucoup plus agréable de ne pas avoir la même entrée "structurelle" faisant référence à deux choses complètement différentes.
Dans la version 1.7, le format du manifeste a été modifié afin que toutes les dépendances soient placées sous une clé [deps] commune. Cela libère l'espace de nom global pour permettre l'ajout d'une entrée julia_version. Cela ouvre également la possibilité d'ajouter de futures données utiles au manifeste. Pkg conservera également le format d'un manifeste existant, de sorte que seuls les nouveaux manifestes auront le nouveau format de manifeste à l'avenir.
Amélioration des performances pour la gestion des registres sur Windows et les systèmes de fichiers distribués
Suite à quelques plaintes concernant la vitesse du gestionnaire de paquets Julia (Pkg) sous Windows et sur les systèmes de fichiers réseau (NFS), l’équipe de développement à améliorer la situation dans Julia 1.7. Ce qui est commun entre ces systèmes est que ce sont des systèmes où les opérations sur les fichiers ont tendance à être significativement plus coûteuses.
Le registre général est le registre par défaut que Pkg utilise pour rechercher des informations sur les paquets. Il est structuré de telle sorte que chaque paquet a quatre fichiers TOML différents. Au moment de la rédaction de cet article, le registre général contient 5761 paquets, ce qui signifie qu'il contient environ 23 000 fichiers. Il y a deux façons pour Pkg d'obtenir des mises à jour pour un registre, soit via le protocole git, soit via HTTPS en utilisant Pkg Server, qui est un moyen communautaire d'héberger des paquets et des registres où le registre est téléchargé sous la forme d'une archive compressée.
Selon certains rapports, sous Windows, le téléchargement initial du registre général prendrait plusieurs minutes, alors que sous Linux et macOS, il ne prend que quelques secondes. La cause principale de ce ralentissement a été diagnostiquée comme étant Windows Defender, qui provoque des ralentissements lors de la fermeture des fichiers, ce qui est très difficile lors de l'extraction de 23 000 petits fichiers. Selon l’équipe Julia, la communauté Rust serait confrontée à un problème similaire lorsqu'il s'agit de décompresser sa documentation.
Étant donné que Julia est fournie avec p7zip et avec la bibliothèque standard Tar.jl, au lieu d'utiliser un pool de threads pour accélérer la fermeture des fichiers, l’équipe a décidé de prendre une autre voie. Il est possible de lire directement le fichier compressé en mémoire sans matérialiser aucun fichier. En faisant cela, le problème de la matérialisation des fichiers est oublié ce qui améliore significativement les performances du registre sous Windows, NFS et autres systèmes de fichiers distribués comme ceux typiquement utilisés dans les systèmes HPC.
À titre d'exemple, voici, l'effet sur un système propre lors de l'installation du paquetage Example à partir de zéro. D'abord, avec les anciennes méthodes de décompression de tous les fichiers (~30 secondes) :...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
