Pourquoi l’apprentissage profond et les réseaux neuronaux sont-ils si prometteurs ?

L’apprentissage profond et les réseaux neuronaux sont à la mode pour le moment dans le domaine de l’apprentissage automatique : Google, NVIDIA et plus récemment Microsoft proposent des bibliothèques, plus ou moins ouvertes, pour faciliter leur utilisation.

De fait, l’apprentissage profond accumule les succès ces derniers temps, y compris pour battre des humains au jeu de go — même si le meilleur joueur au monde, selon les classements actuels, Lee Sedol, estime encore pouvoir battre ce système d’intelligence artificielle. L’intérêt du jeu de go est sa complexité, malgré des règles relativement simple : il existe approximativement 10^{761} parties de go, contre « Ã  peine » 10^{120} parties de jeu d’échecs (un nombre bien plus abordable actuellement).

Apprentissage d’un réseau

Cependant, de manière théorique, rien ne pouvait justifier les succès des réseaux neuronaux, qui sont l’outil principal derrière l’apprentissage profond. Depuis la première vague d’intérêt de la part du monde académique, dans les années 1990, leur étude avait montré la présence de nombreux minima locaux de l’erreur totale. L’apprentissage d’un réseau neuronal se fait en définissant la pondération des entrées de chaque neurone : changer un peu ces poids peut avoir un grand impact sur la prédiction du réseau.

Pour choisir cette pondération, tous les algorithmes testent le réseau sur des données pour lesquelles le résultat est connu : par exemple, un son et les mots auxquels il correspond ; la différence correspond à l’erreur commise par le réseau. La présence de ces minima locaux signifie que, une fois l’exécution de l’algorithme terminée, la pondération n’est pas forcément idéale : en changeant quelques valeurs, il peut être possible de diminuer drastiquement l’erreur totale. L’objectif des algorithmes d’apprentissage est d’atteindre le minimum global d’erreur.

Premières analyses et verre de spin

Jusqu’à présent, l’analyse théorique des réseaux neuronaux s’était portée sur des réseaux de quelques neurones : ces minima locaux sont alors présents en grand nombre et sont assez éloignés les uns des autres. Cette caractéristique menace alors la performance des réseaux, puisque le minimum local après apprentissage peut être très éloigné du minimum global.

Ce comportement correspond, en physique, à celui des verres de spin, « des alliages métalliques comportant un petit nombre d’impuretés magnétiques disposées au hasard dans l’alliage » : l’énergie du matériau dépend fortement de la configuration des impuretés, qui présente un grand nombre de minima locaux éloignés du minimum globale. Ce verre de spin est alors coincé dans une configuration dite métastable : en réorganisant très légèrement les impuretés, l’énergie globale pourrait baisser assez fortement.

Nouvelles analyses

Le seul résultat théorique dont on disposait jusque l’année dernière était que certains réseaux neuronaux correspondent exactement aux verres de spin. Cependant, le résultat obtenu par l’équipe de Yann LeCun (directeur du laboratoire d’intelligence artificielle de Facebook) montre, au contraire, que, pour un très grand nombre de neurones, la fonction d’erreur a plutôt la forme d’un entonnoir : les minima locaux sont très rapprochés du minimum global. Plus le réseau est grand, plus ces points sont rassemblés autour du minimum global. Or, justement, l’apprentissage profond propose d’utiliser un très grand nombre de ces neurones, plusieurs millions : le résultat d’un apprentissage n’est donc jamais loin du minimum global.

Plus précisément, les algorithmes d’apprentissage convergent vers des points critiques. Les chercheurs ont montré que la majorité de ces points critiques sont en réalité des points de selle et non des minima : ils correspondent à une zone plate, avec des directions montantes et descendantes. Il est donc relativement facile de s’en échapper, en suivant la direction descendante (en termes d’erreur). Globalement, les vrais minima (qui correspondent à des cuvettes : seulement des directions qui augmentent l’erreur) sont assez rares — et proches de la meilleure valeur possible.

Physiquement, les réseaux neuronaux correspondent donc plus à des « entonnoirs de spin », avec des formes plus sympathiques : l’énergie de la configuration varie de manière abrupte, sans véritablement offrir de minimum local. Ces matériaux trouvent bien plus facilement leur configuration native (avec une énergie minimale).

Ces résultats confirment donc que des techniques comme la descente de gradient stochastique (SGD) peuvent fonctionner : la fonction d’erreur d’un réseau neuronal est à peu près convexe. Cependant, les réseaux modernes sont souvent plus complexes que ceux étudiés, afin d’éviter le surapprentissage (correspondre trop bien aux données pour l’apprentissage, mais avoir du mal à reconnaître des données qui n’en font pas partie).

