Un nouveau compilateur Fortran libre pour LLVM

Publié le par
Répondre

La NNSA, la partie du Département de l’Énergie américain s’occupant de la sécurité nucléaire (NNSA), utilise énormément de calcul scientifique dans ses trois laboratoires nationaux (Lawrence Livermore, Los Alamos, Sandia) pour étudier le nucléaire dans ses applications militaires (y compris leur destruction). Leurs codes de calcul tendent souvent à mélanger plusieurs langages de programmation, généralement Fortran (populaire uniquement dans le milieu scientifique) et C ou C++ (plus généraliste), ils ont donc besoin d’un même compilateur pour tous ces langages. LLVM et Clang font leur nid dans le domaine du calcul scientifique (par exemple, avec des investissements de Google), mais ils ne peuvent rien faire pour du code Fortran.

Collaboration avec NVIDIA

Le projet lancé en collaboration avec NVIDIA est de développer un nouvel analyseur de code pour Fortran pour l’intégrer dans la galaxie LLVM. Ce choix a été posé par opposition à GCC, l’autre grande suite de compilateurs libre, notamment pour des raisons de licence : LLVM est distribué sous une licence de type BSD, bien plus permissive qu’une GPL. De plus, l’architecture globale de LLVM est très moderne et facilite la recherche dans le domaine des compilateurs, plus particulièrement de l’optimisation (un autre point souvent reproché à GCC). De plus, ce n’est pas la première fois que NVIDIA travaille avec LLVM.

Bien sûr, ce développement ne partira pas de zéro : le partenariat avec NVIDIA a été scellé à cause du rachat de PGI, une société spécialisée dans les compilateurs Fortran, C et C++ à destination spécifiquement du marché du calcul scientifique depuis plus de vingt-cinq ans (ce qui implique que ces compilateurs sont compatibles avec OpenMP et OpenACC). Ils sont notamment à l’Å“uvre dans le compilateur CUDA Fortran (raison du rachat par NVIDIA). Malgré ces origines, le communiqué de presse tient à rassurer : ce projet s’étendra sur plusieurs années (la première version utilisable devrait être disponible dans un an, vers la fin 2016) et suivra à la lettre les directives du projet LLVM pour le code et l’interface de programmation. Pas un mot, par contre, sur la collaboration avec Flang, un embryon de compilateur Fortran pour LLVM.

Plateformes

La performance pourrait poser question : le compilateur Fortran de PGI n’est pas connu pour proposer le code le plus rapide qui soit (voir, par exemple, les comparatifs de Polyhedron). L’espoir est que, couplé aux passes d’optimisation de LLVM, ce compilateur libre soit comparable aux meilleurs actuellement. Il pourrait aussi profiter de toutes les plateformes pour lesquelles LLVM peut générer du code binaire, principalement du x86, mais aussi MIPS ou les GPU.

Notamment, IBM parle déjà en bien de ce projet, par rapport à leur architecture POWER et le consortium OpenPOWER : ce compilateur pourra être utilisé sur leurs machines. D’ailleurs, IBM et NVIDIA sont à la manÅ“uvre pour la réalisation du superordinateur Sierra, qui devrait être installé dans le laboratoire de Lawrence Livermore, avec une puissance de cent pétaflops (juste derrière l’autre projet américain, Summit, prévu pour le laboratoire de l’Oak Ridge avec une puissance de cent cinquante pétaflops). Une grosse partie de la puissance devrait provenir des GPU. Les États-Unis espèrent, avec ces deux projets, de se remettre au plus haut niveau en termes de puissance de calcul : le plus gros supercalculateur, actuellement, est Tianhe-2, en Chine, avec une puissance de cinquante-cinq pétaflops.

Source : NNSA, national labs team with Nvidia to develop open-source Fortran compiler technology.

Unreal Engine 4 et NVIDIA GameWorks VR : d’impressionants gains de performance

Publié le par
Répondre

Unreal Engine 4.10 vient avec un bon nombre d’améliorations de performance au niveau de la réalité virtuelle. Cependant, pour NVIDIA, il est encore possible d’aller plus loin en intégrant leur SDK prévu pour la réalité augmentée, GameWorks VR. En l’incluant dans UE 4, il serait possible d’obtenir cinquante pour cent d’images chaque seconde en plus.

