Simulation en temps réel de grandes déformations élastoplastiques

La simulation des objets déformables est un problème difficile à résoudre, plus encore quand il l’est en temps réel, par exemple dans un jeu vidéo. Il s’agit d’animer des objets (un ballon, par exemple) qui se déforment quand ils sont soumis à une force — au contraire des objets indéformables, comme un mur, sur lequel on peut s’appuyer sans qu’il se plie de manière perceptible. Dans le cas où ces déformations sont relativement limitées, la situation est gérable de manière relativement efficace — nettement moins pour des déformations importantes, où les résultats ne sont pas visuellement plausibles. Cela limite actuellement la créativité des développeurs, notamment de jeux vidéo, lorsqu’ils veulent intégrer des matériaux comme de la mousse ou de la pâte — ô combien utiles.

On distingue deux catégories de déformations : d’abord élastiques, le matériau se déforme puis revient à sa position d’origine (comme un élastique ou un ressort) ; puis plastiques, il ne revient pas à sa forme initiale (comme une latte en plastique que l’on plie). La simulation concerne surtout les matériaux qui passent d’un comportement à l’autre : ils s’appellent élastoplastiques. La simulation, actuellement, peut se faire pour des déformations élastiques importantes, mais pas dans le régime plastique.

C’est là qu’intervient une équipe de chercheurs (travaillant chez NVIDIA pour leur moteur PhysX), en poursuivant leurs travaux sur la dynamique par positions (PBD), déjà appliquée avec grand succès sur des fluides. Les problèmes de déformation élastoplastique sont souvent résolus par correspondance des formes, un algorithme dont les racines sont très géométriques : à partir d’une position initiale et de points objectifs qui minimisent l’énergie, la méthode déplace, à chaque pas de temps, les points en direction des objectifs.

Les apports de l’équipe font le lien entre cette technique et leur cadre de dynamique par position. Dans cette dernière, tous les objets sont représentés comme une série de points liés par des contraintes. Par exemple, un objet solide comme une brique pourra être représenté par une série de points, avec des distances imposées entre chaque paire de points de la brique : elle restera solide et ne se déformera pas. Ici, les solides déformables sont également représentés par un nuage de points. Cependant, les contraintes ne porteront pas sur des distances à conserver, mais une forme plus légère qui garantit une certaine cohésion de la forme. Les particules sont alors filtrées et redistribuées pour continuer la simulation.

De par le formalisme employé (dynamique par positions), cette technique permet des interactions faciles avec d’autres éléments simulés, comme des corps rigides, des fluides, des tissus. Cependant, l’approche n’a pas forcément un sens physique : elle ne cherche pas à conserver la masse totale des objets déformés, mais seulement le volume visible par l’utilisateur — ce qui est une approximation raisonnable pour bon nombre de cas.

Sources : Real-time Simulation of Large Elasto-Plastic Deformation with Shape Matching, Meshless Deformations Based on Shape Matching.
Merci à Claude Leloup pour ses corrections.

Sortie de Qt Creator 4.0.3

Une nouvelle version corrective de Qt Creator 4.0 vient de sortir. La 4.0.3 corrige quelques défauts mineurs. Notamment, sous OS X 10.8 et FreeBSD, le bouton pour lancer un programme était parfois désactivé. Quand Clang se chargeait de l’analyse du code C++, Qt Creator remplaçait parfois les points en tant que séparateurs décimaux par des flèches. L’ouverture de projets CMake depuis des liens symboliques ne fonctionnait pas toujours. Dans les projets QMake, l’EDI détecte maintenant l’ABI à utiliser pour NetBSD et OpenBSD.

Télécharger Qt Creator 4.0.3.
Source : Qt Creator 4.0.3 released.

FUJITSU passe à l’architecture ARM pour ses prochains superordinateurs

