Interview : La promesse d'Intel oneAPI et Direct Parallel C++

Intel n'est pas le premier nom qui vient à l'esprit quand on pense au développement de logiciels, même s'il s'agit de l'une des entreprises technologiques les plus influentes et les plus innovantes de la planète. Il y a quatre décennies, le processeur 8088 d'Intel a aidé à lancer la révolution du PC, et si vous lisez ceci sur un ordinateur de bureau ou un ordinateur portable, il y a de fortes chances que vous ayez un Intel Inside. Il en va de même pour les serveurs et une gamme d'autres matériels sur lesquels nous comptons tous les jours. Cela ne veut pas dire qu'AMD et d'autres fournisseurs n'ont pas de produits compétitifs parce qu'ils en ont, mais Intel domine toujours le marché des processeurs x86.

Les ingénieurs logiciels utilisent les plates-formes matérielles Intel depuis des décennies, généralement sans même tenir compte du logiciel et du micrologiciel qui les sous-tendent. S'ils avaient besoin de plus de performances de virtualisation, ils ont opté pour des produits multicœurs, hyperthreadés Core i7 ou Xeon. Pour bricoler la base de données locale, ils pourraient obtenir un SSD Intel. Mais maintenant, Intel souhaite que les développeurs commencent également à utiliser davantage ses logiciels.

Qu'est-ce qu'Intel oneAPI ?

Entrez oneAPI, présenté par Intel comme un modèle de programmation unique et unifié qui vise à simplifier le développement sur différentes architectures matérielles : processeurs, GPU, FPGA, accélérateurs d'IA, etc. Tous ont des propriétés très différentes et excellent dans différents types d'opérations.

Intel s'est désormais engagé dans une stratégie "logiciel d'abord" et s'attend à ce que les développeurs en tiennent compte. La grande idée derrière oneAPI est de permettre l'utilisation d'une plate-forme pour une gamme de matériels différents, de sorte que les développeurs n'auraient pas à utiliser différents langages, outils et bibliothèques lorsqu'ils codent pour les CPU et les GPU, par exemple. Avec oneAPI, la boîte à outils et la base de code seraient les mêmes pour les deux.

Pour rendre cela possible, Intel a développé Data Parallel C++ (DPC++) en tant qu'alternative open source aux langages propriétaires généralement utilisés pour programmer un matériel spécifique (par exemple, les GPU ou les FFPGA). Ce nouveau langage de programmation est censé offrir la productivité et la familiarité de C++ tout en incluant un compilateur à déployer sur différentes cibles matérielles.

Data Parallel C++ intègre également le SYCL de Khronos Group pour prendre en charge le parallélisme des données et la programmation hétérogène. Intel offre actuellement un accès gratuit à son DevCloud, permettant aux ingénieurs logiciels d'essayer leurs outils et de bricoler avec oneAPI et DPC++ dans le cloud sans trop de tracas.

Mais attendez, cela fonctionnera-t-il sur du matériel fabriqué par d'autres fournisseurs ? Qu'en est-il des licences, est-ce gratuit ? Oui et oui : oneAPI est conçu pour être indépendant du matériel et open source, et cela ne changera pas.

Pour en savoir plus sur oneAPI, nous avons discuté de sa genèse et de son avenir avec Sanjiv M. Shah, vice-président du groupe architecture, graphiques et logiciels d'Intel et directeur général de l'informatique technique, d'entreprise et cloud chez Intel.

Sanjiv : En ce qui concerne ce qu'il y a dans oneAPI, j'y pense en quatre parties. L'un est un langage et une bibliothèque standard, le second est un ensemble d'outils d'apprentissage en profondeur, le troisième est vraiment une couche d'abstraction matérielle et une couche de pilote logiciel qui peut abstraire différents accélérateurs, et le quatrième est un ensemble de bibliothèques axées sur le domaine , comme Matlab et ainsi de suite. Ce sont les quatre catégories de choses dans oneAPI, mais nous pouvons aller plus loin et parler des neuf éléments de oneAPI. Ces neuf éléments sont essentiellement le nouveau langage que nous introduisons appelé Data Parallel C++ et sa bibliothèque standard.