Une des techniques implémentées est l’application de shaders à de multiples résolutions : le centre de l’image, là où se focalisent les yeux, fait l’objet d’un traitement plus poussé ; une résolution moindre est utilisée pour les zones périphériques. Cette optimisation se fait sans grand impact sur la qualité d’image, étant donné que les casques ont tendance à distordre les images au niveau de cette même périphérie. Dans la démo Reflection Subway, l’impact sur le nombre d’images par seconde est radical.

Selon NVIDIA, le plus grand problème pour que la réalité virtuelle devienne courante est vraiment la performance : leur objectif est une résolution Full HD (1080p, c’est-à-dire 1980 pixels par 1080) à trente images par seconde pour un jeu traditionnel, mais deux fois 1512 par 1680 à raison de nonante images par seconde en réalité virtuelle, ce qui fait un rapport de sept en nombre de pixels à émettre chaque seconde. (De nombreux joueurs sur PC préfèrent la cible de soixante images par seconde, ce qui réduit de moitié l’écart cité par NVIDIA.)

Par des améliorations au niveau logiciel (comme GameWorks VR) et matériel, ils prévoient d’atteindre un marché de cent trente millions d’ordinateurs prêts pour la réalité virtuelle en 2020 (par rapport à cinq millions actuellement) — bien évidemment en matériel GeForce —, de telle sorte que la réalité virtuelle devienne une partie intégrante de la vie quotidienne.

Actuellement, quelques jeux sont en cours de développement avec Unreal Engine et prévoient d’exploiter la réalité virtuelle. Par exemple, ADR1FT, une fiction interactive à la première qui suit un astronaute dans l’espace ; Loading Human, spécifiquement développé pour le matériel Oculus Rift, un jeu d’aventure, également dans l’espace ; EVE Valkyrie, un jeu multijoueur d’action et de tir, toujours en spatial.

Source : Get Ready: Unreal Engine 4 to Incorporate NVIDIA GameWorks VR (images), GameWorks VR To Be Included In Unreal Engine 4, Helps Getting Up To 50% More Performance.

CUDA et LLVM, des nouvelles

Publié le par
Répondre

Le compilateur officiel de NVIDIA pour ses extensions GPGPU aux langages C et C++, nvcc, n’est plus la seule option pour compiler ce code CUDA depuis la version 4.1. Depuis ces quelques années, cette contribution au compilateur libre LLVM fait son bout de chemin. L’idée est de générer du code PTX, c’est-à-dire l’assembleur utilisé sur les GPU NVIDIA, traduit par les pilotes officiels en instructions pour chaque GPU.

La semaine dernière, deux nouveautés sont arrivées dans les dépôts de LLVM et Clang au sujet de CUDA. La première est un guide rapide pour compiler le compilateur et commencer à l’utiliser, surtout à destination de chercheurs et développeurs de LLVM, notamment pour les aider à développer des passes d’optimisation spécifiques aux GPU. Pour ce faire, une série de modifications au niveau des sources de LLVM est nécessaire (l’implémentation s’oriente comme nvcc, avec du code pour l’hôte et le GPU mélangé dans un même fichier).

Ce document explicite notamment les optimisations déjà réalisées par LLVM et les modifications CUDA pour améliorer la performance sur les GPU. Notamment :

  • la réduction des redondances dans le calcul d’expressions mathématiques : si x=b*s a déjà été exécuté, l’affectation y=(b+1)*s sera réécrite comme y=x+s, ce qui évite de calculer le facteur b+1 en sus de la multiplication ;
  • l’inférence de l’espace mémoire à utiliser pour une variable (à choisir entre mémoires globale, constante, partagée et locale) ;
  • le déroulement des boucles et l’extension en ligne des appels de fonction plus agressifs que sur du code à destination de CPU, puisque tout transfert de l’exécution sur un GPU est bien plus coûteux que sur un CPU (tout saut, toute condition nuit fortement à la performance) ;
  • l’analyse du recouvrement entre pointeurs, dans le cadre d’une passe généralisée à tout LLVM (bien que cette partie spécifique aux GPU n’est pas encore intégrée) ;
  • l’évitement de divisions lentes sur soixante-quatre bits, par manque de circuits spécifiques pour cette opération sur les GPU NVIDIA (elles sont remplacées, autant que possible, par des opérations sur trente-deux bits).