Dans le dernier classement des superordinateurs les plus puissants, FUJITSU classe une de ses machines à la cinquième position, la plus puissante au monde en dehors de la Chine et des États-Unis (elle était la plus puissante lors de sa construction, en 2011) ; elle est installée chez RIKEN, le plus grand institut de recherche japonais. K utilise des processeurs avec une architecture SPARC64, quand la majorité des supercalculateurs listés utilise la plus conventionnelle x86, la même qui équipe la majorité des ordinateurs personnels.

Cependant, FUJITSU abandonne le SPARC64 pour ses prochains superordinateurs : la société japonaise passera à l’ARM, architecture actuellement reine dans les applications embarquées, notamment les téléphones portables. Cette annonce a été faite à la conférence ISC, lors de la présentation sur le futur des superordinateurs de la marque, dont le remplaçant du K installé chez RIKEN. Il vise l’échelle de l’exaflops (comme les Américains) pour 2020.

Au niveau technologique, la microarchitecture de ces futurs processeurs (qui sert à implémenter les instructions accessibles en assembleur) devrait être similaire à l’actuelle, mais l’architecture ARM devrait mieux l’exploiter, selon les dires de FUJITSU. Actuellement, peu de détails sont cependant disponibles au niveau technique, le projet devant aboutir d’ici à peu près quatre ans.

La stratégie de FUJITSU semble se réorienter : alors que leur avantage compétitif s’amenuise, ils devaient réagir et exploiter un écosystème déjà existant (afin de limiter en partie leurs coûts, vu la faible production en systèmes HPC de FUJITSU). Trois architectures principales coexistent dans le secteur HPC : x86 (Intel et AMD), POWER (IBM) et ARM. La gamme de serveurs FUJITSU inclut les PRIMERGY, qui utilisent des processeurs Intel x86 : il restait à faire un choix entre ARM et POWER.

Le côté ARM est nettement moins développé que POWER pour du calcul scientifique de très haute performance, ce qui laisse une chance à FUJITSU de se différentier (seul Cavium est présent sur ce marché, avec ses ThunderX). De plus, la communauté ARM a une grande expérience quand il s’agit de diminuer la consommation énergétique, à cause des besoins des applications mobiles. Cependant, l’architecture ARM aura besoin d’extensions pour les applications HPC, notamment pour vectoriser les opérations de calcul : FUJITSU travaille main dans la main avec ARM.

Le marché HPC semble récemment se dynamiser, la position dominante d’Intel étant mise à mal : tant par IBM et son architecture POWER que les accélérateurs NVIDIA ou FUJITSU, avec l’arrivée d’AMD sur ce marché.

Source et image : Fujitsu Switches Horses for Post-K Supercomputer, Will Ride ARM into Exascale.

Qt Creator 4.1 Beta

La prochaine version de Qt Creator, numérotée 4.1, s’approche : une préversion Beta est maintenant disponible. La fonctionnalité la plus visible est, à nouveau, purement esthétique, avec deux nouveaux thèmes plats : l’un sombre, l’autre clair. Ils sont disponibles dans les options de l’EDI.


En coulisses, Qt Creator gère mieux les ressources disponibles : les documents qui n’ont pas été modifiés ni au premier plan pendant un certain temps ne seront plus gardés en mémoire. L’outil dispose d’une optimisation similaire depuis belle lurette lors de la restauration d’une session : seuls les documents visibles sont chargés. Les autres documents restent accessibles comme s’ils étaient chargés en mémoire. Ce comportement peut être configuré, bien évidemment.

Toujours dans les options, il est maintenant possible d’indiquer à Qt Creator s’il doit insérer les guillemets et les parenthèses par paire de manière séparée : les deux ne sont plus fusionnés en une seule option. Cette même distinction se fait dans le cas où l’utilisateur entre un tel caractère manuellement, pour indiquer à Qt Creator s’il remplace le caractère inséré automatiquement ou non.

Côté analyse de code, le moteur Clang a été mis à jour vers la version 3.8, ce qui lui permet d’analyser sans problème les fichiers d’en-tête de Visual C++ 2015.

L’outil de conception graphique d’interfaces Qt Quick a vu sa performance améliorée, avec un travail sur le processus de mise à jour du document QML pendant l’édition. Il est aussi maintenant possible de choisir le style des composants Qt Quick Controls 2.