Néanmoins, la chimie théorique et la physique de la matière condensée proposent d’ores et déjà un panel d’outils mathématiques pour comprendre la structure de ces entonnoirs de spin et des variations plus complexes, notamment dans le cas du pliage de protéines (elles prennent une forme qui minimise cette énergie). Cette étude propose ainsi de nouveaux mécanismes d’étude des réseaux neuronaux, mais peut-être aussi de nouveaux algorithmes d’apprentissage ou techniques pour éviter le surapprentissage.

Sources : C’est la fin d’une croyance sur les réseaux de neurones, Why does Deep Learning work? (image).
Plus de détails : The Loss Surfaces of Multilayer Networks, Why does Deep Learning work?, The Renormalization Group.

CNTK, la solution de Microsoft pour l’apprentissage profond, devient libre

Il y a peu, Google a mis à disposition des développeurs TensorFlow, sa solution d’apprentissage profond, une technique d’apprentissage automatique qui exploite principalement des réseaux neuronaux de très grande taille : l’idée est de laisser l’ordinateur trouver lui-même, dans sa phase d’apprentissage, des abstractions de haut niveau par rapport aux données disponibles. Par exemple, pour reconnaître des chiffres dans des images, ces techniques détermineront une manière d’analyser l’image, d’en récupérer les éléments intéressants, en plus de la manière de traiter ces caractéristiques et d’en inférer le chiffre qui correspond à l’image.

Microsoft vient tout juste d’annoncer sa solution concurrente, nommée CNTK (computational network toolkit), elle aussi disponible gratuitement sous une licence libre de type MIT sur GitHub. Cette annonce poursuit la série d’ouvertures de code annoncées par Microsoft dernièrement, comme ChakraCore, son moteur JavaScript.

Ces développements ont eu lieu dans le cadre de la recherche sur la reconnaissance vocale : les équipes de Microsoft estimaient que les solutions actuelles avaient tendance à les ralentir dans leurs avancées. Quelques chercheurs se sont lancés dans l’aventure d’écrire eux-mêmes un code de réseaux neuronaux très efficace, accéléré par GPU… et leurs efforts ont porté leurs fruits, puisque, selon leurs tests, CNTK est plus efficace que Theano, TensorFlow, Torch7 ou Caffe, les solutions les plus avancées dans le domaine du logiciel libre.

Microsoft n’est pas la seule société à beaucoup parier sur les GPU : NVIDIA également croit fort aux GPU pour accélérer l’apprentissage profond. Pour la sortie de la dernière version de CUDA, la solution de NVIDIA pour le calcul sur GPU, leur bibliothèque cuDNN proposait un gain d’un facteur deux pour l’apprentissage d’un réseau.

L’avantage des GPU dans le domaine est multiple. Tout d’abord, leur architecture s’adapte bien au type de calculs à effectuer. Ensuite, ils proposent une grande puissance de calcul pour un prix raisonnable : pour obtenir la même rapidité avec des processeurs traditionnels (CPU), il faudrait débourser des milliers d’euros, par rapport à une carte graphique à plusieurs centaines d’euros à ajouter dans une machine existante. Ainsi, les moyens à investir pour commencer à utiliser les techniques d’apprentissage profonds sont relativement limités. Cependant, la mise à l’échelle est plus difficile : l’apprentissage sur plusieurs GPU en parallèle est relativement difficile, toutes les bibliothèques ne le permettent pas. Pour réaliser de véritables progrès algorithmiques, il faut sortir le carnet de chèques, avec des grappes de machines, nettement moins abordables.

Source : Microsoft releases CNTK, its open source deep learning toolkit, on GitHub.

AMD prépare une nouvelle structure d’interconnexion

Pour les serveurs et plus particulièrement encore le calcul de haute performance (notamment sur superordinateur), les bus traditionnel pour connecter les différences parties d’un ordinateur (processeur principal — CPU —, accélérateurs — GPU, APU, FPGA…) deviennent limitants : avec de piètres débit et latence en comparaison des possibilités des éléments connectés, ils brident quelque peu le matériel utilisé — mais la situation ne s’améliorera pas avec les nouvelles générations. AMD, souhaitant se relancer dans ces marchés très juteux, est en train de développer sa propre solution, que l’on ne manquera pas de comparer à la solution concurrente NVLINK de NVIDIA (qui devrait débarquer cette année sur le marché).

Actuellement, des cartes graphiques comme les AMD Radeon R9 Fury ou NVIDIA Tesla K80 fournissent une belle capacité de calcul, mais elle n’est pas suffisante pour les besoins des utilisateurs les plus exigeants. AMD pourrait mieux répondre à ces besoins en alignant une série de ces cartes et en leur permettant de bien communiquer entre elles (sans devoir passer par le processeur central). Idéalement, cet assemblage devrait s’utiliser comme une seule et unique carte, beaucoup plus puissante, mais cela n’est actuellement pas vraiment possible, notamment à cause des limitations des technologies pour lier ces cartes (CrossFire chez AMD, SLI chez NVIDIA). Ces nouvelles structures d’interconnexion ne devraient pas se limiter aux cartes graphiques, mais devraient s’ouvrir à d’autres types d’accélérateurs, comme des FPGA.