Il existe deux bibliothèques d'apprentissage, une pour les réseaux de neurones et une pour les communications. Il y a la bibliothèque que nous appelons le niveau zéro qui est pour l'abstraction matérielle, et il y a quatre bibliothèques axées sur le domaine. Nous le faisons de manière très, très ouverte. Les spécifications de tous ces éléments sont déjà ouvertes et disponibles. Nous les appelons la version 0.5. Nous avons l'intention de passer à la version 1.0 d'ici la fin de 2020, et nous avons également des implémentations open source de tout cela. Encore une fois, notre objectif est de permettre aux gens de tirer parti de ce qui existe déjà. Si un fournisseur de matériel souhaite implémenter ce langage, il peut prendre ce qui est open source et l'exécuter.

Q : En ce qui concerne les algorithmes et la mise en œuvre, comment cela fonctionne-t-il ?

Ce que nous fournissons, ce sont les primitives que les algorithmes utiliseraient : les primitives mathématiques sous-jacentes et les primitives de communication. En règle générale, l'innovation des algorithmes se produit à un niveau plus élevé que cela, où ils ne refont pas vraiment les mathématiques fondamentales, les mathématiques matricielles, les mathématiques de convolution, etc. Il s'agit de trouver de nouvelles façons d'utiliser ces mathématiques et de nouvelles façons d'utiliser les modèles de communication. Notre objectif est vraiment de fournir le primitif, le niveau zéro, afin que d'autres puissent innover en plus.

Q : Comment cela fonctionne-t-il au niveau matériel ?

Si vous êtes un fournisseur de matériel, prenons une matrice d'IA, quelqu'un qui construit un ASIC d'IA, par exemple, il y a deux façons pour ce fournisseur de matériel de « se brancher » et de tirer parti de l'écosystème d'IA. L'une serait de fournir cette interface matérielle de bas niveau que nous appelons le niveau zéro, et s'ils fournissent leur version du niveau zéro en utilisant l'API standard, ils peuvent tirer parti de l'open source s'ils le souhaitent, puis de toutes les couches logicielles au-dessus peut automatiquement en tirer parti.

Cela pourrait être difficile pour un ASIC axé sur le segment, de fournir toute la généralité du niveau zéro. Donc, comme alternative à cela, ils peuvent également simplement fournir les noyaux mathématiques et les noyaux de communication qui se trouvent dans notre domaine et les bibliothèques d'apprentissage en profondeur, puis nous ferons le travail de « plomber » ces bibliothèques dans les cadres de niveau supérieur, donc ils l'obtiendraient automatiquement.

Q : Vous avez mentionné que la version que vous avez actuellement est désignée 0.5 et que la spécification complète devrait être prête d'ici la fin de 2020.

Donc, il y a deux parties dans notre initiative oneAPI. L'un concerne l'industrie et l'autre les produits Intel. La spécification de l'industrie est de 0,5, et vers le milieu de l'année, nous aimerions l'amener à 1,0. Parallèlement à cela, Intel construit un ensemble de produits, et les produits qu'Intel construit sont aujourd'hui en version bêta et ils implémentent la spécification 0.5. D'ici la fin de l'année, nous aimerions arriver à un produit 1.0.

Le produit d'Intel va au-delà des neuf éléments de oneAPI car, en plus des éléments de programmation de base que nous fournissons, nous voulons également fournir les choses dont les programmeurs ont vraiment besoin, comme des débogueurs, des analyseurs et des outils de compatibilité afin qu'ils migrent des langages existants vers les données Langage C++ parallèle.

Q : À quel point la transition est-elle difficile pour le développeur ? L'environnement plus large est-il similaire à celui qu'ils utilisent depuis des années ?

