Les fonctionnalités de Julia 1.0 seront arrêtées le 15 décembre

Julia est un langage de programmation de haut niveau, dynamique, mais orienté applications de haute performance (surtout pour le calcul scientifique). Malgré son jeune âge (il est apparu pour la première fois au grand public en 2012), il a déjà réussi à fédérer une certaine communauté (on estime à 250 000 son nombre d’utilisateurs en 2017).

Il s’apprête à voir sa première version finale, numérotée 1.0, après de longues années de développement. Toutes les fonctionnalités ne sont pas encore implémentées, mais cela ne devrait tarder : plus aucune ne sera acceptée dès le 15 décembre. À cette date, la première préversion Alpha de la 0.7 sera disponible, six mois après la 0.6. Julia 0.7 et 1.0 devraient être disponibles dans deux mois, si tout va bien.

Bon nombre d’évolutions attendues font leur apparition, comme la macro @isdefined pour déterminer si une variable locale existe ou encore un conteneur de type dictionnaire pour les arguments passés par nom à une fonction (en réalité, des tuples nommés, une autre nouveauté). Les valeurs manquantes, très utilisées en science des données, font leur apparition au sein même du langage (auparavant, elles l’étaient dans les paquets qui en avaient besoin). La macro @nospecialize est utilisée pour indiquer que le compilateur ne peut pas spécialiser une fonction sur le type d’un argument.

Certaines constructions peu lisibles ne sont plus acceptées dans le langage : 1.+2 pouvait être compris comme la somme d’un nombre à virgule flottante (1.) et d’un réel (2) ou bien comme la somme élément par élément entre listes (d’un côté, 1, de l’autre, 2 : 1 .+ 2) ; la juxtaposition de nombres en notation binaire, octale et hexadécimale ne pouvait être qu’illisible (0xapi était compris comme 0xa * pi). La bibliothèque standard a été considérablement allégée, en suivant un mouvement lancé depuis belle lurette : les fonctionnalités moins souvent utilisées (ou qui mériteraient d’être mises à jour plus souvent que le compilateur) ont été déplacées dans des paquets.

La sortie de la version 1.0 se fera en deux temps : tout d’abord, la version 0.7, qui aura exactement les mêmes fonctionnalités, mais avec des avertissements pour ceux qui utiliseraient d’anciennes syntaxes maintenant déconseillées ou supprimées ; très rapidement après, la 1.0, expurgée de ces messages. Ainsi, il sera conseillé de migrer son code vers la version 0.7 pour profiter des messages d’avertissement plus nombreux ; ensuite, le passage à la 1.0 se fera instantanément. Pour les nouveaux, par contre, seule la version 1.0 sera mise en avant.

Toutes les fonctionnalités souhaitées pour Julia 1.0 ne sont pas encore implémentées, toutefois. Si les développeurs ont le temps, tout ce qui sera possible sera implémenté d’ici au 15 décembre, pour laisser le temps aux tests avant la version finale. Les autres fonctionnalités seront ajoutées lors du cycle de vie de Julia 1.x, quitte à laisser des syntaxes indésirables acceptées : elles ne seront supprimées que lors du passage à Julia 2.0.

Voir aussi : la liste des changements apportés jusqu’à présent à Julia 0.7.0.

Source : 1.0 Feature Freeze Dec 15th.

Advertisements

Zinc : Scala se met à la compilation rapide

Ces derniers temps, Scala a vu quelques améliorations notables dans ses outils de compilation. Notamment, le compilateur incrémental Zinc a atteint la version 1.0.

Zinc est utilisé par bon nombre de développeurs Scala sans vraiment qu’ils s’en rendent compte : il est intégré dans sbt (pour lequel il a d’abord été prévu), pants, CBT, IntelliJ ou encore Scala IDE. Son seul objectif est d’améliorer les temps de recompilation en limitant le nombre de fichiers traités : Zinc analyse les dépendances entre parties du code et n’en recompile qu’une partie, celle qui a été changée depuis la dernière compilation et tout ce qui en dépend. Il est prévu pour que le résultat de cette compilation soit identique à une compilation depuis zéro — quitte à être conservatif et à recompiler des choses qui n’en auraient pas eu besoin.

