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.

Advertisements

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.

Sortie de CLion 2017.1

JetBrains est une société spécialisée dans la conception d’environnements de développement. Ses produits les plus connus sont IntelliJ (un EDI indépendant d’abord orienté Java) et ReSharper (une extension C# pour Visual Studio), sans oublier PyCharm (pour Python) ou encore WebStorm (pour le développement Web). En 2015, la firme a lancé CLion, son EDI pour les langages C et C++, en partie dérivé d’AppCode (destiné, quant à lui, à la création d’applications iOS en Objective-C). À presque deux ans, voici la version 2017.1 de l’EDI, qui continue à gagner en maturité et à faire de l’ombre aux grands que sont Visual Studio ou encore Eclipse.

Au niveau des dernières fonctionnalités, on trouve principalement les nouveautés de C++14 et 17. De manière générale, presque tout C++14 est géré (tout sauf constexpr) : par rapport à la version précédente, ce sont donc le type auto, les fonctions anonymes génériques, les modèles variables (au lieu d’un nombre fixé de paramètres) et les captures généralisées. Côté C++17, seuls les espaces de noms imbriqués sont apparus (c’est l’apport de la nouvelle norme plébiscité par les utilisateurs) — le reste de la norme suivra dans les versions à venir de l’EDI. Cela signifie que tous ces aspects du langage bénéficient d’une coloration syntaxique et d’une complétion automatique, sans oublier une intégration aux mécanismes de navigation et de refactorisation du code ; par exemple, CLion peut déterminer le type que prendra une variable automatique afin de proposer l’autocomplétion en conséquence.

Une nouvelle intention est disponible. Elle permet de moderniser d’un clic un bout de code : plus précisément, de remplacer le type d’une variable par le mot clé auto.

Le débogueur a été l’objet de bon nombre d’attentions, avec la correction d’un grand nombre de défauts (notamment des temps d’attente expirés avec GDB). Un désassembleur est maintenant intégré, de telle sorte qu’il est possible de poursuivre l’exécution pas à pas y compris dans du code pour lequel les sources ne sont pas disponibles (une version future de CLion permettra d’accéder à ce désassembleur de manière autonome). Le code assembleur aura aussi une coloration syntaxique (même en dehors du débogueur), à condition de respecter la syntaxe AT&T et de ne pas utiliser de préprocesseur.

CLion est maintenant compatible avec de nouveaux outils de l’écosystème C++. Pour les tests, Google Test est géré depuis le début, Catch apparaît avec cette version. Le compilateur Visual C++ est aussi de la partie (versions 2013 à 2017), sous Windows, mais uniquement de manière expérimentale. Ainsi, CLion ne cherche pas automatiquement le compilateur, il faut l’activer manuellement (le résultat n’est pas encore parfait). msbuild n’est pas géré, CMake reste la seule manière de créer un projet avec CLion. Le débogueur de Visual C++ n’est pas intégré.

Ceci n’est qu’un aperçu des différences fonctionnalités apparues. On peut aussi compter la saisie sans délai (la latence entre l’appui d’une touche sur le clavier et l’impact à l’écran est le plus faible parmi tous les EDI !), la recherche dans un dossier avec prévisualisation automatique, une vue améliorée de l’historique d’un dépôt (avec possibilité d’utiliser des expressions régulières !) ou encore une extension pour les langages Swift (remplaçant d’Objective-C) et Go (un EDI spécifique est en cours de développement).

Télécharger CLion 2017.1.

Source et images : CLion 2017.1 released: C++14, C++17, PCH, disassembly view, Catch, MSVC and more.

Sortie de Mathematica 11.1

Sept mois après la version 11, voici que Mathematica 11.1 arrive. Cet environnement de développement complet continue d’apporter de nouvelles fonctionnalités au niveau de l’apprentissage automatique et de la visualisation, entre autres, avec une remise à plat de la présentation de l’aide. 29 ans après la première version publique de Mathematica, le logiciel continue de s’étoffer : 132 nouvelles fonctions, 98 autres améliorées. Il ne s’agit pas vraiment de pans complets de fonctionnalités (comme on avait pu le voir avec les réseaux neuronaux de Mathematica 11, par exemple), mais plutôt d’améliorations continues.

Apprentissage automatique

L’interface de très haut niveau pour définir des réseaux neuronaux de manière symbolique a continué son extension, notamment au niveau des réseaux récurrents et LSTM, sans oublier des couches pour gérer les séquences de longueur variable. NetEncoder permet d’encoder une entrée (comme une image ou du son) de n’importe quelle manière.

De manière plus générale pour l’apprentissage automatique, FeatureSpacePlot représente une série d’échantillons dans un espace de variables déterminé automatiquement, selon le type d’entrée.

De nouvelles fonctions ont fait leur apparition pour l’apprentissage de séquences (SequencePredict) et l’apprentissage actif, c’est-à-dire que Mathematica décide où évaluer la fonction à apprendre (ActiveClassification et ActivePrediction).

Toutes ces fonctions ne sont pas encore dans leur version finale, c’est-à-dire que leur interface pourrait encore changer dans les versions à venir. Cependant, une fois l’interface figée, elle ne changera plus dans le futur : des  programmes Mathematica 7 (2008) et plus anciens continuent de fonctionner sans modification sur les versions actuelles.

Audio et vidéo

Il devient plus facile de capturer l’information des micros (AudioCapture) et caméras de l’ordinateur (CurrentImage). L’affichage des cepstres d’un son devient aisé, tout comme l’application d’effets. TextRecognize peut aussi trouver la structure d’un texte (paragraphe, colonne, etc.).

Visualisation

Mathematica est connu pour la puissance de son moteur de calcul symbolique, mais aussi pour celle de ses visualisations. L’affichage de texte dans les graphiques s’est simplifié avec Callout, tout comme la mise à l’échelle des graphiques avec ScalingFunctions. BubbleChart permet d’afficher des bulles de taille variable.

Sources et images : The R&D Pipeline Continues: Launching Version 11.1, Summary of New Features in 11.1, Mathematica 11.1 Is Out Now!.

Feuille de route pour Scala 2.13

Dans la communauté Scala, 2017 sera l’année du développement de la version 2.13 du langage (la première RC devrait arriver début 2018). La version 2.12 est donc encore là pour un certain temps. La feuille de route est déjà établie pour Scala 2.13, avec les fonctionnalités souhaitées — modulo les autres envies de la communauté qui seront intégrées d’ici-là. Quatre axes ont été définis : une réécriture de la bibliothèque de collections, des améliorations de performance pour le compilateur, la modularisation de la bibliothèque standard, des simplifications pour les utilisateurs du langage.

Collections

La bibliothèque des collections de Scala est assez régulièrement retravaillée pour la rendre plus facile à utiliser, en améliorer la performance ou la qualité du code. L’itération actuelle date de Scala 2.8 et utilise un grand nombre de couches d’abstraction, très flexibles, qui généralisent tant les collections immuables qu’altérables, parallèles que séquentielles. Chaque nouvelle collection peut ainsi réutiliser une grande partie du code déjà écrit.

Cette implémentation a cependant un certain nombre de défauts. Principalement, pour créer de nouvelles collections, il faut se plonger en profondeur dans la documentation pour déterminer les paramètres implicites à utiliser et vérifier les fonctions héritées à réécrire. Les utilisateurs ne sont pas en reste : niveau performance, tout n’est pas parfait. Par exemple, Slick a pu grandement accélérer certaines étapes de calcul (de l’ordre de 25 % !) en réimplémentant certaines collections, sans chercher à adapter leur implémentation à leurs besoins.

Les modifications prévues visent principalement à réduire fortement l’utilisation de l’héritage pour les collections, tout en gardant un très haut niveau de compatibilité des sources avec l’implémentation existante (soit garder l’API l’existante, soit proposer un outil pour corriger automatiquement le code source). Les développements sont visibles sur GitHub.

Modularisation

La modularisation de la bibliothèque standard de Scala a commencé avec la version 2.11. L’objectif est de déporter une partie du code en dehors du cœur de l’implémentation du langage et de laisser la communauté proposer des solutions. L’avantage principal est que les solutions proposées peuvent évoluer nettement plus vite que Scala.

Un autre avantage est que le cœur peut garder une compatibilité binaire nettement plus facilement entre versions de Scala, ce qui limite les problèmes lors des mises à jour. Il faut noter que Scala laisse toujours accès à la bibliothèque standard Java, ce qui est loin d’être négligeable.

Avec Scala 2.13, la bibliothèque standard se réduira aux collections et à quelques types de base (Option, TypleN, Either, Try).

Améliorations du compilateur

Le langage en lui-même n’évoluera pas tellement avec la version 2.13, celle-ci se focalisant sur les aspects des bibliothèques. Cependant, le travail continue sur le compilateur, principalement pour le rendre plus rapide. Le premier objectif poursuivi sera de développer l’infrastructure nécessaire pour mesurer finement la performance du compilateur. Ensuite, les développeurs de Scala utiliseront tous les outils à leur disposition pour détecter les problèmes (principalement, des profileurs JVM).