Oui, c'est très similaire. Permettez-moi de décrire un peu Data Parallel C++ car c'est une grande partie de ce que nous faisons. DPC++ est trois choses. Il s'appuie sur le langage C++ de la norme internationale ISO. Il existe un groupe appelé Khronos qui définit la norme appelée SYCL, et SYCL est superposé à C++. Nous prenons SYCL, puis nous ajoutons des extensions au-dessus de SYCL. La façon dont nous construisons Data Parallel C++, c'est vraiment juste du C++ avec des extensions dessus, c'est ce qu'est SYCL.

N'importe quel compilateur C++ peut le compiler. La beauté de DPC++ est que n'importe quel compilateur peut le compiler, seul un compilateur expérimenté peut tirer parti de ce qu'il y a dans ce langage et générer du code accélérateur. La façon dont nous menons ce langage, nous le faisons très, très ouvertement, donc toutes nos discussions sur Data Parallel C++ se déroulent avec le comité SYCL. Les implémentations sont open-source, toutes les extensions sont déjà publiées, et nous travaillons très, très soigneusement pour nous assurer que nous avons une belle trajectoire vers les futures normes SYCL. En regardant dans 5 à 10 ans, un chemin de descente vers ISO C++ également.

Q : En ce qui concerne les compilateurs et la migration vers DPC++, la courbe d'apprentissage ne devrait pas poser de problème ?

Oui, cela dépend d'où vous partez, bien sûr. Pour un programmeur C++, la courbe d'apprentissage serait très courte. Pour un programmeur C, vous devriez surmonter l'obstacle de l'apprentissage du C++, mais c'est tout. C'est du C++ très familier. Pour un programmeur habitué à des langages comme OpenCL, cela devrait être très similaire.

L'autre partie que je dois souligner est que nous faisons le travail en open source en utilisant l'infrastructure LLVM. Toutes nos sources sont déjà ouvertes, il y a un référentiel Intel GitHub où vous pouvez aller voir l'implémentation du langage, même télécharger un compilateur open-source. Tous les outils Intel, nos offres de produits en version bêta sont également disponibles gratuitement pour que tout le monde puisse jouer avec et télécharger. Nous avons également un cloud développeur disponible, où les gens n'ont pas besoin de télécharger ou d'installer quoi que ce soit, ils peuvent simplement écrire le code et commencer à utiliser tous les outils dont nous avons parlé.

Q : C++ est performant et relativement simple, mais nous savons tous qu'il vieillit, que le développement est lent, qu'il y a trop d'intervenants, donc ils ralentissent tout. Ce ne serait évidemment pas le cas avec DPC++. Vous auriez des itérations et des mises à jour beaucoup plus rapides ?

Je pense que vous avez atteint un point très, très important pour nous, qui est une évolution rapide qui n'est pas ralentie par les normes. Donc, nous voulons faire nos discussions ouvertement avec la norme, donc il y a un moyen d'entrer dans les normes, mais nous voulons aussi le faire rapidement.

Les langages fonctionnent mieux lorsqu'ils sont co-conçus par leurs utilisateurs et implémenteurs, à mesure que les architectures évoluent. Notre objectif est une conception de code itérative très rapide où nous pratiquons des choses, trouvons la meilleure façon de faire les choses et les standardisons. Donc, absolument, une itération rapide est un objectif important.