Une des nouveautés de cette version 1.0 est l’analyse de dépendance au niveau des classes : auparavant, cette analyse était effectuée par fichier. Cependant, vu qu’un fichier Scala peut contenir un grand nombre de classes, cette manière de procéder menait à de grandes inefficacités. Grâce à ce changement, les temps de recompilation ont pu être améliorés d’un facteur quarante dans certains cas. Ce code était en partie prêt depuis mars 2016, mais a dû être retravaillé avant d’arriver en production, notamment au niveau de la compatibilité avec Java.

En pratique, sur ScalaTest, l’évolution entre Zinc 0.13 et 1.0 est très importante : la recompilation de ce projet de 40 377 lignes prend sept fois moins de temps avec la nouvelle version, en ajoutant simplement une nouvelle méthode.

Avec Zinc 0.13, la compilation incrémentale prend vingt et une secondes :

Zinc 1.0 réduit ce temps à trois secondes :

D’autres améliorations de Zinc 1.0 concernent de rares cas de sous-recompilation (qui causaient des problèmes de correction), des améliorations dans le pont avec Java ou dans la gestion des types. Les API ont été améliorées et le code a été entièrement migré vers Scala 2.12 : Zinc est maintenant prêt pour Java 8.

Sources : Speed up compile times with Zinc 1.0.

Clazy Web UI, une interface Web pour visualiser les messages de Clang

Clazy est une extension au compilateur Clang qui effectue une analyse statique principalement orientée Qt, afin de faciliter le déploiement de bonnes pratiques, mais aussi de limiter les allocations de mémoire dues à une mauvaise utilisation de l’API.

KDAB annonce maintenant, après Clazy, une interface Web pour faciliter la visualisation des résultats, ainsi que des messages produits par le compilateur en général : Clazy Web UI. KDAB en héberge une instance pour Qt, ce qui permet de voir l’outil en situation réelle.

L’interface est prévue pour être simple à utiliser : après avoir sélectionné un module Qt, elle montre tous les types d’avertissement trouvés lors de la compilation et les endroits dans le code. Il est aussi possible de filtrer les résultats bruts, afin d’éliminer les faux positifs ou encore les mentions les moins intéressantes.

Outre l’amélioration de l’outillage C++, l’objectif est bien évidemment d’attirer plus de contributeurs à Qt, en leur montrant une série de tâches relativement simples à accomplir. Cela pourrait les aider à franchir la barre de gerrit.

Source : Clazy Results Visualizer for Qt, Web UI to view clazy and gcc warnings.

Flang, le compilateur Fortran basé sur LLVM, enfin annoncé

L’annonce du développement de Flang est loin d’être récente : elle date de novembre 2015. Ensuite, silence radio, jusqu’à l’ouverture du dépôt Flang sur GitHub, en mai de cette année. Un développeur de NVIDIA vient d’annoncer officiellement l’ouverture du projet au grand public.

En quelques mots, Flang est la culmination d’un effort de NVIDIA, plus particulièrement sa filiale PGI (connue pour son compilateur Fortran), sous l’impulsion donnée par la NNSA du Département de l’énergie américain. Ces presque deux ans de projet ont mené assez loin. L’objectif était de partir du compilateur existant de PGI et de le porter pour qu’il utilise l’infrastructure de LLVM (représentation intermédiaire, passes d’optimisation, génération du code assembleur, etc.), pas d’écrire un compilateur de zéro.

En l’état, Flang possède les mêmes fonctionnalités que le compilateur de PGI, c’est-à-dire l’entièreté de la norme Fortran 2003, quelques fonctionnalités de la révision de 2008 et des extensions propriétaires pour améliorer la compatibilité avec le Fortran primitif. Contrairement à Clang, qui est à la pointe en termes de fonctionnalités des derniers standards C++, Flang ne s’intéresse pas à Fortran 2015 pour le moment ; pour Fortran 2008, la priorité est mise sur les sous-modules et les constructions BLOCK et DO CONCURRENT. Au niveau d’OpenMP, Flang utilise la bibliothèque de support de LLVM ; la version 4.5 de la norme est presque entièrement implémentée pour les processeurs multicœurs.