La solution d’AMD, toujours en cours de développement, devrait offrir des débits de l’ordre de cent gigabits par seconde entre processeurs (contre une trentaine pour la prochaine version de PCI Express, attendue pour 2017), à comparer au double pour NVLINK. La différence principale est cependant que l’approche de NVIDIA ne fonctionne qu’entre processeurs NVIDIA et IBM POWER (deux superordinateurs utilisant cette technologie ont déjà été commandés), alors que AMD est plus ouvert, en mettant l’accent sur des normes ouvertes.

Source : AMD Talks Next Generation Coherent Interconnect Fabric Connecting Polaris GPUs, Zen CPUs and HPC APUs.

NVIDIA FleX arrive dans Fallout 4 avec des effets de débris

Dans la préversion du prochain patch à venir de Fallout 4, un nouvel effet physique a été ajouté : les débris générés par la destruction d’objets par armes à feu. Au lieu de simplement présenter des trous dans le sol ou les façades, des morceaux de béton ou de bois se détacheront et voleront en l’air.

En y regardant de plus près, on peut remarquer que cet effet n’est pas, pour le moment, extrêmement réaliste, avec un nombre excessif de particules générées (faire exploser une chaise pourrait donner plus de débris que la chaise elle-même, par exemple). De plus, seules certaines parties du monde sont concernées par cet effet. Ces limitations sont principalement dues au fait que l’effet a été ajouté après coup et non lors du développement du jeu.

Du côté technique, l’effet utilise le nouveau solveur FleX de NVIDIA (dont la version 0.9.0 est disponible gratuitement), qui exploite les possibilités des processeurs graphiques pour effectuer les calculs sous-jacents ; cela signifie que cet effet ne sera disponible, pour le moment, que sur les GPU NVIDIA (il est prévu depuis les débuts de FleX de réaliser une version exploitant d’autres technologies, mais ces efforts n’ont pas encore vu le jour).

Cependant, ces résultats (préliminaires) sont d’ores et déjà encourageants, par exemple en comparaison de l’effet similaire implémenté dans Borderlands 2, qui utilise le solveur de PhysX (le moteur de physique généraliste de NVIDIA). Les calculs sont plus efficaces en temps, car les débris sont simulés comme de simples points matériels, sans considérer qu’il s’agit de véritables objets en trois dimensions. L’ensemble de leurs mouvements est donc simplifié : le moteur physique ne peut pas prévoir de rotation, un certain mouvement est donc préprogrammé ; les collisions avec les objets statiques sont très simplifiées… et complètement inexistantes avec les autres débris.

Au contraire, dans l’implémentation de Fallout 4, les débris ont une véritable extension spatiale pour la simulation physique : ils ont une forme tridimensionnelle et peuvent interagir entre eux. La différence est plus notable pour un empilement de débris : là où Borderlands 2 formait un simple tapis de débris, sans que l’un chevauche l’autre, Fallout 4 montre un empilement. Les calculs sont effectués dans un formalisme de corps rigides sur GPU et Fallout 4 en est l’une des premières applications ; du côté technique, le point noir actuel est le manque d’ombres.

Source et images : Fallout 4 beta patch adds Nvidia FLEX based particle debris effects.

Qt est et restera un logiciel libre

L’une des premières applications à utiliser Qt fut KDE, un environnement de bureau — plutôt que des ensembles d’application, comme c’était monnaie courante en 1996. Cependant, Qt n’était pas exactement un logiciel libre : sa licence n’était pas compatible avec la GPL selon la Free Software Foundation ; si la société devait être rachetée, le projet KDE courait le risque de ne plus pouvoir utiliser Qt dans ses versions à venir. Cette crainte a mené à la création de la KDE Free Qt Foundation, qui matérialise un accord avec les différentes sociétés derrière Qt et son exploitation commerciale : si jamais Qt n’était plus développé ou libre, alors la dernière version libre serait disponible sous une licence très permissive comme la BSD, automatiquement.

Cet accord avait déjà été mis à jour, la dernière fois en 2014 lors de l’ajout de la LGPLv3 dans les licences : le premier accord ne faisait pas état d’un grand nombre de plateformes concernées — seulement X11 —, alors que toutes les plateformes avec lesquelles Qt est compatible sont concernées ; de même, suite aux changements de gouvernance et la création du Qt Project, les contributions, intégrées ou non aux sources de Qt, sont comprises dans ce texte juridique. Avec ce nouvel accord, la compatibilité avec Linux et Android ne pourra pas être abandonnée (contrairement aux autres plateformes, où Digia reste libre), à moins d’une révision ; la fondation s’est aussi arrogée le droit d’y inclure les successeurs de X11, comme Wayland, sans négociation.

