AMD annonce sa prochaine architecture de GPU, dénommée Polaris

Publié le par
Répondre

AMD tente depuis quelques mois de redorer son blason par la communication, avec un retour dans le monde du HPC suivi du projet GPUOpen. Faisant suite à des années de recherche et développement, le groupe vient d’annoncer sa nouvelle architecture pour les processeurs graphiques (principalement pour la gamme Radeon, puis pour les APU des séries A, C et E), dénommée Polaris.

Ce nom de code a été choisi en référence aux étoiles : l’étoile polaire (Polaris en latin) est la plus brillante de la constellation de la Petite Ourse. AMD indique que cette architecture proposera un saut historique en performance par watt consommé, tout comme les étoiles sont des processus extrêmement efficaces pour générer de la lumière. De fait, l’objectif affiché est de multiplier la performance par watt consommé par un facteur de deux et demi — là où NVIDIA propose un saut d’un facteur deux avec son architecture Pascal, sachant qu’ils partent de puces moins gourmandes qu’AMD.

Une affaire de FinFET

Ce saut est en bonne partie dû au changement de technologie pour la gravure des puces, c’est-à-dire leur réalisation effective à partir de silicium : la résolution de la lithographie sur le semiconducteur passe de vingt-huit nanomètres à quatorze et les transistors sont réalisés en trois dimensions plutôt que deux (FinFET). En d’autres termes, les transistors des nouveaux GPU seront beaucoup plus petits et consommeront moins d’énergie — et pourront fonctionner à une fréquence plus élevée. (Dans le même temps, NVIDIA fait le même changement de processus de fabrication.)

De plus, pour continuer à améliorer la performance et l’efficacité énergétique, AMD a implémenté une série de nouvelles fonctionnalités, comme un ordonnanceur de tâches au niveau du GPU (et non seulement pour le pilote du côté du système d’exploitation), la prélecture des instructions à effectuer ou encore la compression des données lues en mémoire. Cette prélecture est une fonctionnalité qui se trouve depuis longtemps dans les processeurs traditionnels (CPU) pour limiter les temps d’attente de la mémoire, mais relativement complexe à gérer ; elle arrive maintenant dans les processeurs graphiques (GPU), ce qui montre à quel point ces processeurs deviennent eux aussi extrêmement compliqués dans leur conception.

Beaucoup de nouveautés… pas encore vraiment divulguées

En réalité, cette gestion de la mémoire n’est qu’un des nouveaux éléments de cette nouvelle architecture : dans une description fonctionnelle de ces nouveaux GPU, énormément de blocs sont nouveaux ou fortement retravaillés, notamment avec un contrôleur mémoire plus costaud. Selon la gamme de prix, la mémoire embarquée devrait être de type GDDR5 (comme la plupart des GPU actuels) ou HBM (avec une bande passante supérieure).

De même, de nouvelles technologies devraient être incluses, comme DisplayPort 1.3 et HDMI 2.0a pour la connectique ou un codec H.265 (aussi connu comme HEVC) pouvant fonctionner à soixante images par seconde en résolution 4K, tant en encodage qu’en lecture. AMD aimerait également élargir le public utilisant des écrans à large gamut, avec une gestion native des couleurs codées sur dix bits (au lieu des huit habituels) — y compris pour le codec HEVC.

Cependant, AMD reste relativement silencieux quant aux détails de ces blocs, plus devant être révélé à proximité de la sortie effective de ces produits, prévue pour la mi-2016 (les plans de NVIDIA semblent indiquer que la concurrence sera rude à ce moment, leur architecture Pascal étant également prévue dans ces eaux-là).

Sources : AMD Announces Polaris, 2016 Radeon Graphics Architecture To Bring A Historic Leap In Perf/Watt With 14nm / 16nm FinFET Process, AMD Reveals Polaris GPU Architecture: 4th Gen GCN to Arrive In Mid-2016.

Un algorithme quasipolynomial pour l’isomorphisme de graphes

Publié le par
Répondre

La théorie de la complexité, en informatique, classifie les problèmes selon leur difficulté intrinsèque, c’est-à-dire selon la complexité en temps de l’algorithme le plus efficace pour les résoudre. Par exemple, pour trier un tableau, il existe une multitude d’algorithmes : le tri par insertion, le tri par fusion, le tri par tas ou encore, le plus célèbre, le tri rapide. Les plus efficaces ont une complexité pseudolinéaire : pour trier n éléments, il leur faudra \Theta\left( n \log n \right ) opérations ; d’autres algorithmes, comme le tri par insertion, ont une complexité quadratique : le nombre d’opérations évolue comme \mathcal{O}\left( n^2 \right ). Les premiers algorithmes pourront trier des tableaux beaucoup plus grands que les seconds, peu importe le langage de programmation utilisé ou la minutie d’implémentation.