Les projets CMake sont mieux gérés depuis la version 4.0, de nouvelles options sont apparues : CMake peut ne plus être lancé automatiquement, un choix à faire outil par outil ; par défaut, CMake n’est d’ailleurs plus lancé automatiquement quand Qt Creator n’est pas l’application active. Les erreurs de CMake sont mieux analysées et présentées à l’utilisateur.

Filippo Cucchetto, créateur de NimQml, qui permet d’exploiter des interfaces Qt Quick depuis le langage Nim, a contribué une extension pour ce langage dans Qt Creator, à activer manuellement. Elle propose la coloration syntaxique, l’indentation, la configuration des styles de code, la compilation, l’exécution et le débogage.

Télécharger Qt Creator 4.1.0 Beta.
Source : Qt Creator 4.1.0 Beta released.

Qt et WinRT : quoi de neuf ?

Windows Runtime (WinRT) est une plateforme logicielle qui tend à homogénéiser l’interface des applications Windows universelles (UWP, universal Windows platform), notamment imposée sur le Windows Store. Cette bibliothèque vise à remplacer l’API Win32, qui commence à montrer son âge, notamment parce que cette API n’est pas du tout orientée objet et provient de l’époque Windows 95 : au contraire, WinRT s’inscrit dans le futur. Cet cadre logiciel, arrivé avec Windows 8, exploite les concepts orientés objet et s’étend sur bon nombre de plateformes, tant de bureau (Windows 8, 8.1, 10) que mobiles (pour téléphones — Windows Phone 8.1, Windows 10 Mobile — ou non — Windows 10 IoT, Hololens, Xbox One). Qt est, bien évidemment, compatible avec WinRT et permet de développer des applications UWP, en profitant des dernières avancées de Microsoft (comme le glisser-déposer).

État actuel avec Qt 5.6 et 5.7

Qt 5.6 a nécessité pas mal de travail côté WinRT. En effet, depuis cette version, toute l’interface est dessinée dans une couche XAML, afin de s’intégrer au mieux à la plateforme. Actuellement, le code permet d’échanger pas mal d’informations internes avec le moteur d’exécution XAML, notamment afin d’intégrer du contenu XAML dans une application Qt : Qt WebView en profite pour utiliser le navigateur local (Microsoft Edge) dans une application Qt Quick.

Qt 5.6 est arrivé avec d’autres fonctionnalités intéressantes, comme la gestion de la caméra dans Qt Multimedia ou la reconnaissance du stylet (notamment pour les Microsoft Surface). Qt 5.6.1 améliore le confort de vie pour développer des applications UWP au niveau des fichiers de projet qmake : il n’est plus nécessaire de préciser CONFIG += windeployqt pour créer une solution Visual Studio, cela est fait automatiquement ; de même, en précisant QT += multimedia, bon nombre de fonctionnalités sont activées, comme l’accès à la webcam ou au micro (qu’il est bien sûr possible de désactiver).

Qt 5.7 n’est pas resté en retrait pour les améliorations. Ainsi, l’audio passe maintenant par WASAPI, qui garantit une latence moindre que précédemment — également accessible sous Windows, pour du développement d’interfaces classiques. L’inconvénient est alors que WASAPI synchronise le taux d’échantillonnage avec celui du pilote audio, sans donner la possibilité au développeur de convertir automatiquement le flux audio. Cette fonctionnalité n’est pas activée par défaut et doit être compilée séparément.

Aussi, côté Qt Quick, le code JavaScript peut être compilé à la volée (JIT), comme sur la plupart des autres plateformes. Initialement, comme Apple, Microsoft avait interdit toute génération de code pour des applications Windows Store, comme mesure de sécurité. Cependant, cette interdiction semble avoir été levée, même s’il n’y a pas encore eu de communication officielle à ce sujet. Grâce à cela, les applications Qt Quick peuvent être sensiblement accélérées, certains fonctions s’exécutant plus de cent fois plus vite. Au vu des incertitudes à ce sujet, cette fonctionnalité doit être activée manuellement et pourrait être retirée d’une prochaine version de Qt.