Une bonne partie de ces optimisations a eu des contributions de la part de Google, qui pourraient sembler quelque peu inattendues. Leur objectif est de développer une plateforme à la pointe de la technologie pour la recherche sur la compilation pour GPU et le calcul scientifique de haute performance en général. Leurs premiers résultats, présentés par Jingyue Wu, indiquent que leurs avancées sur LLVM font aussi bien que le compilateur de NVIDIA, nvcc, sur certains tests… et vont parfois jusque cinquante pour cent plus vite que le code produit par nvcc ! Ceci s’accompagne d’un gain de huit pour cent en moyenne sur le temps de compilation (sans véritable intégration à Clang, puisque la compilation s’effectue en plusieurs phases bien séparées — GPU et CPU —, ce qui fait perdre pas mal de temps).

Sortie de Unreal Engine 4.10

Publié le par
Répondre

La nouvelle version de Unreal Engine est sortie, numérotée 4.10. Elle amène un bon nombre d’améliorations (dont cinquante-trois par la communauté). De manière générale, cette version améliore l’utilisation en réalité virtuelle (avec notamment des améliorations de performance spécifiques pour les casques de visualisation) et la compatibilité avec de nouvelles plateformes.

Effets sur plateformes mobiles

Les effets de réfraction sont maintenant disponibles sur les plateformes mobiles, en droite ligne de l’effet sur les autres plateformes : les shaders fonctionneront sans aucune modification, sur des téléphones récents, tant iOS qu’Android.

Également, un système de contrôle de la qualité des matériaux a fait son apparation. Il facilite la mise à disposition d’applications pour toute une gamme d’appareils, du plus haut de gamme au moins cher, en générant des versions de plus ou moins bonne qualité pour chaque shader, en désactivant des fonctionnalités pour augmenter la performance (au détriment de la qualité d’image). Le moteur pourra détecter de manière automatique un bon niveau par défaut pour les plateformes les plus populaires.

Réalité virtuelle

Les jeux exploitant la réalité virtuelle seront bien plus rapides à l’exécution avec cette nouvelle version grâce à des optimisations spécifiques à ces appareils. Pour limiter l’utilisation du GPU, elles portent sur les parties des maillages visibles et invisibles pour chaque Å“il, pour éviter de passer du temps sur des parties qui ne seront jamais affichées à cause des distorsions dues aux lentilles. Il s’agit d’une nouvelle passe dans le flux de rendu, qui désactive très vite ces parties en dehors du champ, la même chose étant effectuée pour le posttraitement. Dans la démo Bullet Train, sur un ordinateur de test, chaque trame prenait onze millisecondes de calcul : cette optimisation représente un gain d’un quart de milliseconde (un gain qui devrait être plus grand sur plateformes mobiles).

Plateformes

Unreal Engine fonctionne désormais avec Visual Studio 2015, ce qui permet de profiter des dernières fonctionnalités ajoutées dans le compilateur (principalement des normes C++11 et C++14, pas encore entièrement implémentées) — et qui continuent d’arriver par le biais de mises à jour régulières. Toutes les éditions sont compatibles, dès la version gratuite (Community), avec cependant quelques limitations pour la version Express (qui n’autorise pas les extensions, contrairement à la Community). La compatibilité avec Visual Studio 2013 sera retirée dans une version ultérieure, afin de profiter au mieux des dernières fonctionnalités du langage C++.

À peu près toutes les autres plateformes ont également eu droit à quelques mises à jour, notamment côté Oculus Rift (réalité virtuelle), mais aussi les consoles Xbox One et PlayStation 4 (avec une compatibilité avec la technologie PlayStation VR !). Bon nombre de défauts ont été corrigés pour Linux.

Source et images : Unreal Engine 4.10 Released!

Sortie de Nim 0.12

Publié le par
Répondre