La principale nouveauté concerne cependant les licences de la version libre de Qt, pour les aligner avec la « philosophie du logiciel libre ». En 2014, la licence LGPLv3 a été ajoutée pour mieux respecter cette philosophie. Par rapport à la version précédente (2.1), elle garantit non seulement le droit de l’utilisateur à modifier les sources, mais aussi à les compiler et à les exécuter — ce qui empêche directement de bloquer complètement des appareils, afin de forcer la création d’un environnement libre. Un autre apport important concerne la protection par rapport aux brevets, très importante outre-Atlantique.

Ce nouvel accord sera d’application dès Qt 5.7 et supprime la LGPLv2.1 à cause de ces limitations et impose que le nouveau code soit disponible sous LGPLv3 et GPLv3 (le code existant doit aussi être disponible sous GPLv2 pour rester compatible par rapport à d’autres projets libres). Les différentes parties de Qt et de son environnement de base seront alors disponibles sous des régimes différents (tous seront toujours disponibles dans une édition commerciale, plus flexible mais non libre) :

  • pour les modules essentiels (Qt Core, GUI, Quick, Network, etc.) : LGPLv3 et GPLv2 ;
  • pour les modules d’extension (Qt Android Extras, Bluetooth, Concurrent, OpenGL, etc.) : LGPLv3 et GPLv2, à l’exception de Qt WebEngine (à cause de Chromium, le code est également disponible sous LGPLv2.1) ;
  • pour les outils et applications (Qt Creator, moc, lupdate, etc.) : GPLv3, avec deux exceptions pour que le code généré n’ait aucune restriction et que les liens avec du code tiers soit toujours possible.

De manière générale : tout Qt est disponible sous la GPLv3 ou une licence compatible ; de larges pans sont aussi disponibles sous la LGPL et la GPLv2. Ces changements arriveront dès Qt 5.7 : la 5.6 étant une version avec support à long terme, les projets devraient avoir le temps de s’adapter à ces changements au besoin.

En même temps, de nouveaux modules, anciennement uniquement commerciaux, seront disponibles sous une licence libre (GPLv3) : dès Qt 5.7, Qt Charts, Qt Data Visualization, Qt Virtual Keyboard, Qt Test Integration, Qt Quick 2D Renderer, QML Profiler et l’analyseur statique pour Clang. L’objectif est d’inclure le compilateur Qt Quick dans le module Qt QML (LGPLv3 et GPLv2), qui devrait arriver avec Qt 5.8. Le code de la plupart des modules est déjà disponible, les autres devraient arriver sous peu. Par contre, l’offre spécifique à l’embarqué (Qt for Device Creation) reste entièrement commercial.

Cette annonce confirme la volonté d’uniformiser l’écosystème Qt, lancée avec le site qt.io, commun aux éditions libres et commerciales. La stratégie reste de fournir des fonctionnalités spécifiques sous licence commerciale pour garantir un flux de liquidités et assurer la suite du développement de Qt, tout en offrant beaucoup dans l’offre libre pour que Qt rayonne. Cependant, elle semble s’axer de plus en plus vers le monde de l’embarqué.

Sources : New agreement with the KDE Free Qt Foundation and changes for the open source version, Qt is Guaranteed to Stay Free and Open – Legal Update

Voir aussi : le contrat.

Qu’attendre de GCC 6 en C++ ?

Avec le nouveau cycle de GCC, la prochaine version majeure sera numérotée 6 et sera la première à apporter des nouveautés par rapport à GCC 5, sorti en avril dernier dans sa première version finale (5.1). La principale nouveauté concerne la norme C++ par défaut : adieu C++98, GCC s’ouvre maintenant au vingt et unième siècle en activant C++14 par défaut ! Il est toujours possible de compiler son code en C++98 ou C++11 avec l’option de compilation adéquate (std=c++11, par exemple).

Toujours au niveau des normes, quelques points qui devraient faire partie de la prochaine révision de C++, en 2017, sont déjà implémentés (et accessibles par l’option std=c++1z). Cette révision n’étant pas achevée, toutes ces fonctionnalités sont marquées comme expérimentales. La principale est nommée concepts : il s’agit d’une extension du système de templates du langage pour inclure des garanties formelles ; par exemple, pour imposer que le type paramétré T d’une fonction puisse être comparé, on pourrait écrire ce bout de code :

template<typename T> requires LessThanComparable<T>
const T& min(const T &x, const T &y) {
    return (y < x) ? y : x;
}

auto concept LessThanComparable<typename T> {
    bool operator<(T, T);
}

Code très approximatif suite aux énormes limitations du système de blog.

Grâce à ces concepts, le compilateur pourrait fournir des messages d'erreur beaucoup plus explicites qu'actuellement ; ils pourraient être utilisés par les outils d'analyse statique du code pour des diagnostics plus précis ou encore guider l'optimisation du compilateur. Initialement, ces concepts étaient prévus pour C++11, mais n'étaient pas encore estimés suffisamment prêts alors. Au niveau de la bibliothèque standard C++17, les extensions proposées pour la gestion des fichiers et une série de fonctions estimées de base sont implémentées.