Contrairement à Clang et au projet LLVM en général, Flang est principalement écrit en C et cela ne devrait pas changer. Ce choix a été posé pour reprendre autant de code de PGI que possible, tout en respectant les règles de codage du projet LLVM. L’objectif est de passer à C++ dans le futur, les développeurs sont ouverts à la discussion, mais préféreront se focaliser sur des points précis à discuter avec la communauté. Au niveau de la licence, Flang est actuellement disponible sous la licence Apache, mais sera distribué sous la même licence que LLVM lorsque son code aura été approuvé pour intégration à LLVM. En l’état, Flang passe toute la suite de tests de PGI, de nouveaux sont ajoutés en permanence.

Côté technique, Flang n’utilise pas les API de LLVM pour générer la représentation intermédiaire des programmes Fortran : il écrit directement dans un fichier, puis fait appel à opt et llc au besoin par la suite. La partie frontale de Flang est organisée en deux exécutables, l’un étant prévu pour les utilisateurs (il gère les paramètres de compilation) et appelant le deuxième pour la compilation effective. Pour le moment, il ne fonctionne que sous Linux, sur les architectures x86-64 (pour le grand public), ARM (comme les téléphones portables et certains nouveaux supercalculateurs) et OpenPOWER.

Source : [Flang-announce] Flang Fortran front-end for LLVM.

Sortie de Julia 0.6

Julia est un langage de programmation de haut niveau, dynamique, mais orienté applications de haute performance (surtout pour le calcul scientifique). Malgré son jeune âge (il est apparu pour la première fois au grand public en 2012), il a déjà réussi à fédérer une certaine communauté (on estime à 250 000 son nombre d’utilisateurs en 2017), dans bon nombre de domaines.

Sa version 0.6 est sortie, un peu moins d’un an après la précédente. Elle marque le dernier jalon avant la version finale : la 0.7 et 1.0 sortiront presque simultanément, la seule différence étant la gestion d’anciennes syntaxes et l’émission de messages correspondants pour la 0.7 (ce dont la 1.0 ne s’alourdira pas).

Le plus gros changement de Julia 0.6 concerne le moteur d’inférence des types, qui a été complètement réécrit pour être plus rapide, donner des résultats plus précis (ce qui permet d’optimiser le code exécuté) et permettre de nouvelles fonctionnalités. Ainsi, en définissant un nouveau type avec des paramètres (comme une classe générique dans bon nombre d’autres langages), on peut faire référence aux types des paramètres précédents. Par exemple, avec struct Foo{R<:Real, A<:AbstractArray{R}}, on définit un type Foo par rapport à un type particulier de nombres réels (comme Float64) et un tableau (dont les éléments doivent avoir le même type que mentionné précédemment).

Au niveau syntaxique, les mots clés pour définir des types ont été changé pour promouvoir par défaut des valeurs immuables : le code généré est bien souvent plus rapide, cela réduit le risque d’erreur lors de l’écriture du code, avec un impact souvent minime sur l’utilisateur. Ainsi, type devient mutable struct tandis que immutable devient simplement struct.

Pour la performance, les opérateurs et fonctions sont tous vectorisés automatiquement à l’aide d’un point : a .⨳ b est la syntaxe équivalente à l’application de l’opérateur  entre tous les éléments de a et de b. L’avantage principal est que ce mécanisme est géré au niveau du langage, il n’y a plus de traitement particulier des opérateurs vectorisés. Grâce à ce changement, l’écriture de code très optimisé sur des vecteurs devient très facile : pour évaluer une expression utilisant une série d’opérateurs vectorisés, Julia n’exécute qu’une seule boucle à travers les opérandes.

Voir aussi : les notes de version de Julia 0.6.

En route vers Scala 3 : sortie de Dotty 0.1.2 RC 1