Nim (connu, jusqu’il y a peu, sous le nom de Nimrod) est un langage de programmation « moderne » (comme c’est à la mode) aussi performant que le C (souvent indiqué comme une référence à ce niveau) : de manière générale, il souhaite donner un maximum de puissance à l’utilisateur sans sacrifier la performance (comme Rust ou Julia). Au niveau de ses caractéristiques, son système de typage est statique et son style impératif, bien que le langage soit multiparadigme : il mélange métaprogrammation, fonctionnel, passage de messages, procédural et orienté objet, avec un ramasse-miettes. Il ne dispose pas d’un compilateur, mais d’un transcompilateur, qui produit du code C, C++ ou Objective-C en sortie… ou encore en JavaScript, ce qui facilite l’intégration avec l’environnement extérieur (il est aussi très facile d’appeler des fonctions externes C).

De manière générale, la syntaxe rappelle Python (pour la délimitation des blocs) et Scala (pour les types et certaines syntaxes raccourcies), avec des types, mais aussi le renvoi implicite d’une variable (ce qui contribue à raccourcir le code… avec un peu d’habitude) :

proc reverse(s: string): string =
  result = ""
  for i in countdown(high(s), 0):
    result.add s[i]

var str1 = "Reverse This!"
echo "Reversed: ", reverse(str1)

La métaprogrammation est poussée plus loin qu’en C++ : elle permet de générer n’importe quel type de code à la compilation, en travaillant directement au niveau de l’AST du compilateur. Par exemple, la fonction suivants génère des fonctions dont le nom dépend des arguments. (Bien évidemment, ce système peut être utilisé dans des cas plus complexes.)

import macros

template abcProc(n: expr): stmt  =  
  proc n() = echo astToStr(n)

abcProc(A)
abcProc(B)
abcProc(C)

L’un des concepts principaux derrière le langage concerne les aspects parallèles : chaque fil d’exécution peut communiquer avec les autres à l’aide de messages asynchrones, des canaux. Le ramasse-miettes peut donc fonctionner indépendamment pour chaque fil d’exécution : même en en mettant un en pause, l’application peut toujours fonctionner ; ce système est donc adapté aux applications qui ne sont pas strictement temps réel, comme les jeux (mais contrairement à une bonne partie de l’électronique). Cependant, ces mécanismes sont encore expérimentaux.

Cette nouvelle version apporte pas mal de changements qui cassent la rétrocompatibilité, comme l’envoi d’exceptions lors de l’accession à une clé non existante dans une table de hachage (au lieu d’un null). La grande nouveauté est cependant NimScript, un sous-ensemble très léger du langage qui peut être exécuté dans la machine virtuelle incluse, déjà notamment utilisée pour l’évaluation de fonctions lors de la compilation ; maintenant, ce système peut également être utilisé de manière plus générale, notamment pour remplacer le système de configuration existant. Par contre, l’accès au code C n’est pas encore possible, ce qui limite fortement les possibilités, mais est largement suffisant pour une description d’un paquet ou pour des scripts d’installation et de compilation.

Sources : Nim version 0.12.0 released, Nim (programming language), Nimrod: A New Systems Programming Language, A cursory look at meta-programming in Nim.

Sortie de LXQt 0.10

Publié le par
Répondre

Quelques mois après la version 0.9, la nouvelle version de LXQt est sortie, avec le numéro 0.10. Cet environnement de bureau léger pour Linux basé sur Qt continue à gagner en maturité, avec de nombreuses améliorations ergonomiques et nouvelles traductions.

Les panneaux ont été l’objet de nombreux travaux. Ils peuvent maintenant se cacher automatiquement pour libérer de la place à l’écran, grouper plusieurs icônes d’une même application, en plus de gérer le glisser-déposer d’icônes. Le gestionnaire de fichiers PCManFM a vu sa fonctionnalité de recherche s’améliorer ; il peut aussi être contrôlé avec les boutons avancer-reculer de certaines souris.

La partie principale du travail a cependant porté sur l’amélioration de la qualité du code de l’environnement. Notamment, la version précédente a commencé à utiliser les KDE Frameworks, des bibliothèques généralistes issues de l’environnement KDE ; celle-ci exploite désormais Solid, la couche orientée matériel, qui détecte notamment les nouveaux périphériques branchés, sans dépendance explicite envers le système d’exploitation. De même, libkscreen remplace l’utilisation de xrandr pour la configuration du serveur X, tout en étant compatible avec Wayland ; en passant, l’interface a été complètement repensée. L’élévation de privilèges est désormais gérée par le module lxqt-sudo, à travers les commandes lxsu et lxsudo.

