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.

Advertisements

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.

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).

Scala Native : accéder au bas niveau depuis Scala

Le langage Scala n’est pas dénué d’avantages, comme beaucoup d’autres : il est typé (comme C ou Pascal), mais ne force pas à indiquer les types explicitement dans le code (contrairement aux précités, mais comme Python) ; il n’impose pas une verbosité monstre (contrairement à Java), avec une syntaxe orientée productivité (comme Python) ; il est raisonnablement rapide (comme Java, mais nettement moins que C), mais permet d’exploiter le parallélisme très facilement (contrairement à Python).

Par contre, un des inconvénients de Scala est sa vitesse d’exécution, pas toujours suffisante : il faut compter le temps de démarrage de la JVM, puis les optimisations que le moteur JIT peut effectuer sur le code qui lui est soumis, sans oublier que le ramasse-miettes peut venir jouer. La sécurité que le langage offre peut aussi aller à l’encontre de la performance à l’exécution : il est impossible de s’échapper du bac à sable défini, à l’exception de quelques utilisateurs très expérimentés. Finalement, au niveau de l’accès aux bibliothèques natives préexistantes, leur réutilisation est presque impossible — après tout, ces bibliothèques natives pourraient causer des problèmes de sécurité !

Pour résoudre ces problèmes, une équipe de l’EPFL, déjà à l’origine de Scala, a lancé le développement de Scala Native. Ce compilateur Scala exploite LLVM, l’infrastructure de compilateurs derrière Clang, notamment. La syntaxe de cette variante de Scala ne diffère de l’originale que par quelques ajouts, dont l’objectif est de faciliter l’interopérabilité avec des bibliothèques natives, comme des structures C (avec l’annotation @struct sur une classe) ou encore l’allocation de mémoire sur le tas avec des pointeurs :

@struct class Vec ( // Définition d'une structure en C.
 val x: Double
 val y: Double
 }
 val vec = stackalloc[Vec] // Équivalent à un malloc() en C ou un new en C++ : vec est un pointeur sur le tas.

Pour accéder directement à des fonctions C (comme malloc()), il est aussi possible d’utiliser l’annotation @externe et directement définir la fonction comme utilisable :

@extern object stdlib {
 def malloc(size: CSize): Ptr[_] = extern
 }
 val ptr = stdlib.malloc(32)

Au niveau de l’implémentation, le projet Scala Native ne duplique pas l’analyse syntaxique du compilateur, mais l’utilise (ou bien dotty, la prochaine génération du compilateur Scala). Il profite donc d’une base de code bien établie, ainsi que d’optimisations éprouvées dans le contexte du code Scala.

À l’exécution, bien sûr, Scala Native exploite toujours un ramasse-miettes, le classique Boehm, simplement parce qu’il a l’avantage de déjà exister. Les développeurs notent qu’il ne peut que s’améliorer par rapport à cette implémentation générique. La bibliothèque standard Java est partiellement disponible, toute la bibliothèque standard C est accessible.

Ce générateur de code natif depuis Scala n’est pas encore prêt pour le plus grand nombre, il a, à peine, été annoncé ce mois-ci. Ses objectifs ne concernent pas les temps de compilation. Cependant, il montre que le langage Scala veut s’exporter de plus en plus, après un autre générateur de code JavaScript pour utiliser son code dans des navigateurs Web.

Source (dont image) : présentation à Scala NYC.
Voir aussi : le site officiel de Scala Native, le projet sur GitHub.

Calendrier 2016 pour Scala : la version 2.12 en vue

Scala est un langage de programmation pour la JVM, c’est-à-dire qu’il exploite l’écosystème Java, mais avec une syntaxe et des concepts radicalement différents de ceux de Java, tout en maintenant une forte compatibilité (tout code Java peut être appelé depuis Scala et vice-versa). Scala est donc un langage orienté objet, mais fonctionnel depuis sa conception (contrairement aux extensions fonctionnelles de Java 8) ; il possède également un système de typage fort. De manière générale, il tend à être concis tout en éliminant les défauts du langage Java — sa conception a débuté en 2001 à l’EPFL, dans le laboratoire de méthodes de programmation (LAMP).

La série actuelle, numérotée 2.11, sera la dernière à être compatible avec Java 6, avec des versions régulièrement mises à disposition. Les développeurs peaufinent énormément cette version, car la suivante est l’objet de grands travaux, avec notamment l’élimination de la compatibilité avec Java 6 et 7. La dernière version devrait être la 2.11.9, au troisième trimestre de 2016, c’est-à-dire deux ans après la première version de Scala 2.11.

Le futur s’annonce de plus en plus excitant : pour tirer le meilleur parti de Java 8, le compilateur encodera d’une manière très différente les traits et fonctions anonymes, beaucoup plus proche du comportement actuel de Java 8. Ainsi, l’interopérabilité sera beaucoup plus facile avec Java, avec la possibilité d’écrire des fonctions anonymes en Java pour les utiliser avec une bibliothèque Scala et vice-versa — ceci, sans changement du code Scala. Du côté technique, cet encodage utilisera les pointeurs sur méthodes (instances de la classe MethodHandle), comme Java 8, ce qui devrait diminuer les temps de compilation et la taille des binaires générés, même si le gain de performance n’est pas clair.

De manière plus générale, le compilateur a droit à une cure de jouvence, basé sur les derniers travaux côté EPFL de Miguel Garcia (partiellement intégrés dans Scala 2.11) : de manière générale, seule l’analyse syntaxique du code Scala est gardée par rapport aux versions précédentes, le reste a été fondamentalement retravaillé pour augmenter la performance (la compilation est de quinze pour cent plus rapide qu’avec Scala 2.10, sur tout le processus) et la taille des binaires générés.

La syntaxe du langage n’évolue pas entre Scala 2.11 et 2.12, toutes ces améliorations se font sous le capot. Actuellement, la préversion 2.12 M3 est disponible depuis début octobre ; elle est déclarée suffisamment stable pour que les développeurs de bibliothèques commencent à tester et à distribuer des versions compilées de leurs bibliothèques. La prochaine, numérotée 2.12 M4, est prévue fin janvier 2016, avec la première version admissible 2.12 RC1 fin mai 2016. La version finale n’est pas encore planifiée, mais ne devrait pas tarder, à moins que des défauts majeurs soient trouvés.

Les versions suivantes devraient reprendre le train des améliorations dans la syntaxe et la bibliothèque standard, avec un compilateur bien plus facile à maintenir et à faire évoluer. Rien n’est encore véritablement planifié, mais les améliorations imaginées comportent :

  • une simplification des collections (par exemple, de leur hiérarchie), par défaut immuables, avec un déplacement de fonctionnalités en dehors de la bibliothèque standard, notamment pour faciliter l’optimisation ;
  • des collections parallèles avec des améliorations de performance, obtenues par la fusion d’opérations et un ordonnancement ;
  • l’intégration de la réflexion et des macros à la Lisp comme fonctionnalités pleinement supportées (certaines sont actuellement expérimentales) ;
  • une syntaxe simplifiée et unifiée, pour se rapprocher des principes fondateurs du langage : un ensemble réduit de fonctionnalités orthogonales faciles à assembler (comme Lisp) ; la syntaxe XML pourrait ainsi disparaître, tout comme les fonctionnalités qui mènent régulièrement à des comportements inexplicables pour les débutants.

Source : 2016 Scala Release Schedule update, Scala 2.12 Roadmap.