Fonctionnalités en cours de développement

Dans le futur, les développeurs espèrent que le module JIT pourra être activé pour les plateformes ARM : de par leur puissance, toute accélération possible du code est bonne à prendre. Cependant, toutes les fonctionnalités requises ne sont pas encore disponibles dans les API fournies par Microsoft, même si l’implémentation a déjà commencé côté Qt.

Les fonctionnalités de Qt 5.8 seront arrêtées d’ici un mois, WinRT aura droit à son lot. Notamment, le Bluetooth basse énergie sera accessible (comme sous Android et iOS actuellement) et le module Qt Purchasing sera étendu au Windows Store pour fournir des achats à l’intérieur des applications. Qt Speech arrivera en préversion technologique, avec côté WinRT la mise à disposition de l’API de synthèse vocale de Microsoft. De même, les travaux de découplage de Qt Quick par rapport à OpenGL ne serviront pas qu’à implémenter certaines parties sur Vulkan : ces applications pourront être affichées avec DirectX 12.

Source : Status Update on Qt for WinRT / UWP.
Merci à Claude Leloup pour ses corrections.

IBM annonce sa feuille de route pour son architecture POWER9

Dans le monde des serveurs, Intel règne à peu près sans partage en ce qui concerne les processeurs utilisés, notamment avec sa gamme de Xeon. Cependant, sa place est convoitée dans ce marche lucratif : d’un côté par ARM, des processeurs bien plus simples et qui permettent de stocker plus de processeurs avec plus de cœurs (bien plus lents) pour la même consommation énergétique ; de l’autre par IBM et son architecture POWER, concurrent de longue date d’Intel (une architecture de la même famille que les PowerPC chers à Apple, avant de passer chez Intel il y a dix ans).

Après avoir lancé l’OpenPOWER Foundation en 2013 avec la nouvelle version de son architecture POWER8, voici venu, pour IBM, le temps des premières annonces sur sa prochaine architecture, dénommée POWER9. La caractéristique mise en avant est que ces processeurs POWER9 auront vingt-quatre cœurs (par rapport aux vingt-deux proposés récemment par Intel dans ses Xeon E5 v4), soit le double de la génération actuelle POWER8 ; ils devraient arriver dans la seconde moitié de 2017 et seront utilisés pour le supercalculateur américain Summit.

Quelques détails plus croustillants sont d’ores et déjà disponibles sur le processeur lui-même : la gravure se fera en 14 nm (comme les processeurs Intel de dernière génération, par exemple) par GlobalFoundries. Il utilisera de la mémoire vive DDR4 et profitera d’un grand cache à faible latence de type eDRAM (comme certains processeurs Intel actuels). Au niveau communication, les entrées-sorties se feront par PCIe 4.0, les accélérateurs seront connectés par NVLink 2.0 (technologie propriétaire NVIDIA — une version améliorée par rapport aux GPU actuels Pascal) ou CAPI 2.0 (technologie ouverte du consortium OpenPOWER, notamment pour utiliser des FPGA). Chaque processeur aura des parties spécifiques pour la compression et la cryptographie, afin d’accélérer ces parties du traitement (ce qui donne des indications sur les marchés visés, comme les serveurs Web). Les serveurs seront prévus pour accueillir deux de ces processeurs.

Pendant la présentation d’IBM, Google est venu présenter son utilisation de cette architecture, en remplacement des processeurs Intel. Bon nombre de leurs services Web ont migré vers des systèmes POWER, ce qui a été une opération somme toute assez mineure au niveau logiciel pour eux : Google garde ses logiciels indépendants de la plateforme d’exécution, ce qui permet d’effectuer des tests sur d’autres architectures rapidement (comme des processeurs ARM ou POWER).