Architectures

Pour ARM64, le compilateur peut maintenant déterminer le processeur utilisé et optimiser au mieux pour ce compilateur, sans nécessiter de paramètre particulier pour march et compagnie. Aussi, l’optimisation lors de l’édition est liens fonctionne sur plusieurs unités de compilation.

Sur les processeurs Intel, les extensions de protection de la mémoire (MPX) sont maintenant activées par défaut : ces instructions des processeurs de génération Skylake sont prévues pour augmenter la sécurité lors de l’exécution avec une vérification matérielle des références des pointeurs. Sur ces mêmes processeurs (gamme Xeon uniquement), pour la performance, les extensions AVX-512 sont maintenant gérées : elles servent à exécuter des opérations mathématiques sur des vecteurs de cinq cent douze bits d’un coup (plutôt que d’effectuer une série d’instructions les unes à la suite des autres), ce qui a un impact principalement sur le code scientifique.

Côté AMD, les processeurs de la famille Zen, qui devraient débarquer à la fin de l’année, sont déjà gérés.

OpenMP est une norme prévue pour aider à paralléliser du code source C, C++ et Fortran. La nouvelle version 4.5 de la norme est complètement implémentée pour les compilateurs C et C++.

Diagnostics du compilateur

Une nouvelle option, -fsanitize=bounds-strict, effectue des vérifications plus poussées et plus strictes au niveau des bornes des tableaux lors des appels.

Cependant, le nouvel avertissement qui a fait le plus de bruit concerne l’indentation : par exemple, si un bout de code marque par son indentation qu’il devrait dépendre d’une condition… mais si la syntaxe utilisée montre le contraire, le compilateur donnera un avertissement. Il a déjà montré ses effets positifs pour une partie des elfutils : Mark Wielard a pu corriger un défaut « gênant » dans le code. Il doit cependant être activé séparément avec le paramètre -Wmisleading-indentation.

Ce type d’erreur a déjà mené à des failles de sécurité, notamment chez Apple, où une fonction retournait sa valeur avant d’avoir effectué tous les tests de sécurité nécessaires. Encore une fois, l’indentation indiquait que le code était correct… alors que le retour se faisait sans la moindre condition.

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
                                 uint8_t *signature, UInt16 signatureLen)
{
    OSStatus        err;
    …

    if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
        goto fail;
    if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
        goto fail;
        goto fail;
    if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
        goto fail;
    …

fail:
    SSLFreeBuffer(&signedHashes);
    SSLFreeBuffer(&hashCtx);
    return err;
}

Cependant, pas mal d’utilisateurs craignent que ce nouveau type d’avertissements ne crée un grand nombre de faux positifs — c’est d’ailleurs pour cette raison qu’il n’est pas activé par défaut.

GCC 6.1, la première version stable de GCC 6, devrait arriver aux alentours de mars ou avril. Il devrait être le compilateur par défaut pour Fedora 24, dont la sortie devrait être retardée jusque juin pour laisser le temps de recompiler tous les paquets avec cette nouvelle version de GCC.

Sources : GCC 6 Release Series, C++1z Support in GCC, libstdc++ status, Among The Changes/Features Coming For GCC 6, GCC 6 To Enable Intel’s MPX Library By Default, GCC 6 Will Warn You About Misleading Code Indentations, Apple’s SSL/TLS bug, Fedora 24 Will Likely Be Delayed.

Quelles pistes pour les superordinateurs d’un exaflops ?

En 1964 a été construit le premier superordinateur, nommé Control Data 6600, avec une puissance de calcul d’un mégaflops, c’est-à-dire un million d’opérations en virgule flottante chaque seconde (comme additionner deux nombres à virgule). Il a été conçu par Seymour Cray, qui a lancé la société Cray, connue pour son activité dans les supercalculateurs.

Vingt et un ans plus tard, en 1985, la barre du gigaflops a été franchie par Cray-2. Actuellement, un processeur haut de gamme (comme un Intel i7 de dernière génération) fournit approximativement cent gigaflops.

Une dizaine d’années plus tard, en 1997, ASCI Red explose le téraflops, mille milliards d’opérations en virgule flottante par seconde ; dans cette série de records, c’est le premier à ne pas être associé au nom de Cray. Un processeur graphique moderne haut de gamme (comme la GeForce GTX Titan X) dépasse maintenant quelques téraflops.

Il y a presque dix ans, Roadrunner atteignant le pétaflops, en combinant une série de processeurs similaires à ceux utilisés dans les PlayStation 3. Aujourd’hui, le plus puissant est Tianhe-2, installé en Chine (alors que les précédents sont américains), avec une cinquantaine de pétaflops. La route semble encore longue jusqu’à l’exaflops, c’est-à-dire un milliard de milliards d’opérations en virgule flottante par seconde. À nouveau, les États-Unis ont lancé un projet pour atteindre cette puissance de calcul à l’horizon 2020 — plus particulièrement, le Département de l’Énergie, le même à investir massivement dans un compilateur Fortran moderne libre.