Classes de complexité

En réalité, la théorie de la complexité distingue deux catégories principales de problèmes : ceux qui acceptent une solution en un temps polynomial (des problèmes « faciles »), comme le tri, la recherche de plus court chemin, la multiplication matricielle (ils forment l’ensemble \mathcal{P}), puis ceux pour lesquels aucun algorithme polynomial n’est connu, comme le voyageur de commerce ou l’analyse de formules en logique (\mathcal{NP}). Une contrainte supplémentaire pour être dans \mathcal{NP} est qu’il soit possible de vérifier si une réponse est acceptable en un temps polynomial : pour le voyageur de commerce, il suffit de vérifier que toutes les villes sont visitées. Par contre, pour trouver la solution optimale, il n’y a pas de technique qui soit vraiment meilleure que d’explorer toutes les possibilités (du moins, d’un point de vue théorique : il reste possible de résoudre de grandes instances en des temps raisonnables).

En informatique théorique, un problème récurrent est de savoir si \mathcal{P}=\mathcal{NP}. Aucune preuve n’a pu être avancée jusqu’à ce jour, malgré des dizaines d’années d’essais. Si cette égalité était vérifiée, il deviendrait possible de résoudre tous ces problèmes « difficiles » en un temps polynomial — ce qui pourrait changer la face du monde. Rares sont ceux, cependant, qui croient que ces deux classes coïncident : si tel était le cas, on aurait déjà trouvé un algorithme polynomial pour ces problèmes.

Isomorphisme de graphe