Google doit garder son matériel toujours à la pointe, afin de rester dans la compétition pour ses différents services et répondre à une demande toujours croissante. Par exemple, sur une dizaine d’années, le nombre de pages Web indexées a été multiplié par un facteur soixante. Depuis 2012, Gmail a vu son nombre d’utilisateurs actifs multiplié par deux ; quand YouTube recevait sept heures de vidéo chaque minute, il doit maintenant en traiter quatre cents chaque minute, à encoder de différentes manières pour les offrir aux visiteurs plus tard.

La société doit en plus limiter ses coûts : la technologie avançant, il est de plus en plus cher de réduire la taille des transistors… et donc d’augmenter la performance fournie pour chaque dollar investi dans l’infrastructure (de la construction à la maintenance). L’architecture POWER semble leur permettre d’atteindre ces objectifs. Google travaille justement avec Rackspace au développement de baies POWER9, sous le nom de Zaius. Intel ne sort pas complètement de leur infrastructure, mais une bonne partie utilise maintenant les processeurs d’IBM, compétitifs avec la solution d’Intel.

Sources : Power9: Google gives Intel a chip-flip migraine, IBM tries to lures big biz (dont l’image), IBM Fires a Shot at Intel with its Latest POWER Roadmap.

Intel concurrence NVIDIA avec son nouveau Xeon Phi Knights Landing

Annoncée il y a de cela un an, la nouvelle mouture des processeurs Intel Xeon Phi, nom de code Knights Landing, était annoncée : ces processeurs sont maintenant livrés aux fournisseurs de matériel HPC. Avec ces nouvelles puces, Intel vise le même segment que NVIDIA avec ses cartes graphiques (GPU) de génération Pascal : l’apprentissage profond, le calcul scientifique de haute performance (HPC).

Actuellement, quatre modèles sont disponibles, avec un nombre de cœurs variable (de soixante-quatre à septante-deux) et des fréquences aussi variables (entre 1,3 et 1,5 GHz), des caractéristiques proches des GPU actuels comme NVIDIA Pascal. Tous sont livrés avec seize gigaoctets de mémoire vive (MCDRAM), empilée et très proche du processeur, pour une bande passante de presque cinq cents gigaoctets par seconde. Ces différentes puces représentent des compromis différents : la plus puissante (7290, 3,46 Tflops) est la plus chère (6294 $), avec un produit bien plus abordable au niveau du téraflops par euro (7210 à 2438 $ pour 2,66 Tflops) ; l’une optimise le ratio performance par watt (7250, 3,05 Tflops pour 215 W, là où le 7290 fournit 3,46 Tflops pour 245 W) et la dernière la mémoire disponible par cœur (7230, soixante-quatre cœurs, comme le 7210, mais la mémoire a une fréquence plus élevée).

Au niveau des chiffres bruts, ces processeurs ne dépassent pas l’offre de NVIDIA : « à peine » trois téraflops et demi pour le plus haut de gamme, quand les GPU NVIDIA Pascal atteignent cinq téraflops (et une bande passante de cinquante pour cent plus élevée, à sept cent vingt gigaoctets par seconde). Par contre, selon les applications, à cause de la différence d’architecture fondamentale, les résultats varient énormément (les Xeon Phi sont organisés comme des processeurs traditionnels : chaque cœur peut exécuter une instruction propre, contrairement aux GPU, où la même instruction est exécutée sur un grand nombre de cœurs). Ainsi, pour de la simulation de dynamique moléculaire, pour le test de performance LAMPPS, un Xeon Phi de milieu de gamme (7250) a fonctionné cinq fois plus vite en consommant huit fois moins de mémoire qu’un GPU NVIDIA K80 (la génération précédant les Pascal). Pour de la visualisation par lancer de rayon, Intel indique être cinq fois plus rapide ; le facteur descend à trois pour de la simulation de risque financier. Ces comparaisons ne sont pas entièrement équitables, à cause de la différence d’âge entre les processeurs, mais donnent la tendance qu’Intel veut montrer. Ces résultats devront être confirmés par des indépendants pour être fiables.