Sources : LXQt 0.10 Released!, [ANN] LXQt 0.10 released!.

Merci à Claude Leloup pour ses corrections.

Sortie de NVIDIA Nsight Visual Studio Edition 5.0

Publié le par
Répondre

NVIDIA Nsight est une extension à Visual Studio (ou Eclipse) lui ajoutant diverses fonctionnalités dans le domaine du calcul sur GPU au sens large : l’outil est prévu pour des technologies de calcul pur (CUDA, OpenCL, DirectCompute) et de rendu 3D (Direct3D, OpenGL).

Cette nouvelle version, estampillée 5.0, est maintenant compatible avec Visual Studio 2015 (sauf pour les applications CUDA 7.5 !). Côté graphique, le débogage fonctionne également avec Direct3D 12, même si la majorité des fonctionnalités habituelles ne sont pas encore disponibles pour cette version (principalement celles axées sur l’analyse de la performance), mais devraient l’être dans une prochaine version. Les applications OpenG 4.4 et 4.5 sont aussi mieux gérées.

Pour le calcul proprement dit, les instantanés produits par le pilote en cas de plantage peuvent être ouverts dans Visual Studio pour une analyse plus détaillée. Les outils d’analyse sont désormais compatibles avec OpenCL 1.2. (NVIDIA étant largement en retard à ce niveau, AMD ayant déjà publié des pilotes compatibles OpenCL 2.0) Il devient également possible de déboguer et de profiler des applications CUDA distantes (à condition d’utiliser CUDA 7.5). Les systèmes d’exploitation 32 bits ne sont plus pris en charge et les processeurs de génération Fermi (GeForce 400/500, distribués jusqu’en 2012) ne le seront plus à la prochaine version.

Sources : Nsight Visual Studio Edition 5.0 New Features , Release Notes.

Sortie de GSL 2.0

Publié le par
Répondre

La GNU Scientific Library est une bibliothèque de fonctions en C qui s’occupe de calcul numérique : elle fournit des générateurs de nombres aléatoires, des fonctions spéciales (fonctions de Bessel, intégrales elliptiques, polynômes de Laguerre généralisés, etc.), une implémentation de BLAS pour l’algèbre linéaire, etc. La version précédente, numérotée 1.16, est sortie en juillet 2013.

GSL 2.0 apporte des nouveautés significatives, notamment au niveau des matrices creuses, dont un solveur de systèmes linéaires utilisant l’algorithme GMRES. Le module de régression aux moindres carrés peut maintenant utiliser une formulation robuste, avec une régression d’arête (aussi dite de Tychonoff) ; de même, de nouvelles fonctions s’occupent de la régression non linéaire, comme lmniel pour des systèmes avec beaucoup de données. Pour l’interpolation, de nouvelles techniques 2D ont été implémentées : l’interpolation bilinéaire et bicubique.

La version majeure a augmenté suite à certains changements plus profonds : l’API a légèrement évolué pour certaines fonctions, d’autres ont été supprimées ; l’architecture interne de la bibliothèque a également évolué, de telle sorte que la compatibilité binaire n’est plus assurée (pour profiter de cette nouvelle version, les binaires existants devront être recompilés).

Source : GNU Scientific Library 2.0 released.

OpenMP 4.1 sera nommé 4.5

Publié le par
Répondre

Le premier brouillon d’OpenMP 4.1 a été publié en juillet et son implémentation a déjà débuté côté GCC. Un récent message sur la liste de diffusion du compilateur indique que cette nouvelle version aura pour numéro 4.5, à cause des changements importants apportés au niveau de la spécification. La rétrocompatibilité sera cependant parfaite avec le code OpenMP 4.0. La version finale est toujours attendue pour la conférence SC15 (supercomputing 2015, du 15 au 20 novembre).