Ces nombres paraissent énormissimes : un milliard de milliards d’opérations par seconde. Outre les aspects purement informatiques, ce genre de projets a une grande importance pour la recherche scientifique : les laboratoires américains de l’Énergie étudient notamment l’arme nucléaire et la destruction en toute sécurité d’ogives ; en Europe, le Human Brain Project vise à simuler toute l’activité cérébrale d’un cerveau humain au niveau neuronal, ce qui nécessiterait une puissance de calcul de cet ordre de grandeur.

Comment y arriver ?

Le Département de l’Énergie estime que, actuellement, toutes les technologies nécessaires pour construire un tel superordinateur sont réunies. Cependant, il serait extrêmement difficile de l’alimenter : il faudrait un réacteur nucléaire complet pour y arriver ! Même si la construction de réacteurs fait partie de ses compétences, l’objectif de l’administration est de proposer une machine qui ne consomme « que » vingt mégawatts (un réacteur nucléaire produit généralement mille mégawatts). Erik DeBenedictis voit trois technologies pour réduire la consommation du facteur cinquante demandé : des transistors opérant à une tension d’un millivolt, la mémoire 3D et les processeurs spécialisés.

En théorie, un transistor peut fonctionner avec des tensions bien plus faibles qu’actuellement, en passant d’un volt à quelques millivolts à peine, ce qui augmenterait l’efficacité énergétique des processeurs d’un facteur dix à cent à court terme (jusqu’à dix mille à plus long terme !). La diminution de tension a jusqu’à présent suivi la loi de Moore, suivant la taille des transistors ; cependant, elle est bloquée depuis une décennie au niveau du volt… mais personne ne sait comment y arriver. Plusieurs technologies pourraient néanmoins passer cette barre :

Les mémoires empilées (aussi dites « en trois dimensions ») sont d’ores et déjà en cours de déploiement, sous des noms comme HBM ou HMC, dans les processeurs graphiques haut de gamme ou des accélérateurs spécifiquement prévus pour le calcul scientifique. Ils permettent une grande réduction de la consommation énergétique, d’autant plus enviable que l’objectif de vingt mégawatts réserve un tiers de la consommation à la mémoire. Une autre piste serait d’abandonner autant que possible la mémoire non volatile, pour passer par exemple à la mémoire résistive, comme la technologie Octane d’Intel.

Le troisième axe de recherche propose d’exploiter des architectures beaucoup plus spécifiques aux problèmes à résoudre. Elle est déjà exploitée, puisqu’une bonne partie des superordinateurs les plus puissants utilisent des processeurs graphiques. Cependant, Erik DeBenedictis propose de pousser l’idée plus loin encore : installer des processeurs extrêmement spécifiques aux tâches à réaliser, qui seraient activés seulement quand ils sont nécessaires. Pour effectuer d’autres types de calculs sur l’ordinateur, il faudrait alors installer d’autres processeurs spécialisés, ce qui n’est plus déraisonnable actuellement, au vu du prix des puces spécialisées.

Des compromis à réaliser

Ces trois pistes ont l’air intéressantes, mais n’ont pas du tout les mêmes propriétés quant au modèle de programmation actuel : si la physique derrière les processeurs change complètement, ils restent programmables de la même manière ; par contre, pour exploiter efficacement de nouveaux processeurs spécialisés, il faudrait changer complètement sa manière de pensée. La mémoire est dans une situation intermédiaire : empilée sur le processeur, les délais d’accès changent radicalement, l’ancien code n’est donc plus aussi efficace s’il tirait parti de ces spécificités, mais continuera à fonctionner ; au contraire, pour la mémoire résistive, il n’y aurait plus de distinction entre la mémoire utilisée pour effectuer les calculs et celle pour le stockage à long terme.

Sources : Three paths to exascale supercomputing (paru en ligne sous le titre Power problems threaten to strangle exascale computing), FLOPS.

Merci à Claude Leloup pour ses corrections.

Conan, nouvelle tentative de gestionnaire de dépendances en C++

L’environnement des bibliothèques C++ peut être considéré en bonne approximation comme un capharnaüm : à moins de développer exclusivement sous Linux avec des bibliothèques relativement matures (et donc disponibles dans les différents gestionnaires de paquets), l’installation des dépendances (et de leurs dépendances respectives !) devient rapidement difficile pour gérer d’autres plateformes ou pour des bibliothèques moins courantes. Même dans ce cas idyllique, il n’est pas rare que les versions disponibles soient trop anciennes.