Il existe également des problèmes dont on ne sait pas encore s’ils sont dans \mathcal{P} ou \mathcal{NP}, comme l’isomorphisme de graphes. Il s’agit de déterminer si deux graphes ont la même structure (ils sont alors dits isomorphes), c’est-à-dire si leurs points peuvent correspondre entre eux tout en gardant les liens entre ces points. (Par exemple, les relations d' »amitié » dans un réseau social comme Facebook peuvent être représentées avec des points pour les individus et des liens pour ceux qui se sont déclarés « amis ».)

Les applications de ces isomorphismes sont nombreuses, telle la reconnaissance de l’unicité d’un visiteur sur un site Web de par son comportement ou l’identification de régions pour implanter des infrastructures lors d’une réflexion urbanistique. Un bon nombre de ces applications est cependant de haut vol, comme pour l’optimisation du code dans un compilateur ou, en informatique théorique, la vérification de programmes, notamment dans des contextes parallèles, ou encore l’égalité des langages reconnus par des automates.

L’avancée de László Babai

Récemment, László Babai a prouvé qu’il existait un algorithme de complexité quasipolynomiale pour résoudre ce problème d’isomorphisme, c’est-à-dire qu’il nécessite un nombre d’opérations \mathcal{O}\left( \exp \left( \log^c n \right ) \right ) (le cas où c=1 étant polynomial), par rapport à \mathcal{O}\left( \exp \sqrt{n \log n} \right ) précédemment. Même si l’avancée semble faible, ce résultat montre que l’isomorphisme a une classe de complexité inférieure à \mathcal{NP} (mais n’est pas forcément dans \mathcal{P}).

Toutefois, cet algorithme et les détails de la preuve ne sont pas très accessibles, exploitant la théorie des groupes et les automorphismes de mots. De plus, ce résultat n’aura pas beaucoup d’implications pratiques à court terme : ceux qui en ont besoin peuvent d’ores et déjà résoudre des isomorphismes suffisamment rapidement pour leurs besoins. Certes, ce nouvel algorithme a des garanties théoriques, mais il n’a pas encore fait ses preuves en pratique pour les cas les plus courants.

Et alors ?

László Babai a reçu le prix Knuth cette année, décerné par l’ACM, pour ses « contributions fondamentales dans les domaines de la conception d’algorithmes et d’analyse de la complexité ». Le résultat obtenu pour les isomorphismes de graphes est important pour plusieurs raisons, principalement théoriques. Notamment, le lien entre propriétés des groupes et des graphes (les principes sous-jacents pourraient mener rapidement à d’autres résultats du même genre en théorie de la complexité, peut-être même pour donner un algorithme polynomial pour les isomorphismes de graphes). Il faut aussi remarquer que la preuve n’a pas encore été publiée dans une revue avec comité de relecture, mais sur arXiv.

Ce résultat a donc principalement des vertus théoriques. Il pourrait aussi, en pratique, éliminer les parties aléatoires des heuristiques utilisées pour résoudre ces isomorphismes pour n’utiliser que des algorithmes plus classiques dans leur manière de fonctionner ; l’avantage serait alors une bien meilleure prédictibilité des résultats. Il pourrait aussi questionner les pratiques actuelles en cryptographie, en abaissant la classe de complexité du problème de factorisation des nombres entiers.

Voir aussi l’article de László Babai.

Sources : Comparaison de graphes, what are the applications of the isomorphic graphs?, A Big Result On Graph Isomorphism.

Qt et les garanties de compatibilité binaire vues par Fedora

Publié le par
Répondre

Qt a des principes assez stricts en ce qui concerne la compatibilité entre versions : par exemple, si une application fonctionne parfaitement avec Qt 5.0.0, elle continuera à fonctionner avec Qt 5.0.1 sans recompilation (aux défauts corrigés près) et vice-versa : c’est une compatibilité tant ascendante que descendante.

Au contraire, les versions mineures (Qt 5.1, 5.2, etc.) ne garantissent qu’une compatibilité ascendante : si une application est compilée avec Qt 5.0, elle fonctionnera avec Qt 5.1 sans nécessiter de recompilation de l’application — une compatibilité descendante serait ici impossible, car de nouvelles fonctionnalités font leur apparition d’une version à l’autre. Par contre, une version majeure peut casser cette compatibilité : pour passer de Qt 4 à 5, il a été nécessaire de recompiler toutes les applications et d’en retoucher légèrement les sources. Toutefois, les modules d’extension de Qt ne sont pas sujets aux mêmes garanties.

Ces garanties facilitent la vie des distributeurs de logiciels, particulièrement pour les distributions Linux : une version partagée de Qt suffit pour tout le système, elle peut être mise à jour indépendamment des applications — ce qui limite fortement l’utilisation de bande passante pour les mises à jour, économise de l’espace disque et permet la correction de défauts rapidement.

Un casse-tête pour les développeurs…

Pour atteindre ces objectifs, les développeurs de Qt doivent faire attention à deux points : les compatibilités au niveau des sources et des binaires. La première est relativement simple : l’interface de programmation doit rester identique d’une version à l’autre, les ajouts étant autorisés ; par conséquent, une fonction ne peut pas changer de prototype (un nouveau paramètre ne peut pas devenir obligatoire d’une version à l’autre). Par le principe d’encapsulation, une classe peut être réimplémentée complètement sans casser cette compatibilité des sources.

Par contre, la compatibilité binaire est plus épineuse : elle est atteinte quand un programme qui lie dynamiquement une version plus ancienne de Qt peut être utilisée avec de nouvelles versions de Qt sans recompilation de l’application. Alors qu’il est souvent bénin d’ajouter des fonctions sans casser la compatibilité binaire, il est impossible de changer la taille d’un objet en mémoire, car cela casserait les mécanismes d’allocation dynamique. Ces modifications doivent alors être planifiées pour la prochaine version majeure, où la recompilation sera nécessaire. De même, rendre une fonction constante change le nom du symbole associé, c’est-à-dire que le système d’exploitation ne la trouvera plus dans la bibliothèque partagée.

… et pour les distributions Linux

La compatibilité binaire facilite fortement la maintenance d’une distribution Linux, mais il faut s’assurer qu’elle est bien respectée. Pour ce faire, Fedora s’est dotée d’un nouvel outil : ABI Tracker. Il remplace le Linux Upstream Tracker, qui n’est plus mis à jour.

Ainsi, les mainteneurs de la distribution peuvent réagir pour chaque non-respect de la compatibilité binaire et décider de mettre à jour telle ou telle bibliothèque : ils peuvent prédire la quantité de dysfonctionnements à attendre de cette opération. Il peut s’agir d’un comportement erratique du programme (par exemple, un symbole de plus dans une énumération : les tests sur la valeur peuvent alors échouer), voire d’un plantage pur et simple lorsque l’exécution passe à un point donné du programme (un symbole n’existe plus). Par exemple, le module Qt Core a eu tous ces problèmes en passant de la version 5.1.1 à 5.2.0, selon l’outil de Fedora.

Qt respecte-t-il ses principes de compatibilité ?

En regardant la page montrant l’évolution de Qt, une chose saute à l’Å“il : la garantie de compatibilité binaire est loin d’être respectée depuis Qt 4.7 (sorti fin 2010), sauf pour les dernières versions correctives de Qt 4.8.

Ce constat mérite néanmoins d’être nuancé. Pour Qt 5.0, le score de zéro pour cent est totalement justifié, étant donné que c’était l’objectif du changement de version majeure. Pour Qt 5.6, la prochaine version avec support à long terme, le score est catastrophique, avec moins de nonante pour cent au lieu des cent promis ; en regardant le détail, on se rend compte qu’une bonne partie est due à une erreur d’empaquetage, Qt 3D étant inclus dans le rapport précédent, alors que ce module est loin d’être finalisé ; d’autres modules ont été supprimés et n’aident pas le score.

Plus en détail, pour le module Qt Quick, qui n’atteint qu’un score de 92,3 %, une bonne partie des symboles supprimés correspond à une classe qui n’a jamais fait partie de l’API publique (DesignerSupport). Le tiers restant correspond néanmoins aux destructeurs de classes publiques. A contrario, les dernières versions correctives de Qt 4.8 ne posent strictement aucun souci.

Bien évidemment, cette vision est partielle, parce qu’elle est obtenue avec un outil générique, qui ne prend pas en compte certaines spécificités de Qt (les API privées). Il n’empêche que certaines modifications semblent casser cette compatibilité, sans qu’elles ne posent de problème spécifique aux mainteneurs.

Sources : Qt Version Compatibility, Future of the Linux upstream tracker.

Voir aussi : Pensées sur la compatibilité binaire et sur les conventions d’appel.

En réponse à GameWorks, AMD annonce GPUOpen

Publié le par
Répondre

Depuis quelques années, NVIDIA a lancé sa suite de bibliothèques logicielles baptisée GameWorks. Elles sont spécifiquement prévues pour le jeu vidéo et donnent la possibilité aux développeurs d’intégrer aisément des effets, comme la simulation de poils en tout genre avec HairWorks ou encore d’herbe avec Turf Effects. La famille compte aussi GameWorks VR, qui promet d’importants gains en performance pour les jeux exploitant la réalité virtuelle.

NVIDIA met en avant l’optimisation effectuée sur ces implémentations et la facilité d’intégration, ce qui décharge les studios d’une bonne partie du travail… sauf qu’il semblerait que l’optimisation peut se faire au détriment d’AMD. L’exemple de Witcher 3 a montré que HairWorks exploitait un point fort du matériel vendu par NVIDIA, la tesselation — ce qui nuisait fortement à la performance sur les cartes AMD.

Une stratégie : l’ouverture

Justement, AMD prépare sa réponse à GameWorks sous le nom de GPUOpen, en arrêtant de se focaliser sur l’aspect matériel du jeu vidéo. La différence principale par rapport à GameWorks est la licence du code : là où les bibliothèques GameWorks sont disponibles gratuitement après enregistrement, sous une licence propriétaire peu restrictive (les sources sont disponibles sur demande sous licence), AMD envisage de proposer ses bibliothèques GPUOpen comme logiciels libres, sous licence MIT, distribués sur GitHub, dès janvier. Rien n’indique cependant que le développement aura bien lieu sur GitHub et que les contributions seront facilement acceptées (y compris les optimisations pour le matériel autre que celui d’AMD).

Cet élément n’est pas le premier de la stratégie actuelle de AMD. Peu auparavant, ils avaient annoncé une couche de compatibilité avec CUDA, la technologie propriétaire de calcul sur processeur graphique de NVIDIA. AMD a aussi lancé une nouvelle version de leurs pilotes pour carte graphique, dénommée Radeon Software Crimson Edition, qui a apporté un tout nouveau panneau de configuration, bien plus pratique à l’usage que le précédent, ainsi qu’une performance améliorée pour les jeux (bien qu’invisible sous Linux). Globalement, AMD essaye de rattraper son retard par rapport à ses concurrents du côté PC — malgré son omniprésence sur le marché des consoles.

Du contenu pour les jeux…

Dans les bibliothèques disponibles, une bonne partie du contenu sera tout à fait nouveau. Il y aura bien sûr TressFX, sa solution de simulation de cheveux, poils et brins d’herbe, dans la version 3.0. Elle était déjà disponible gratuitement, sources comprises, sur le site d’AMD — un mécanisme moins facile d’accès que GitHub. Également, AMD devrait rendre disponibles en janvier les bibliothèques GeometryFX (opérations géométriques ou simulation physique, selon les sources), ShadowFX pour les ombres et AOFX pour l’occultation ambiante. AMD inclura ses exemples de code, tant pour DirectX 11 et 12 qu’OpenGL.

Les bibliothèques proposées ne devraient pas seulement s’étendre du côté des effets pour des jeux vidéo, avec notamment LiquidVR pour la réalité virtuelle, le moteur de rendu par lancer de rayons FireRender et la bibliothèque de lancer de rayons FireRays, RapidFire pour le déploiement dans le nuage. Pour faciliter le développement, AMD devrait aussi fournir CodeXL pour l’analyse statique de code (y compris pour DirectX 12) et Tootle pour le prétraitement des maillages des modèles 3D à afficher afin d’améliorer la performance au rendu (même si le développement de cet outil a officiellement cessé en 2010).

… mais pas seulement !

GPUOpen ne profitera pas seulement au secteur du jeu vidéo, mais aussi pour le calcul de haute performance, l’initiative Boltzmann étant incluse sous ce nom, avec un nouveau compilateur HCC, un pilote pour Linux spécifiquement optimisé pour le calcul sur GPU ou encore HIP pour la compatibilité avec CUDA.

Ils participent aussi au projet Caffe, actif dans le domaine de l’apprentissage profond (technique notamment utilisée avec succès dans la vision par ordinateur), pour lequel ils optimisent une version OpenCL (sans indiquer d’avantage en performance par rapport à cuDNN, l’option de NVIDIA).

Du libre aussi pour Linux

Le dernier point mis en avant par AMD pour ce projet GPUOpen est la mise en place effective de leur architecture de pilote libre pour leurs cartes graphiques. La performance des pilotes actuellement fournis par AMD n’est pas optimale pour tous les types d’utilisation, étant parfois largement dépassés par l’implémentation complètement libre Radeon — les deux étant souvent décrits comme largement en deçà des attentes, notamment pour les machines Steam.

La nouvelle architecture, déjà annoncée l’année dernière, s’articule autour d’une partie libre — AMDGPU —, directement incluse dans le noyau Linux. Cette partie n’aura aucune implémentation des piles graphiques telles que OpenGL ou Vulkan — totalement inutiles dans les applications de calcul pur.

Ensuite, les implémentations libre et propriétaire pourront diverger pour tout ce qui concerne OpenGL, l’accélération du décodage de vidéos, OpenCL et HSA. L’implémentation propriétaire d’OpenCL et de Vulkan devrait être distribuée en libre dans le futur, un mouvement qui n’est pas encore prévu pour OpenGL. Les fonctionnalités spécifiques aux cartes professionnelles FirePro seront, bien évidemment, uniquement propriétaires, même si rien n’empêche l’implémentation libre de les fournir.

Ces suppléments au pilote noyau fonctionneront entièrement en espace utilisateur, ce qui devrait améliorer la sécurité de l’implémentation et diminuer le nombre de changements de contexte utilisateur-noyau.

Sources : présentation d’AMD, Direkte Kontrolle der Radeon-Hardware für Spieleentwickler, AMD Further Embraces Open Source with GPUOpen, for Games and Compute, AMD embraces open source to take on Nvidia’s GameWorks.

Merci à Claude Leloup pour ses corrections.

GammaRay 2.4.0 à proximité

Publié le par
Répondre

GammaRay est un outil de débogage et d’introspection développé spécifiquement pour les applications Qt. Contrairement aux débogueurs classiques (GDB, LLDB ou autres, intégrés ou non aux environnements de développement intégrés), il comprend Qt et son mécanisme de fonctionnement, avec les connexions de signaux et slots, la hiérarchie des objets. Il donne donc, de manière générale, une vue de plus haut niveau du comportement de l’application, en comprenant parfaitement la structure de composants de Qt comme les QGraphicsView ou le graphe de scène Qt Quick — là où un débogueur traditionnel ne peut se placer qu’au niveau de l’instruction machine, avec parfois des extensions pour Qt, notamment pour afficher correctement la valeur de certaines variables, ce qui devient plus délicat encore pour le code généré par le moc.

Un deuxième gros avantage de GammaRay est son aspect visuel : il est capable de générer une visualisation de parties complètes de l’application pour en faciliter le débogage, plus particulièrement quand les éléments s’imbriquent l’un dans l’autre. Par exemple, il peut afficher les machines d’état et leur évolution, le contenu des modèles, les liens complexes entre signaux et slots : au lieu d’aller rechercher ces éléments disparates au fond des structures de données de Qt, il les rassemble tous dans une vue unique.

De plus, il ne fait pas que lire les objets : il peut aussi les modifier, en utilisant les facilités offertes par QObject. En effet, malgré toute la puissance du langage et l’importance de son écosystème, Qt utilise du C++ et a toujours besoin d’un étape de compilation, que ce système permet d’éviter pour une série de cas lors d’une séance de débogage intensif dans une application complexe. Ainsi, un développeur peut modifier une bonne partie du comportement de l’application à l’exécution, tout comme les développeurs Web exploitent les outils offerts par les navigateurs modernes — qu’elle soit basée sur Qt Quick, Qt Widgets, QGraphicsView… ou toute combinaison des trois !

La version 2.4.0 arrive très bientôt et apporte pas mal d’améliorations côté Qt Quick, notamment les propriétés attachées et la navigation dans les items. Pour les propriétés de type composite, l’éditeur peut maintenant agir en mode récursif. La gestion des erreurs et avertissements gérés par la classe QMessageLogger (ce qui inclut notamment les fonctions qDebug, qCritical, etc.) a été retravaillée, principalement au niveau de la liste des fonctions dans la pile au moment de l’appel.

Voir aussi les sources : site officiel, dépôt GitHub.

Sortie de Qt 5.6 Beta

Publié le par
Répondre

Qt 5.6 sera une version charnière dans l’histoire de Qt, mais pas vraiment au niveau des fonctionnalités : un support à long terme est prévu pour les trois prochaines années, tout comme ce fut le cas pour Qt 4.8.

Nouvelles fonctionnalités par rapport à Qt 5.5

La première préversion a apporté pas mal de nouveautés, notamment pour Qt 3D et diverses préversions technologiques (les nouveaux Qt Quick Controls, l’accès aux bus série par Qt SerialBus, la reconnaissance vocale et la synthèse vocale avec Qt Speech, la compatibilité avec le compositeur Wayland par Qt Wayland), ainsi que des améliorations de performance.

Cette nouvelle préversion, Qt 5.6 Beta, apporte une meilleure gestion des écrans à haute résolution sur toutes les plateformes, avec un ajustement automatique des tailles de police et des autres éléments d’interface, y compris quand l’utilisateur déplace une fenêtre sur un autre écran avec une densité de pixels différente.

La compatibilité avec Windows 10 est maintenant parachevée, tant pour les applications traditionnelles que WinRT, ces dernières pouvant être distribuées sur le Windows Store — grâce à Qt, la migration se fait en un coup de compilation. Visual C++ 2015 fait maintenant partie de la liste des compilateurs compatibles ; par contre, l’extension pour Visual Studio n’est pas compatible avec la version 2015.

Support à long terme

Le point le plus important de cette version est cependant son support à long terme (LTS), disponible pendant trois ans. La précédente version dans ce cas était Qt 4.8, sortie début 2013, dont le support s’achève ce mois-ci — Qt 5.6 devrait être disponible au premier trimestre 2016, ce qui laissera quelques semaines sans version à support à long terme. Après trois ans, comme pour Qt 4.8, il faudra souscrire un contrat d’extension de support auprès de Digia.

Ce « support à long terme » signifie que Qt 5.6 aura droit à des correctifs, tant pour la sécurité que pour la correction de défauts ou la compatibilité avec de nouveaux systèmes d’exploitation et des compilateurs plus récents autant que possible ; en d’autres termes, Qt 5.6 aura droit à une série de versions de patch, au lieu d’une à deux pour les autres versions mineures de Qt 5. Sur le côté, Qt continuera bien évidemment à évoluer, avec de nouvelles fonctionnalités dans les versions mineures ultérieures (Qt 5.7 et suivantes), mais elles ne seront pas réintégrées dans Qt 5.6, afin de garantir qu’une application utilisant Qt 5.6 continue à fonctionner après une mise à jour de Qt, sans grand risque.

Objectif : faciliter le développement ultérieur

Globalement, ce support à long terme permettra de simplifier le code pour Qt 5.7, après une phase de développements pour mettre les différentes plateformes sur un pied d’égalité au niveau des fonctionnalités offertes pour Qt 5.5 et 5.6. Ces simplifications pour Qt 5.7 se feront parfois au détriment de fonctionnalités et de couches de compatibilité dépassées.

Les modules désapprouvés ne font pas partie de cette offre de support à long terme, ils devraient être rapidement supprimés. Cette liste contient Qt Script et Qt Enginio — sachant que Qt WebKit et Qt Declarative ne sont plus livrés dès cette version, remplacés respectivement par Qt WebEngine et Qt Quick 2, par suite de la décision de les désapprouver pour Qt 5.5.

De même, les préversions technologiques ne sont pas incluses, aucune garantie n’est fournie à leur égard : Qt 3D n’a toujours pas atteint un niveau de finition suffisan, à l’instar de Qt Quick Controls 2.0, de Qt Speech, de Qt SerialBus ou de Qt Wayland. Pour les compilateurs, Qt 5.6 sera la dernière version à maintenir la compatibilité avec C++98 et de vieux compilateurs, comme Visual C++ 2008 et 2010 ou encore GCC 4.6.

Sources : Qt 5.6 Beta Released, Introducing Long Term Support.

Calendrier 2016 pour Scala : la version 2.12 en vue

Publié le par
Répondre

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.

Altera annonce le premier FPGA lié à de la mémoire superposée HBM2

Publié le par
Répondre

Pour les processeurs graphiques, une limite fondamentale est depuis longtemps la mémoire, très lente par rapport aux débits que peut traiter un processeur : le bus est relativement rapide (de l’ordre de deux cents mégabits par seconde pour de la GDDR5), mais insuffisant pour tenir toutes les unités de calcul en activité (plus d’un térabit par seconde requis). L’avancée la plus récente (présente dans la série AMD Fiji et dans la prochaine génération côté NVIDIA) est le remplacement de cette mémoire par des composants embarqués sur la puce du GPU par le biais d’un interposeur (d’où l’appellation de « mémoire empilée »), notamment HBM (high bandwidth memory) — une technologie équivalente au HMC (hybrid memory cube) utilisé par Intel pour certains processeurs. Les gains promis en bande passante sont de l’ordre d’un facteur dix !

Cette technologie — HBM — est maintenant également disponible sur certains FPGA d’Altera, avec le même genre d’intégration. Par rapport aux processeurs traditionnels (CPU ou GPU), ils ont l’avantage d’être entièrement configurable : ils n’ont pas d’instructions fixes, puisque l’utilisateur peut assembler comme il le souhaite les portes logiques pour adapter le matériel à ses besoins. L’avantage n’est pas de traiter des tâches plus spécifiques (les processeurs traditionnels peuvent toutes les effectuer), mais bien plus efficacement (en temps ou en énergie).

Cette innovation sera utile dans les cas où la mémoire est une limite (pas tellement pour les gains en énergie, bien que la technologie permette de réduire par deux tiers l’énergie requise par bit transféré), comme dans l’apprentissage automatique ou le traitement de flux vidéo 8K : les quantités de données à gérer sont alors astronomiques, avec parfois des garanties de délai à maintenir — et empêche d’implémenter des fonctionnalités plus avancées, qui demandent plus de calculs.

Les premiers prototypes seront envoyés à des clients choisis en 2016 et seront disponibles plus largement en 2017. Avec le rachat d’Altera par Intel, il reste à voir si ces FPGA seront également intégrés dans certains processeurs Xeon Phi (les prochains seront pourvus de mémoire HMC), notamment pour contrer le partenariat entre IBM et Xilinx.

Source : communiqué de presse, Intel and Altera Develop World’s First HBM2, 2.5D Stacked, SiPs With Integrated Stratix 10 FPGA and SoC Solution.

[SC15] AMD lance l’initiative Boltzmann

Publié le par
Répondre

AMD s’est récemment lancé, comme Microsoft, dans une série d’actions d’ouverture de leur code source sous des licences libres, notamment au niveau de leurs pilotes pour Linux (AMDGPU). À un tout autre niveau, pour le calcul sur GPU, ils espèrent que leur architecture hétérogène (dite HSA) sera compatible avec les instructions de délégation de calcul d’OpenMP dans GCC 6 (qui devrait sortir début 2016), pour se mettre au même niveau qu’Intel (leur accélérateur Xeon Phi est déjà accessible par ce biais depuis GCC 5, c’est-à-dire début 2015). De même, ils explorent le côté LLVM des compilateurs libres, avec l’ouverture prévue du code de HCC, leur compilateur hétérogène pour leur plateforme HSA.

L’initiative Boltzmann prend le nom d’un physicien autrichien (ce qui n’est pas sans rappeler les noms de code des GPU NVIDIA), à l’origine de l’approche statistique en physique (ses travaux sont fondamentaux dans certaines utilisations actuelles des GPU). Cette initiative correspond à une revalorisation des GPU à destination des serveurs dans le marché du calcul de haute performance, avec notamment un pilote Linux prévu exclusivement pour le calcul sur ces GPU (sans aucune implémentation d’OpenGL). Leur compilateur HCC permettra d’y exécuter du code C ou C++ en utilisant OpenMP, un mécanisme de parallélisation assez général (pas initialement prévu pour les GPU), c’est-à-dire avec un seul et même langage et un seul compilateur pour une série de processeurs (de manière similaire au C++ AMP, proposé par Microsoft).

Une partie de cette initiative Boltzmann est prévue pour le portage des applications CUDA vers un « modèle de programmation C++ commun » aux différents types de processeurs disponibles, un modèle connu sous le doux nom de HIP (heterogeneous compute interface for portability). Il s’agit notamment d’effectuer une transpilation partielle du code CUDA, qui devrait être automatique pour nonante pour cent des cas courant — les dix pour cent restants devant être traduits à la main, ce décompte ne tenant pas compte de l’utilisation d’assembleur (PTX) ou de l’appel direct au pilote ; ce code transpilé sera toujours compilable pour les GPU NVIDIA. Au contraire, des applications CUDA compilées ne pourront pas directement être lancées sur un GPU AMD, ce qui nécessiterait l’implémentation complète dans le pilote d’une pile CUDA (et, accessoirement, une licence de la part de NVIDIA pour ce faire, déjà proposée dans le passé). Ce mouvement est absolument requis pour qu’AMD se relance dans la course du calcul scientifique de haute performance avec ses solutions GPGPU (et pas simplement des APU), au vu de la quantité de code CUDA existant.

Globalement, cette initiative Boltzmann matérialise un véritable retour en grande pompe dans le domaine du HPC, une niche très lucrative : le matériel existe déjà, mais l’environnement logiciel était encore défaillant pour reprendre des parts de marché, à Intel et NVIDIA. Les premiers résultats devraient arriver au premier trimestre 2016, avec des préversions. Restera à voir l’impact sur la performance.

Sources : AMD Launches ‘Boltzmann Initiative’ to Dramatically Reduce Barriers to GPU Computing on AMD FireProâ„¢ Graphics, AMD @ SC15: Boltzmann Initiative Announced – C++ and CUDA Compilers for AMD GPUs (images), AMD Plans To Contribute Heterogeneous Compute Compiler, AMD Working On CUDA Source Translation Support To Execute On FirePro GPUs.

[SC15] Collaboration entre IBM et Xilinx

Publié le par
Répondre

La conférence ACM/IEEE Supercomputing 2015 (SC15) est un haut lieu américain dédié aux superordinateurs, l’occasion pour les fabricants de présenter leurs dernières avancées dans de domaine. Ce lundi, IBM et Xilinx ont annoncé un partenariat stratégique autour de leurs FPGA et de leur intégration dans des systèmes OpenPOWER, principalement en ce qui concerne le calcul scientifique. Là où un processeur traditionnel (qualifié, par les électroniciens, d’ASIC — application-specific integrated circuit) est prévu uniquement pour certaines opérations, qui correspondent à des circuits gravés en dur dans le silicium, les FPGA (field-programmable gate array) peuvent se reconfigurer à l’envi : conceptuellement, ils peuvent créer des instructions spécifiques pour le traitement demandé, ce qui leur permet d’atteindre une performance extrême — et une efficacité énergétique plus importante.

De manière générale, les accélérateurs sont de plus en plus utilisés dans les superordinateurs pour contrebalancer la faiblesse de la croissance de la performance des CPU traditionnels. Par exemple, une bonne proportion du Top 500 des machines les plus puissantes au monde utilise ces accélérateurs (principalement des GPU) pour atteindre les sommets. Les FPGA sont également très présents sur le marché de niche du calcul de haute performance, notamment grâce à leur flexibilité : un CPU ou un GPU a une architecture invariable et adaptée à des situations différentes, quand un FPGA peut s’adapter à toutes les situations, bien qu’avec des fréquences moindres. Par exemple, Altera indique que, avec leurs produits, l’apprentissage d’un réseau neuronal profond peut s’effectuer deux fois plus vite que sur un GPU.

Pour l’instant, en calcul de haute performance, les FPGA sont plutôt intégrés comme des cartes d’extension, auxquelles le processeur principal peut accéder par le bus PCI Express (comme la gamme Virtex de Xilinx ou une des cartes proposées par Altera). L’objectif est d’arriver à un plus haut niveau d’intégration, comme Intel avec le rachat en juin d’Altera, grand concurrent de Xilinx — toujours pour tendre vers des systèmes de plus en plus intégrés, y compris comme AMD et ses APU, mêlant CPU et GPU sur une même puce.

Le niveau d’intégration de la technologie de Xilinx était déjà bon dans la plateforme POWER, en exploitant l’interface CAPI, spécifique à POWER et prévue pour la connexion vers tous les accélérateurs. Cette annonce marque surtout que les FPGA sont de plus en plus utiles et qu’IBM souhaite un partenariat plus privilégié avec au moins un fabricant qu’une simple compatibilité. Xilinx dispose maintenant d’un siège au conseil d’administration du consortium OpenPOWER, probablement au détriment d’Altera, suite au rachat par Intel.

Source : IBM and Xilinx Announce Strategic Collaboration to Accelerate Data Center Applications, IBM & Xilinx @ SC15: Collaborating For Better POWER/FPGA System Integration.