Parmi les tests de performance, Intel s’est aussi orienté vers l’apprentissage profond, branche dans laquelle NVIDIA s’impose actuellement. Ce domaine est actuellement à la pointe de la recherche, avec des résultats de plus en plus intéressants : c’est grâce à des techniques de ce genre que Google a pu battre le joueur le plus fort au monde au jeu de go. Sur un même jeu de test, un Xeon Phi 7250 a obtenu sa réponse en cinquante fois moins de temps qu’un seul processeur traditionnel ; avec quatre tels Xeon Phi, les temps de calcul ont été réduits d’un facteur deux par rapport à quatre GPU NVIDIA K80.

Intel précise également qu’il est plus facile de programmer ses processeurs Xeon Phi : ils embarquent beaucoup plus de cœurs, mais c’est la seule différence avec les processeurs habituels de nos PC, alors qu’il faut réécrire complètement son code (ou utiliser des API adaptées) pour les GPU, avec une phase d’optimisation du code qui nécessite des compétences plus spécifiques. La nouvelle génération de Xeon Phi apporte cependant une distinction plus importante : ces processeurs Intel pourront être utilisés comme processeurs principaux (pas seulement comme cartes d’extension), ce qui évite les opérations de transfert de données, très limitantes pour la performance des applications actuelles. Il reste cependant à déterminer si ces processeurs seront suffisamment rapides pour effectuer toutes les opérations des applications qui leur sont soumises (ils fonctionnent à une fréquence réduite par rapport aux processeurs habituels : ils excellent dans le traitement parallèle, mais pas en série, qui constitue parfois une part importante du code à exécuter).

Ni ces nouveaux Xeon Phi ni les GPU NVIDIA Pascal ne sont actuellement utilisés à grande échelle pour du calcul scientifique. Cependant, ces premiers résultats montrent que les deux jouent dans la même cour. Si les mesures d’Intel se généralisent, ils deviendront un concurrent plus que très sérieux de NVIDIA, notamment dans le marché en expansion de l’apprentissage profond ; s’ils ont en plus l’avantage du prix, la dominance de NVIDIA sera vite mise à mal.

Sources : Intel Takes on NVIDIA with Knights Landing Launch, Intel’s Knights Landing: Fresh x86 Xeon Phi lineup for HPC and AI, Intel Xeon Phi Knights Landing Now Shipping; Omni Path Update, Too.

Merci à Claude Leloup pour sa relecture orthographique.

Sortie de Qt 5.6.1-1

Très peu de temps après Qt 5.6.1, la gravité d’un défaut (QTBUG-53761) a été remarquée : l’utilisation d’applications Qt Quick un peu sérieuses est devenue impossible avec Qt 5.6.1 (ce qui n’était pas le cas avec la 5.6.0). Le problème vient de la gestion des caches : dès que soixante-quatre composants ont été importés (des fichiers QML ou JavaScript), mais que tous n’ont pas été instanciés, le système de gestion des caches pouvait effacer certains composants non instanciés. Lors de leur utilisation effective, l’interpréteur ne pouvait donc plus les trouver, ce qui résultait en une série d’erreurs difficilement compréhensible :

Starting /dev/Qt5.6.1-test/Examples/Qt-5.6/quickcontrols/extras/flat-Desktop_Qt_5_6_1_GCC_64bit-Debug/flat...
QML debugging is enabled. Only use this in a safe environment.
qrc:/ExtrasImports/QtQuick/Controls/Styles/Flat/GroupBoxStyle.qml:64: TypeError: Cannot read property 'flat' of null
qrc:/ExtrasImports/QtQuick/Controls/Styles/Flat/GroupBoxStyle.qml:62: TypeError: Cannot read property 'flat' of null
qrc:/ExtrasImports/QtQuick/Controls/Styles/Flat/GroupBoxStyle.qml:82: TypeError: Cannot read property 'checked' of null

Pour les détails temporels : le défaut avait été corrigé avant la sortie de Qt 5.6.1, mais sa gravité avait été mal estimée, la sortie de Qt 5.6.1 n’a donc pas été retardée, puisque chaque modification doit être testée. Au fil du temps et des rapports qui ont défilé sur l’application de suivi des défauts, les développeurs ont remarqué que ce problème était grave, d’où cette nouvelle version. Par contre, le correctif a été intégré à Qt 5.7.0 à temps pour la sortie de cette version.

