Interview de James Reinders

Pendant la conférence, vous avez mentionné à de multiples reprises le compilateur C++ d'Intel et celui de Microsoft. Qu'en est-il du compilateur Clang, sponsorisé par Apple ?

Nous avons discuté avec eux et sommes très au courant de ce qu'ils font. Notre compilateur Fortran et C++ fonctionne avec Mac Os X, et nous comptons continuer ainsi. Beaucoup de gens apprécient que nous supportions plusieurs plate-formes, c'est une des principales raisons de la popularité de nos compilateurs.

Nous nous échangeons des plans, et parfois des technologies ou des revues avec Apple. J'ai assisté à une présentation chez Intel il y a environ 2 ans présentant comment ils s'éloignaient de gcc, et présentant la technologie LLVM (sur laquelle est construit Clang). Mais nous n'investissons pas de manière massive dans leur technologie de compilateur.

Pourquoi CILK est présenté à l'utilisateur, et non pas simplement utilisé en interne par des bibliothèque comme TBB.

L'objectif de CILK est de prendre un programme fonctionnel, et de le rendre parallèle avec le minimum de modifications, comme changer un for en cilk_for, un appel de fonction par un cilk_spawn. Son extrême simplicité devrait en faire un point d'accès aisé au monde du parallélisme. Sa syntaxe est faite de telle façon, qu'en ignorant les mots clefs spéciaux, on se retrouve avec le code initial, ce qui rend la compréhension facile.

Quand la prochaine version de Parallel Studio, compatible avec Visual Studio 2010, est-elle prévue ?

Le programme de bêta officiel devrait commencer vers mi-mai. La sortie est prévue pour la fin du troisième trimestre, nous espérons pouvoir le sortir pour l'IDF (Intel Developper Forum), à la mi-septembre, à San Francisco.

Quelles seront les nouvelles fonctionnalités ?

Tout d'abord, comme indiqué, le support pour Visual Studio 2010. Nous avons dû attendre que ce produit soit finalisé.

Le compilateur prendra aussi en compte Cilk, avec l'ajout de trois primitives, ainsi que la notation tableau. Cette notation sera comprise par le C et le C++. Voici quelques exemples :

a[:] = b[:] + 3; // Permet de copier les éléments d'un tableau à une dimension vers un autre

a[:] = b[3][:] * c[:][12]; // Extrait des vecteurs lignes ou colonnes pour faire des calculs

Cette notation, semblable à celle de Matlab, pourra automatiquement bénéficier d'une parallélisation, de SSE, d'AVX. Nous travaillons avec d'autres constructeurs de compilateurs, pour se mettre d'accord sur une syntaxe, et peut être au final, basé sur l'expérience apportée par une implémentation dans plusieurs compilateurs, en tirer une proposition pour les comités de normalisation C et C++.

Intel Parallel Advisor a été en phase d'incubation cette année, mais deviendra un produit à part entière dans cette version. Il permet d'accélérer une étape critique de développement parallèle. Quand on se lance dans la parallélisation, la première étape est d'essayer de voir où l'on souhaite paralléliser, la seconde est d'écrire le code correspondant, et d'effectuer des mesures.

Mais cette seconde étape peut être longue, des semaines ou des mois pour trouver les bugs, les race conditions, les deadlocks... pour parfois au final se rendre compte que ça ne marche pas aussi bien qu'on l'avait espéré. Nous essayons d'accélérer cette étape : Les développeurs ajoutent dans leur code des annotations indiquant leur souhait d'en paralléliser une portion, sans vraiment coder cette parallélisation. Un outil prend alors le relais pour analyser ce code, et indiquer : Si vous faites ça, vous allez avoir des race conditions, ou bien votre code ne sera pas scalable.

Ces notations permettent ainsi de prototyper rapidement le code, il n'est même pas nécessaire de l'exécuter sur une machine multi-cœurs. Ce produit est conçu pour aider les architectes à choisir entre différentes manières de paralléliser du code, avant d'investir dans la parallélisation elle-même.