Conan vient combler ce déficit : en tant que gestionnaire de dépendances, il prend en entrée une série de bibliothèques requises pour un programme donné, puis il les télécharge et les compile si nécessaire, de telle sorte qu’il devient possible de compiler le programme demandé. De plus, Conan dispose déjà d’une grande base de données en ligne de bibliothèques compilées pour différentes plateformes en versions variées — plusieurs dizaines de bibliothèques, certaines très courantes en C++ comme Boost.

Ce projet ne vient pas de nulle part : il s’agit en réalité de Biicode, dont une très grande partie du code a été repris, suite à la faillite de la société derrière ce projet. Une chose a été améliorée depuis : la simplicité de création d’un paquet. Les contributeurs de Conan sont en grande partie des anciens de Biicode, avec des contributions comme des générateurs de fichiers de projet depuis lors. Actuellement, il n’y a aucune société derrière Conan, il s’agit plus d’un projet personnel. Bien que libre, l’objectif est de développer une société derrière pour faire vivre le projet et un modèle économique viable : les idées pour l’instant se rapprochent du modèle de GitHub, c’est-à-dire des paquets privés payants, même s’il a déjà échoué pour Biicode.

Découvrir Conan

Sources : Conan: One Month After Launch, Thanks!, Nerd Food: Dogen: The Package Management Saga

Juno, un EDI pour Julia

Julia est un langage très récent : sa première version date de 2012 et il est actuellement en version 0.4. Il est de plus en plus utilisé de par le monde, avec un public assez divers : quelques programmeurs dont c’est le métier, mais surtout des scientifiques, des ingénieurs, des analystes financiers, des statisticiens qui développent les bibliothèques de fonctions qui leur sont utiles. Pour que plus de gens utilisent le langage, il est nécessaire de fournir un environnement de développement complet et accessible pour ce public, avec de l’autocomplétion intelligente, l’intégration de graphiques, le débogage, etc. Cet environnement prend le nom de Juno.

Le développement est parti d’un composant proposé par GitHub, Atom, un éditeur de texte prévu pour être facile à personnaliser. Il a la particularité d’être basé exclusivement sur des technologies Web, c’est-à-dire qu’il est codé en HTML, CSS et JS, avec une architecture très modulaire (Juno est implémenté comme une série de modules, relativement indépendants les uns des autres, ce qui devrait faciliter leur réutilisation dans d’autres projets, comme Ink, celui chargé des composants graphiques d’un EDI). Il reste cependant accessible comme une application de bureau traditionnelle, en dehors du navigateur, par Electron (ex-Atom Shell).

La prochaine priorité sera le fignolage de l’utilisation interactive, plus particulièrement tout ce qui a trait au multimédia, aux graphiques interactifs. Ainsi, avec un seul téléchargement, les nouveaux utilisateurs pourront rapidement commencer à écrire quelques lignes de code Julia, à créer des graphiques très rapidement avec les paquets fournis de base. Ensuite, la documentation et le débogueur seront inclus (même si ce dernier doit encore être finalisé du côté Julia : les fonctionnalités sont actuellement au stade de prototype et ne sont pas incluses de base), avec un outil d’analyse de la performance du code.

Pour le téléchargement de la nouvelle version 1.1.0, direction le site de Julia. (La version sur le site de Juno est dépassée et ne fonctionne pas avec les versions actuelles de Julia et des paquets requis.)

Source : Julia IDE work in Atom.

Visual Studio en 64 bits ?

Visual Studio est l’environnement de développement intégré proposé par Microsoft. Il gère une pléiade de langages, historiquement des langages natifs comme C++, mais aussi toute la pile .Net avec C#, VB.Net et d’autres, y compris pour le Web. Il est souvent cité en référence comme environnement de développement. À l’origine payant, les éditions Express sont apparues en 2005 ; nettement moins limitées, les éditions Community sont beaucoup plus récentes.

Cependant, l’environnement est aussi connu pour ne pas toujours être extrêmement réactif, notamment dans le cas de projets de grande ampleur ou avec des extensions. Suite à un tweet de Gunnar Skogsholm, le débat sur une version 64 bits de Visual Studio est relancé : ainsi, l’environnement ne serait plus limité à quatre gigaoctets de mémoire vive, il pourrait exploiter toute la mémoire des machines actuelles, ce qui pourrait aider en performance. D’ailleurs, une série d’environnements de développement y sont déjà passés, comme Eclipse ou Android Studio — ces deux-là ayant la particularité d’être écrits en Java et de dépendre d’une JVM, les efforts de portage en 64 bits sont donc très limités.

Des raisons techniques

Rico Mariani, un ancien développeur de Visual Studio, maintenant passé dans l’équipe de Microsoft Edge (le nouveau navigateur de Microsoft), indique cependant que passer au 64 bits n’apportera pas grand-chose à l’EDI, cela risque même plus probablement de lui causer d’autres problèmes de performance. En effet, du côté technique, ces 64 bits correspondent à la taille d’une adresse en mémoire (ce qui permet d’indexer beaucoup plus de mémoire vive qu’en 32 bits) ; cette transition doublerait donc la taille de tous les pointeurs, ce qui a des impacts sur l’alignement en mémoire des structures de données, sur la densité des données stockées et donc la localité.