Télécharger Qt 5.6.1-1.
Source : Qt 5.6.1-1 Released.

Qt WebKit NG TP2

Peu après les premières annonces officielles, une nouvelle préversion technologique du nouveau Qt WebKit fait son apparition. Dans les nouveautés, on peut compter une implémentation de l’API HTML5 IndexedDB complètement refaite : elle ne dépend plus de LevelDB, un moteur de base de données de Google, tout en apportant un meilleur niveau de compatibilité avec la norme.

Pour les vidéos, l’API Media Source Extensions est activée quand GStreamer est disponible. Cette implémentation est encore expérimentale et, notamment, toutes les vidéos YouTube ne fonctionnent pas (lorsqu’une publicité est affichée au début). Il faut encore l’activer manuellement, mais elle devrait l’être automatiquement dans une prochaine version.

D’autres API sont maintenant disponibles : la détection de l’orientation et des mouvements, principalement pour les applications mobiles ; les manettes de jeu, uniquement pour Linux. Aussi, il devient possible d’imprimer. Le projet est maintenant compatible avec OS X 10.10.

Au niveau de l’infrastructure, le projet s’intègre mieux avec qmake et CMake, ce qui facilite son utilisation dans vos projets. La documentation est maintenant générée aux formats HTML et QCH, ce qui permet notamment son utilisation depuis Qt Creator ou Qt Assistant.

Maintenant, des binaires précompilés sont disponibles : pour Windows 32 et 64 bits (compilation avec Visual C++ 2015) ainsi que pour OS X.

Source : [Development] [Announcement] QtWebKit Technology Preview 2.

LLVM lance un nouveau projet : parallel-lib

Il y a trois mois, Google proposait son projet StreamExecutor à LLVM. Cette bibliothèque sert à lancer des calculs sur des processeurs graphiques et d’autres types d’accélérateurs, principalement pour leur solution d’apprentissage profond TensorFlow. L’avantage est de disposer d’un système unique pour lancer des calculs sur ce type d’accélérateur, sans dépendre de la bibliothèque qui sera effectivement utilisée pour les calculs. Cette couche d’abstraction ne fait « que » gérer l’évolution des calculs sur les accélérateurs selon le concept de flux (emprunté à NVIDIA CUDA), d’où le nom de la bibliothèque. Ce projet StreamExecutor s’inscrit notamment dans la lignée d’OpenMP 4, avec la possibilité de décharger une partie du code sur des accélérateurs à l’aide d’une directive spécifique (offload).

Suite à cette proposition de code de la part de Google, après quelques mois de discussions, lancées par la proposition de Google, LLVM lance un nouveau sous-projet orienté programmation concurrente : parallel-libs. Ce projet est présenté comme un parallèle concurrent à compiler-rt, qui rassemble diverses fonctionnalités (implémentation générique d’instructions non disponibles sur certains processeurs, assainisseurs de code, etc.).

En quelques mots, les objectifs de parallel-libs sont plus étendus que ceux de StreamExecutor : ce sous-projet pourra contenir des moteurs d’exécution comme celui d’OpenMP, des bibliothèques d’accès au matériel à l’instar de StreamExecutor, voire des fonctions mathématiques implémentées en parallèle. La seule contrainte pour une inclusion dans parallel-libs est d’être à la croisée des chemins des compilateurs et de l’exécution concurrente, ce qui permettra de partager du code.

Pour le moment, les décisions sont prises, mais le projet n’a pas encore d’existence physique (pas d’emplacement sur le dépôt SVN de LLVM, pas de liste de diffusion). Cela ne devrait pas tarder. D’ailleurs, IBM pourrait rejoindre la danse, avec leurs projets d’interface unique pour lancer du code, que ce soit avec CUDA ou OpenMP, pour lesquels un premier commit est arrivé.

Source : [llvm-dev] parallel-lib: New LLVM Suproject.