Les fonctionnalités principales attendues pour cette prochaine révision sont la définition de priorités pour les tâches, une première API pour l’affinité de la mémoire et une meilleure compatibilité avec Fortran 2003 (seules dix limitation sont encore listées dans la norme). En outre, les références en C++ sont mieux gérées, les différentes itérations d’une boucle pourront être réparties entre des tâches différentes (directive taskloop) et les dépendances pourront être indiquées.

Plus spécifiquement, pour les dépendances, les directives utilisant la construction ordered (utilisée pour indiquer que les itérations de la boucle doivent avoir lieu de manière séquentielle dans une section parallélisée) pourront prendre un paramètres pour indiquer le nombre de boucles associées à cette directive. Une clause simd limitera le bloc à une unité d’exécution SIMD.

Le travail sur OpenMP 5.0 commence déjà. La sortie est prévue en 2017 (une estimation déjà dite optimiste), avec au menu une meilleure compatibilité avec les versions les plus récentes de C, C++ et Fortran (C11, C++14, Fortran 2003), une interopérabilité avec pthreads, mais aussi la mémoire transactionnelle ou du parallélisme en dehors des régions déclarées parallel.

Sources : OpenMP 4.1 is dead, long live OpenMP 4.5, OpenMP 4.1 Morphs Into OpenMP 4.5, OpenMP 4.1 and 5.0 Progress, OpenMP 4.1 TR3.

Sortie de Julia 0.4

Publié le par
Répondre

À peine un mois après la sortie de sa RC 1, plus d’un an après sa dernière version mineure (0.3 en août 2014), la version finale de Julia 0.4 est sortie. Ce langage de programmation assez récent est principalement prévu pour le calcul scientifique. Similaire à MATLAB au niveau de la syntaxe, il est de très haut niveau et dynamique, tout en atteignant une performance comparable aux langages statiques comme C ou Fortran.

Pour les utilisateurs, les nouveautés principales de cette version mineure concernent la performance : la compilation incrémentale des paquets, ce qui réduit fortement le temps de chargement des plus lourds d’entre eux ; le ramasse-miette est passé à une implémentation par générations, ce qui améliore la performance dans les cas les plus fréquents par rapport à l’implémentation traçante précédente ; des canaux de communication entre tâches plus rapides. Les types des tuples ont complètement changé, passant de (A,B) à Tuple{A,B}, ce qui est plus cohérent ; de plus, cette refactorisation autorise la graphie field::NTuple{N,T} pour désigner des tuples de N éléments d’un même type.

Les développeurs de paquets se réjouiront de la finalisation d’autres fonctionnalités, comme la surcharge des appels de fonction (y compris les constructeurs) pour n’importe quel objet (et pas seulement la fonction elle-même) ; en particulier, il devient possible de définir des constructeurs pour des types abstraits. Les fonctions générées donnent un contrôle bien plus grand sur la spécialisation des fonctions lors de la compilation : ces fonctions retournent un code en fonction du type des paramètres (et non une valeur en fonction des valeurs des paramètres pour les fonctions traditionnelles).

De manière générale, Julia 0.4 a aussi été l’occasion d’améliorer la performance (réduction des vérifications effectuées lors de l’adressage tout en garantissant le même niveau de sécurité) et la flexibilité des tableaux à plusieurs dimensions, des vues sur ces tableaux (SubArray) et de l’itération (avec par exemple la fonction eachindex() pour itérer sur tous les éléments d’un tableau, peu importe le nombre de dimensions, en garantissant une performance optimale) ; les changements implémentés sont listés dans un métaticket. Plus de changements sont prévus pour Julia 0.5, détaillés dans le métaticket Arraypocalypse.

La communauté Julia a aussi gagné en maturité depuis l’instant de mise à disposition de la version 0.3. Notamment, une série de paquets ont atteint une belle maturité : JuliaOpt pour l’optimisation ; JuliaStats pour les statistiques et l’apprentissage automatique ; JuliaGPU pour l’accès au GPU ; IJulia, une interface en feuilles de calcul basée sur IPython ; Images.jl pour le traitement d’images ; Gadfly et Winston pour les graphiques ; Juno comme environnement de développement.

Source : Julia 0.4 Release Announcement.

Merci à Claude Leloup pour ses corrections.