De manière générale, le code sera plus lourd, l’application occupera plus de place en mémoire en 64 bits plutôt qu’en 32 bits (dans un facteur qui dépend fortement de l’application considérée). Par conséquent, les caches du processeur seront moins bien utilisés, puisqu’il n’ont pas soudainement augmenté en taille ; les registres disponibles seront certes plus grands et plus nombreux, mais ce facteur n’a de réel impact que sur le code effectuant des traitements lourds (comme du calcul scientifique ou de l’analyse de données) plutôt que des interfaces graphiques. Cette migration en 64 bits ne se justifie donc que s’il est nécessaire d’utiliser plus de mémoire que la partie accessible en 32 bits.

Une autre justification est moins attendue : en 64 bits, une fuite de mémoire ne fera pas planter l’application rapidement, puisqu’elle pourra consommer toute la mémoire de l’ordinateur, le ralentir à l’extrême et le rendre complètement inutilisable. Ce genre de justification est encore plus valable pour un navigateur qui autorise des extensions.

Utiliser plus de mémoire est une erreur de conception, pour Rico Mariani

D’ailleurs, même si cette mémoire supplémentaire était utile, il y a d’autres options pour rester en 32 bits, notamment une représentation plus efficace des données en mémoire. Pour gagner en performance, cette solution est bien évidemment meilleure que d’exploiter plus de mémoire. L’idée est donc de prévoir son code pour que seule une partie de la mémoire requise doive résider en mémoire vive, c’est-à-dire stocker la plupart des données dans un fichier et s’assurer d’en avoir besoin très peu souvent.

En effet, pour qu’une application puisse se mettre à grande échelle, ce genre de techniques est souvent requis. Pour un client, l’approche est très positive : il est possible de faire bien plus avec moins de ressources. Par exemple, en 1989, même avec 640 ko de mémoire vive, il restait possible d’exploiter sans problème de performance une base de données de 24 Mo, simplement en gardant un cache de 12 ko de données intéressantes pour accélérer les opérations de recherche et de lecture. À l’heure d’aujourd’hui, les échelles monteraient plutôt à quelques téraoctets de données au moins à traiter, mais le principe reste d’application. Le conseil de Rico Mariani est de considérer les données comme une base de données relationnelle (SQL), puis de la charger par tranches en mémoire, au lieu d’exploiter des représentations plus naturelles pour un programmeur à base de pointeurs.

Cette migration n’est de toute façon pas encore utile

Ces considérations techniques éloignent le débat des points réellement importants pour une application : être agréable à utiliser. Utiliser telle ou telle technologie n’a aucun impact sur ce critère premier ; en réalité, utiliser aussi peu de technologies différentes est probablement une bonne chose. De même, utiliser plus de mémoire n’a pas d’impact direct sur l’utilisabilité : moins de mémoire pour la même expérience devrait être l’objectif. En d’autres termes, une migration en 64 bits n’a pas de sens pour l’utilisateur de Visual Studio.

De plus, elle coûte en temps de développement, qui pourrait être investi dans d’autres fonctionnalités. Notamment, les formats de fichiers binaires utilisent régulièrement des pointeurs, ce qui empêche une migration aisée entre 32 et 64 bits. Cette même évolution a longtemps été retardée par Firefox par manque de compatibilité avec un grand nombre de dépendances externes en 64 bits : il est difficile de ne pas effectuer une migration complète, c’est-à-dire seulement les quelques parties qui en bénéficieraient.

Depuis 2008, Visual Studio permet la création d’extensions chargées en dehors du processus principal de l’EDI, c’est-à-dire dans un processus séparé, avec un espace mémoire séparé. Ces extensions peuvent être réalisées de diverses manières : par exemple, le cÅ“ur de Visual Studio est assez léger, beaucoup de fonctionnalités sont proposées en extensions (comme les solutions), dont un nombre grandissant est écrit en C#, avec une exécution dans une machine virtuelle. Il est aussi possible de compiler ces extensions en 64 bits si nécessaire… et le fait est que très peu d’extensions le font, parce que ce changement ne leur est pas utile. Par contre, Resharper C++, une extension de JetBrains pour Visual Studio, à l’origine du retour de cette controverse, ne profite pas de cette possibilités et a des difficultés à gérer de grandes quantités de code.

Et Rico Mariani de conclure en disant qu’avoir un système d’exploitation 64 bits est extrêmement utile — ce qui n’est pas le cas de la majorité des applications.

Sources : Revisiting 64-bit-ness in Visual Studio and elsewhere, 64-bit Visual Studio — the « pro 64″ argument, Visual Studio: Why is there no 64 bit version? (yet).