Dans Visual Studio 2010, Microsoft a introduit la notion de tâche (par opposition aux threads) dans le débogueur. Avez-vous une notion semblable ?

Nous avons ajouté des annotations dans TBB afin que notre Inspector (qui détecte des races conditions) ou Amplifier (qui mesure des performances) comprenne la notion de tâche au sens TBB. Microsoft a fait de même avec les tâches de TPL et PPL afin que leur propre débogueur puisse les comprendre. Mais ces annotations ne sont pas compatibles. Nous étudions ce que nous pouvons faire afin d'harmoniser la situation, que nos outils comprennent les tâches de TPL et PPL, et que leurs outils comprennent les tâches de TBB.

Les utilisateurs veulent pouvoir utiliser un outil unique dans tous les cas. Nous avons déjà écrit des extensions à leur débogueur qui améliorent son comportement avec OpenMP, ils ont ajouté des extensions très agréables pour les tâches, nous regardons si on peut communiquer avec leur débogueur afin d'en tirer les même bénéfices avec TBB.

Une partie de Parallel Studio devrait être disponible sous Linux. Quand ? Quel ordre de grandeur de prix ?

Novembre. Le programme bêta devrait commencer en juin/juillet, pour une sortie du produit en novembre.

En terme de prix, on devrait être dans la même gamme que nos autres outils de développement (compilateur, VTune), et donc un peu plus cher que Parallel Studio. Le compilateur Fortran sera en option, ce qui pourrait augmenter le prix. Mais nous n'avons pas encore annoncé de tarif actuellement.

Les styles de programmation entre TBB et PPL sont très proches, pensez-vous qu'il est possible, en se restreignant à un sous-ensemble de ces bibliothèques, d'avoir un code source qui serait compatible avec ces deux bibliothèques ?

Il est vrai que ces bibliothèques sont très semblables dans leur interface. On pourrait imaginer un programme qui juste avec un peu de macros permettrait de basculer de l'un à l'autre. Ce qui est important, c'est que la sémantique est la même. Par exemple, il se passe la même chose quand on utilise le parallel_for de TBB et celui de PPL. La syntaxe peut légèrement varier, puisque par exemple ils gèrent les indices légèrement différemment de nous.

Pour les structures de données (concurrent_queue, concurrent_vector...), c'est encore plus vrai, puisqu'il s'agit du même code, Microsoft ayant repris le code d'Intel. Il n'y avait en effet aucune raison de ne pas avoir les mêmes structures de données.

Quelles sont les nouveautés de la version 3 de TBB ?

La version 3 va être officiellement annoncée la semaine prochaine. Tout d'abord, sous Windows, il y a l'utilisation du concurrency runtime, que Microsoft vient juste de sortir. Il y a aussi plein de modifications que je qualifierais d'entretien. Par exemple, on a effectué un certain nombre d'ajustements pour la prise en compte de C++0x. On gérait déjà les lambda-fonctions, par exemple dans un parallel for, mais pas dans l'ensemble de TBB, en particulier pour la gestion des pipelines.

Un autre exemple est la manière dont fonctionne le thread principal, qui a lancé les autres threads utilisés par TBB. En général, ce thread fait tourner des tâches, comme les autres threads, et ça ne pose pas de problème. Mais selon la manière dont on prend des verrous, ce comportement peut produire des deadlocks, et la nouvelle version permet de régler ce comportement, et de rendre le thread principal passif.

Ce que les utilisateurs de TBB apprécient beaucoup, c'est qu'elle est suffisamment mature pour être mise en œuvre, et résoudre de vrais problèmes dans de vrais programmes.

Est-ce que Ct sera distribué en open source ?

Pour l'instant, on ne sait pas vraiment quelle est la bonne façon de faire. Si TBB a été placée en open source, c'est parce que c'était la bonne manière de la rendre disponible sur de nombreuses plateformes. OpenMP présente un autre modèle, une API standardisée que plusieurs personnes peuvent implémenter.