La version 0.1.2 RC 1 du nouveau compilateur Scala, Dotty, est sortie fin mai. Il s’agit d’une réécriture complète du compilateur Scala, avec des changements au niveau syntaxique. La 0.1.2 est spéciale en ce sens qu’il s’agira de la première version publique de Dotty, même si le projet est connu de longue date — son développement dure déjà depuis quatre ans, le compilateur peut se compiler lui-même depuis 2015.

Par rapport à Scala 2, la syntaxe est légèrement épurée : notamment, il n’y a plus moyen d’écrire directement du XML dans du code Scala ; le langage fournit moins de types, mais des constructeurs revenant aux fondamentaux. La différence principale par rapport à Scala 2 se situe au niveau théorique : Dotty se base sur le modèle de calcul DOT (plus simple que les machines de Turing ou le calcul lambda, par exemple, mais surtout plus adapté au code réel). Cela permet de réaliser des preuves formelles à propos de morceaux de code. Ce modèle de calcul est forcément réduit par rapport aux fonctionnalités du langage, mais la plupart des constructions syntaxiques peuvent se réécrire dans ce modèle.

Quelques nouveautés par rapport à Scala 2 peuvent déjà être notées, comme les types d’intersection (un objet passé en argument à une fonction doit posséder plusieurs traits) et d’union (au moins un trait).

def f(x: Resettable & Growable[String]) = { // Intersection : à la fois Resettable et Growable[String]
  x.reset()
  x.add("first")
}

def help(id: UserName | Password) = { // Union : soit un UserName, soit Password (soit les deux)
  // ...
}

Les traits peuvent aussi posséder des paramètres, tout comme les classes.

trait Greeting(val name: String) {
  def msg = s"How are you, $name"
}

Les énumérations font leur apparition.

enum Color {
  case Red, Green, Blue
}

Dès maintenant, les développeurs se forceront à produire de nouvelles versions régulièrement : des versions compilées chaque jour et des RC toutes les six semaines, ces dernières devenant des versions finales après six semaines.

Sources : Announcing Dotty 0.1.2-RC1, a major step towards Scala 3, 0.1.2 release notes.

Plus de détails sur DOT.

Des nouvelles de Flang, le compilateur Fortran basé sur LLVM

Après un an et demi de travaux, le compilateur Fortran basé sur LLVM promis par NVIDIA arrive enfin sur GitHub, bien que sans annonce officielle. Le projet a commencé avec un étudiant (financé par le programme Google Summer of Code) en 2013 sous le nom de Flang (analogue de Clang, le compilateur LLVM pour le C et ses dérivés), puis a été repris par NVIDIA et la sécurité nucléaire du département américain en 2015. L’objectif était de fournir un compilateur libre de très haute qualité, notamment basé sur celui de PGI.

Avec le développement de LLVM, ce projet apporte de plus en plus de promesses à l’écosystème Fortran. Par exemple, LLVM permet de compiler du code pour les GPU NVIDIA : grâce à Flang, il sera très facile d’offrir un compilateur libre pour ce faire (sans devoir utiliser celui de PGI). Également, OpenMP permet de décharger l’exécution du code sur un accélérateur : GCC ne le permet pas encore pour des cartes graphiques, uniquement les coprocesseurs Intel Xeon Phi ;  LLVM, quant à lui, gère les cartes NVIDIA et les coprocesseurs Intel Xeon Phi.

Pour le moment, Flang fonctionne avec LLVM 3.9 (presque la dernière version). Les sources de la version 1.0 sont en ligne depuis une semaine (avec des commits d’employés de NVIDIA et de PGI), mais aucune annonce officielle n’a encore été faite (la documentation fait référence à un site qui n’existe pas encore, http://flang.nvidia.com/). La norme Fortran 2008 est implémentée, mais aucune information n’est donnée sur le niveau de compatibilité (le compilateur de PGI n’implémente pas toute la norme). La grande différence par rapport au compilateur de PGI devrait être la qualité des messages d’erreur, du niveau de Clang.