Q : Une question qui a été soulevée par certains de mes collègues (vous pouvez probablement comprendre qu'ils sont quelque peu préoccupés par l'ouverture avec tout ce qui vient d'une grande entreprise) : DPC++ restera-t-il toujours ouvert à tous les utilisateurs et fournisseurs ?

Absolument! La spécification est faite avec une licence creative commons. N'importe qui peut utiliser la spécification, la prendre et la bifurquer s'il le souhaite, et la faire évoluer. Je tiens à souligner que tous les éléments de oneAPI ne sont pas open source, mais nous sommes sur la bonne voie pour rendre presque tous les éléments open source. Tout cela, n'importe qui peut le saisir et l'exploiter - il est disponible pour la mise en œuvre.

Codeplay, qui est une société basée au Royaume-Uni, a annoncé une implémentation Nvidia de DPC++, et nous encourageons vraiment tous les fournisseurs de matériel et de logiciels à faire leur portage. Nous sommes à un point unique dans l'industrie où les accélérateurs deviennent communs à plusieurs fournisseurs. Lorsque cela se produit dans l'histoire, lorsqu'il n'y a qu'un seul fournisseur, sa langue domine. L'industrie du logiciel exige une solution standard et plusieurs fournisseurs.

Ce que nous essayons de faire ici est ce que nous avons fait il y a environ deux décennies et demie avec OpenMP, où il y avait plusieurs langages parallèles mais aucun vraiment dominant. Nous avons pris tout cela et l'avons unifié dans une norme qui, 25 ans plus tard, est la façon de programmer pour le HPC.

Q : Serait-il exact de dire que DPC++ va connaître de nombreuses évolutions au cours des prochaines années ? Qu'en est-il des tenseurs, qu'en est-il du nouveau matériel qui sort ?

Oui, tout à fait, vous avez raison. Nous devons faire évoluer le langage pour prendre en charge le nouveau matériel qui sort. C'est l'objectif d'une itération plus rapide. Un autre point que je tiens à souligner est que nous concevons Data Parallel C++ afin que vous puissiez également brancher des extensions spécifiques à l'architecture si vous le souhaitez.

Ainsi, bien qu'il s'agisse d'un langage standard que nous souhaitons exécuter sur plusieurs architectures, nous réalisons également que parfois, un public, un public très important, a besoin du maximum de performances possible. Ils voudront peut-être se plonger dans une programmation de très bas niveau qui ne sera pas nécessairement portable par architecture. Nous construisons des extensions et des mécanismes afin que vous puissiez avoir des extensions pour les tenseurs et ainsi de suite qui seraient spécifiques à l'architecture.

Q : Quel degré de contrôle un développeur peut-il avoir sur le code généré pour le matériel ? Quel contrôle peuvent-ils avoir sur la gestion de la mémoire entre le système et les différents accélérateurs ?

Nous empruntons le concept de tampons à SYCL, qui donnent un contrôle très explicite de la mémoire à l'utilisateur, mais en plus de cela, nous ajoutons également la notion de mémoire unifiée . Notre objectif est de permettre au programmeur d'avoir le niveau de contrôle dont il a besoin, non seulement pour gérer la mémoire, mais aussi pour générer du code rapide. Certaines des extensions que nous ajoutons à SYCL sont des éléments tels que des sous-groupes, des réductions, des canaux, etc. Cela vous permettra de générer un bien meilleur code pour différentes architectures.

Q : Un point intéressant est la distribution oneAPI pour Python : Intel a spécifiquement répertorié NumPy, SciPy, SciKit Learn. Je suis curieux de connaître le gain de performances et les avantages de productivité qui pourraient être débloqués via oneAPI. Avez-vous des mesures à ce sujet?

C'est une excellente question. Nous appuyons cet écosystème. Pourquoi Python voudrait-il utiliser un accélérateur ? Il s'agit d'obtenir des performances de ses bibliothèques mathématiques, de ses bibliothèques d'analyse. Ce que nous faisons, c'est "plomber" NumPy, SciPy, SciKit Learn, etc., afin que nous puissions obtenir de bonnes performances en tirant parti des bibliothèques que nous avons en plus. L'implémentation par défaut de NumPy, SciPy, SciKit Learn, etc., par rapport à celle qui est correctement intégrée avec des packages natifs optimisés, peut générer des gains très, très importants. Nous avons vu des gains de l'ordre de 200x, 300x, etc.

Notre objectif avec Python est que nous voudrions obtenir une fraction raisonnable, à moins de 2x, peut-être à moins de 80% des performances du code natif. L'état de l'art aujourd'hui est que vous êtes souvent à 10x ou plus. Nous voulons vraiment combler cet écart en plombant toutes les tâches hautes performances afin que vous soyez dans un facteur de 2, et en fait beaucoup plus élevé que cela.

Q : De quels types de matériel parlons-nous ? Les développeurs pourraient-ils libérer ce potentiel sur un poste de travail ordinaire, ou faudrait-il quelque chose d'un peu plus puissant ?

Non, ce serait partout. Si vous réfléchissez à l'origine du gain, vous comprendrez. Les bibliothèques Python normales n'utilisent aucune des fonctionnalités de virtualisation sur les processeurs. Ils n'utilisent aucune des capacités multicœurs des processeurs. Ils ne sont pas optimisés, le système de mémoire et tout ça n'est pas optimisé. Donc, cela se résume à une multiplication matricielle écrite par un programmeur naïf et compilée par un compilateur sans aucune optimisation, puis comparez cela à ce qu'un expert écrit en code assembleur. Vous pouvez voir des gains multi-100x lorsque vous comparez ces deux, et dans le monde Python, essentiellement, c'est ce qui se passe.

Les interpréteurs Python et les bibliothèques standard sont de si haut niveau que le code avec lequel vous vous retrouvez devient un code très, très naïf. Lorsque vous le plombez correctement avec des bibliothèques optimisées, vous obtenez ces énormes gains. Un ordinateur portable a déjà deux à six ou huit cœurs de processeur, ils sont multithreads et ont des capacités de vectorisation assez décentes, peut-être 256, peut-être 512. Il y a donc beaucoup de performances dans les ordinateurs portables et les postes de travail. Lorsque vous faites évoluer cela jusqu'aux GPU, une fois que vous avez des graphiques disponibles, vous pouvez imaginer d'où viennent les gains.

Si vous regardez nos graphiques intégrés, ils deviennent également très puissants. Je suis sûr que vous avez vu l'Ice Lake Gen 11, où les graphismes intégrés sont nettement meilleurs que la génération précédente. Vous pouvez voir d'où proviendraient les avantages, même sur les ordinateurs portables.

Q : Qu'en est-il de la disponibilité de DevCloud ? Si je me souviens bien, son utilisation est gratuite pour tout le monde pour le moment, mais cela restera-t-il ainsi après votre médaille d'or l'année prochaine ?

C'est une bonne question. À ce stade, je vais être honnête, je ne connais pas la réponse. Notre intention à ce stade est qu'il soit gratuit pour toujours. C'est pour le développement, pour jouer, et il y a beaucoup de puissance là-bas, donc les gens peuvent réellement faire leurs courses.

Q : Cela ne vous dérangerait donc pas si nous demandions à quelques milliers de développeurs de tenter le coup ?

Oh, absolument pas. Nous aimerions que cela se produise !

Je peux résumer ce que nous essayons de faire. Tout d'abord, nous sommes très, très enthousiasmés par oneAPI. Il est temps qu'une solution multi-fournisseurs prenne son envol, car il existe actuellement plusieurs fournisseurs sur le marché. Si vous jetez un coup d'œil à notre gamme de processeurs, pas seulement aux GPU qui arrivent, aux GPU intégrés de plus en plus puissants et à notre feuille de route FPGA, c'est un moment passionnant pour construire une norme pour tout cela. Notre objectif est la productivité, la performance et l'infrastructure de l'industrie afin que vous puissiez en tirer parti.

En ce qui concerne les trois publics dont j'ai parlé, les développeurs d'applications peuvent facilement tirer parti des choses, car elles sont déjà disponibles. Les fournisseurs de matériel peuvent tirer parti de la pile logicielle et brancher de nouveaux matériels, tandis que les fournisseurs d'outils et de langages peuvent facilement l'utiliser. Intel ne peut pas créer tous les langages et tous les outils du monde, il s'agit donc d'une infrastructure open source que d'autres peuvent exploiter et développer très facilement.