Nous voulons que Ct soit disponible sur de nombreuses plateformes, et nous sommes en discussions avec des compagnies qui pourraient en réaliser un portage. Nous ne savons pas encore ce qui serait le mieux, entre une solution open source et une solution basée sur une API ouverte et des implémentations propriétaires tirant parti des bénéfices de chaque plateforme. Il est en tout cas probable que Ct ne soit pas uniquement une technologie propriétaire.

Nous voulons aussi avoir une API ouverte au niveau du front-end, afin de permettre l'interface avec d'autres langages, comme par exemple python ou perl.

Quels compilateurs seront supportés pour la première version ?

Au minimum, Intel Compiler, Microsoft Visual C++, et gcc. Mais la technologie n'est pas très dépendante du compilateur, et devrait marcher avec n'importe quel compilateur C++. On avait eu des problèmes avec TBB, en particulier sur la gestion des exceptions, qui nous avaient forcés à faire des modifications, par exemple pour le compilateur Solaris. C'était il y a longtemps, mais c'est pourquoi je ne m'avance pas plus pour Ct.

Quels sont les concepts techniques derrière Ct. Est-ce plus qu'une bibliothèque de matrice gérant la parallélisation ?

Ct crée le concept d'un environnement protégé, avec des variables sur lesquelles on ne peut pas tout faire (par exemple, prendre des pointeur dessus). Ça nous donne un contrôle complet sur ces variables, et on peut donc prendre en compte des processeurs spécialisés, de la mémoire distribuée... Le problème des variables en C et C++ est qu'il est possible de prendre leur adresse de tant de manières différentes, qu'on ne peut pas bouger les données en mémoire sans casser le programme.

Avec Ct, tant qu'on ne prend pas de pointeur sur une variable, on a donc une latitude d'optimisation supplémentaire, qui nous permet d'utiliser du GPGPU, l'architecture Larrabee, ou le CPU. Pouvoir bouger la donnée est donc l'un des concepts principaux de Ct.

La prise en compte de toutes ces architectures aura-t-elle lieu à la compilation ou à l'exécution ?

A l'exécution. Nous avons une technologie de JIT. Par exemple, quand on exécute le code, si l'on détecte la présence d'un GPU, on peut décider de lui déléguer tout un problème mathématique, ou encore de partager cette tâche entre un CPU et le GPU.

C'est un aspect important du design, ce n'est pas une simple bibliothèque de template générant directement du code, elle génère des opérations, qui seront ensuite envoyées vers un système gérant leur exécution. Ce système pourra décider de bouger les données, d'agréger ou pas des opérations, de les distribuer sur diverses unités de calcul...

Ce qui est intéressant, c'est que le code source reste simple, alors que tant de choses complexes sont utilisées pour le mettre en œuvre. Nous pensons que cette technologie de JIT va être très efficace, mais elle est complexe et nous devons faire attention à pleins de détails.

(Remarque : James doit m'envoyer des papiers entrant un peu plus dans les détails. Peut-être un prochain article ? Une présentation plus détaillée est aussi prévue pendant le salon SuperComputing aux US en novembre)

Qu'est-ce qui va changer dans Ct suite à l'acquisition de RapidMind ?

Principalement deux points :

Tout d'abord, ils avaient de très bonnes technologies pour cibler la GPU, nous allons en bénéficier. Ils nous permettent aussi de rendre plus prévisible notre technique de JIT.

Ensuite, ils ont de nombreux retours utilisateurs sur leur technologie, et ont pu proposer des modifications de syntaxe, comment la rendre plus en phase avec le C++ et plus simple. Par exemple, dans certains cas, du code écrit avec la syntaxe actuelle prend trois ou quatre fois plus de place que du code écrit avec la prochaine version.

Merci à Intel de m'avoir invité à cette conférence, et de m'avoir permis d'interviewer James Reinders

Merci à James Reinders de m'avoir accordé un peu de son temps au cours de sa journée marathon d'interviews

Merci enfin à evarisnea pour sa relecture !