Interview de James Reinders (Intel)

Quel est votre rôle chez Intel ?

Mon travail comporte deux aspects : Je suis le directeur vente et marketing pour les logiciels de développement Intel, et je suis aussi le principal évangéliste de nos produits. J'ai une formation d'ingénieur, j'aime nos produits et ce qu'on peut en faire, et je donne des conférences, des formations. J'ai aussi écrit des livres (un sur Vtune et un sur les thread building blocks). J'aime garder mes mains dans la technologie, ce qui n'est pas très typique pour quelqu'un faisant du marketing.

Quel est l'intérêt d'Intel pour le logiciel ?

Nous sommes un éditeur et vendons nos produits. Beaucoup de revendeurs distribuent nos logiciels, ça nous rapporte de l'argent, et ça compte beaucoup pour nous. Mais le plus important pour nous reste de fournir un logiciel qui permette à notre matériel de fonctionner. Et je pense que c'est une bonne chose. On peut être très innovants sur le matériel, et sortir de nouveaux concepts très intéressants, comme SSE4.1 et 4.2 et AVX, mais il est important que l'entreprise qui fournit le matériel fournisse aussi le logiciel qui permet d'en tirer profit. Toute l'industrie en profite.

Et ça nous permet aussi d'avoir un retour. Les développeurs ne le savent peut-être pas, mais ils ont un impact important sur la conception de nos processeurs. Les outils que nous vendons nous donnent une grande expérience dans le support à l'utilisation de nos processeurs par les développeurs.

Ainsi, nos experts en logiciel rencontrent des développeurs qui eux sont experts dans leurs domaines, et nous avons une influence sur la façon dont Intel conçoit les futures générations de processeurs. Ce retour nous évite de développer des processeurs que personne ne pourrait utiliser. Le multi-cœurs, par exemple, est un domaine important, et je suis fier d'aider à en tirer parti. C'est un problème ancien, et on fait des progrès dans la manière de l'aborder.

Parallel studio n'arrive-t-il pas un peu tard, alors que les machines multi-cœurs sont déjà omniprésentes ?

En fait je pense qu'on est dans les temps, voire légèrement en avance. Quand un processeur est disponible, par exemple avec du dual-core, c'est très difficile de convaincre quelqu'un de développer pour ce processeur, quand personne d'autre ne le fait. Désormais, presque tous les processeurs ont au moins 2 cœurs, mais les gains se font sentir de manière bien plus sensible avec 4 ou 8 cœurs, ce qui justifie plus l'effort requis pour que le logiciel en tire partie.

Nous ne sommes pas en retard, car la plupart des développeurs n'ont pas encore développé en parallèle. La majorité du parc installé était encore il y a peu avec un seul cœur, nous sommes en train de basculer.

Pensez-vous que le développement parallèle va rester confiné à quelques développeurs, ou va-t-il devenir commun ?

Le développement parallèle auquel nous sommes habitué, avec les threads windows ou les pthreads ne sera jamais grand public. Quand on prend un niveau d'abstraction plus élevé, comme ce que permettent les TBB, il devient un peu plus accessible, mais je ne crois toujours pas que tout le monde peut l'utiliser. Mais je pense qu'au fur et à mesure que l'on ajoute des couches plus haut niveau, comme Ct, ou le framework basé sur des acteurs de Microsoft qui peut être intéressant dans certains cas, on progresse.

Et peut-être qu'on se réveillera dans 10 ans, et que tout le monde fera du développement relié au parallèle. Ils ne le feront peut-être pas explicitement, peut-être utiliseront-ils des bibliothèques comme la bibliothèque SQL parallèle de Microsoft(1), mais leur code sera parallèle.

Parallel studio contient le compilateur C++ d'Intel. Quel est son niveau de compatibilité avec celui de Microsoft. Est-ce qu'il risque d'être un frein à l'adoption du produit ?

Il est extrêmement compatible. Aucun compilateur n'est parfait, celui de Microsoft pas plus qu'un autre, il n'implémente pas toujours le standard à la perfection. Nous détectons donc la version du compilateur Microsoft installée, et nous nous comportons de manière aussi proche que possible de celle-ci. Par exemple, et c'est une nouveauté de la version du compilateur dans Parallel Studio, nous générons des messages d'erreur avec les même codes, de manière à être compatible avec des outils comme des filtres qui utilisent ces numéros.

Nous travaillons très dur pour être compatible au niveau du source comme du code compilé. Vous pouvez mélanger librement des modules compilés par ces deux compilateurs : Le name mangling est identique, les tables de code sont les mêmes.

En terme de performance, il peut être intéressant d'utiliser notre compilateur dans Parallel Studio. Il possède par exemple des fonctionnalités comme le support d'Open MP 3.0 (Open MP 2 pour Microsoft). Mais si vous désirez utiliser le compilateur de Microsoft, de nombreux modules de Parallel Studio continueront de fonctionner : Parallel Inspector , Parallel Amplifier, Thread Building Blocks, IPP. Certaines options de debug fournies avec Parallel Composer demandent un code compilé par le compilateur Intel, mais globalement, nous n'imposons pas de compilateur. Finalement, nous avons voulu que le basculement d'un compilateur à l'autre soit immédiat. Il suffit de choisir une option dans un menu.

Votre compilateur est-il entièrement développé par Intel, ou est-il basé sur un front-end spécifique, comme celui d'EDG ?

Nous utilisons le front-end d'EDG depuis plus de 10 ans. Ils sont vraiment très bons. Nous travaillons aussi en partenariat avec eux pour ajouter à leur produit certaines extensions des compilateur Microsoft ou GNU, ce qui bénéficie à tout le monde. Le reste du compilateur (back-end, optimisateur...) est développé par Intel.

Votre compilateur est-il à même d'utiliser de lui même les extensions SSE ou faut-il écrire du code spécifique ?

Notre compilateur est très agressif dans son utilisation de SSE. Lorsque ces instructions ont été ajoutées au processeur, nous avons eu des discussions sur la manière de les concevoir pour qu'elles puissent être utilisées automatiquement par le compilateur, et nous les avons implémenté dans le compilateur en avance de phase afin de vérifier que c'était bien le cas.

Notre compilateur peut déjà profiter d'AVX, le successeur de SSE qui utilise 256 bits au lieu de 128, ainsi que de l'architecture Larabee et ses 512 bits. Bien entendu, on peut toujours aller plus loin dans l'optimisation, mais notre compilateur obtient des gains de temps non négligeables et fait déjà un travail tout à fait correct. Je ne pense pas qu'il existe un autre compilateur qui tire aussi bien parti de SSE que le notre, mais ils essayent...

Les Thread Building Blocks existent depuis un certain temps maintenant, pouvez-vous nous parler des nouveautés de la version fournie avec Parallel Studio, comme par exemple l'utilisation des λ-fonctions ?

Lorsque les TBB sont sorties, nous haïssions le fait que le C++ ne possède pas de λ-fonctions. Ça en rend l'utilisation si peu élégante. Notre équipe voulait presque les ajouter à notre compilateur, et tant pis pour le respect du standard C++. Mais maintenant que le standard C++ les définit, on en profite.

Il y a d'autres évolutions dans les TBB. Déjà, elles sont portées sur un nombre toujours plus important de processeurs. Ensuite, les premières versions supposaient que l'ensemble des tâches allait avancer en permanence, et créaient donc autant de threads qu'il y avait de cœurs disponibles. Ça marche bien pour tout ce qui est calcul, mais moins pour les entrées/sorties, où l'on est souvent en attente. Il est désormais possible de définir une tâche comme étant une tâche d'E/S, et cette dernière sera exécuté dans un thread supplémentaire, afin d'utiliser tous les cœurs de manière optimale.

Quels sont les liens entre TBB et le Concurrency Runtime de Microsoft

Les TBB sont disponibles pour de nombreuses architectures, nous adapterons les TBB pour que sous Windows, elles puissent tourner par dessus le Concurrency Runtime dès qu'il sera disponible. Nous avons déjà demandé à Microsoft d'y ajouter des éléments dont nous avons besoin pour y parvenir.

Les développeurs Linux peuvent-ils espérer développer avec Parallel Studio un jour ?

Le compilateur et les bibliothèques marchent déjà sous Linux. L'année prochaine, nous comptons sortir une nouvelle version de nos produits (V-Tune, Thread profiler et Thread checker) bénéficiant des avancées que nous avons effectuées dans le cadre de Parallel Studio. Je ne sais pas encore s'ils sortiront sous leur noms actuels, ou s'ils seront renommés Inspector et Amplifier. Beaucoup des technologies les plus avancées prennent naissance sous Linux, nous n'oublions pas cet environnement.

Avez-vous des outils pour d'autres langages que C++ et Fortran ? Certains langages sont ils meilleurs que d'autre pour le parallélisme ?

Inspector et Amplifier travaillent avec n'importe quel langage compilé. Un programme qui mixerait C++ avec par exemple du Java ou du C# pourrait aussi être analysé, mais nous nous concentrons sur le code natif. Je pense que nous allons ajouter quelques fonctionnalités pour aller un peu plus vers C# et peut-être Java, mais ce n'est pas encore défini.

Avec Ct, on se pose la question de faire du parallélisme de données dans d'autres langages, c'est certainement un très bon moyen de démocratiser le parallélisme. Python pourrait être un bon exemple. Nous sommes ouverts aux suggestions sur le sujet.

Pensez-vous que Python soit en train de remplacer Fortran pour l'informatique scientifique ?

D'une certaine manière oui. Les programmes existants en Fortran restent en Fortran, mais pour les nouveaux programmes, Python et Matlab sont très populaires. En particulier, dans les sciences de la vie, où l'usage de l'informatique est plus récent, et où Fortran n'a pas la base installée qu'il peut avoir par exemple en électricité, Python est très populaire.

Le plus important, pour les scientifiques, est de pouvoir écrire dans un langage qu'il maîtrisent, de pouvoir innover, faire évoluer le programme. À partir du moment où ils confient le développement à un développeur, pour des raisons de performance ou de taille du code, et que ce développeur commence à utiliser un langage moins simple, ils perdent cette flexibilité. C'est ce qui fait que Python marche pour ces gens. Et Ct, avec sa notation proche des mathématique pourrait apporter le parallélisme par les données à ces communautés, d'où notre intérêt pour ce langage.

Des outils comme Inspector travaillent en instrumentant l'exécutable et en effectuant des mesures en cours d'exécution. Y a-t-il des outils qui vérifient un programme parallèle de manière statique ?

Notre compilateur peut réaliser quelques tests, mais avec les vérifications statiques, on a le dilemme suivant : Soit on veut détecter tous les problèmes potentiels, mais on aura de nombreux faux positifs, et les gens détestent ça, soit on ne signale que les cas où l'on est certain qu'il y a une erreur, mais on passe à côté de beaucoup de choses. On peut avoir des résultats corrects pour la détection statique des deadlocks, mais pour les data races, qui sont le problème le plus courant, il y a bien trop de faux positifs.

Donc, en pratique, une vérification dynamique est plus efficace. D'autant plus que nous n'attendons pas qu'une erreur de parallélisme produise vraiment des effets néfastes pour la détecter. Dès que deux threads accèdent au même emplacement mémoire sans utiliser de locks, nous le signalons. La vérification est en pratique limitée aux endroits du programme qui sont exécutés, ce qui demande à l'utilisateur d'exercer l'ensemble de son code, mais ce n'est pas un véritable problème.

Il y a 3 ou 4 ans, nous avons acquis une société qui possédait un autre produit nommé Assurer, qui travaillait en instrumentant le code à la compilation. Quand nous l'avons repris pour sortir Thread Checker, on a décidé d'instrumenter directement le binaire, après la compilation, ce qui permet aussi d'instrumenter des DLL et exécutables pour lesquels on ne possède pas le code source. Quand la première bêta est sortie, nous l'avons diffusée à 15 utilisateurs. J'espérais que parmi eux, 1 ou 2 trouveraient un problème grâce à cet outil. En fait, tous les 15 ont trouvé un data race dans un programme qui était déjà mis sur le marché. Et ces race conditions étaient réelles, elles pouvaient arriver, et elles étaient peut-être déjà arrivées chez certains de leurs clients, provoquant un plantage. Nous avons discuté avec eux, et dans chaque cas, il y avait un conflit entre leur code et du code tiers. Ça m'a vraiment ouvert les yeux sur le fait que les data races sont dans les interactions entre différentes parties du logiciel. C'est un autre problème des vérifications statiques, elles demandent à avoir accès au code source, et passent généralement à coté de ce genre de problèmes.

Avez vous entendu parler du projet de recherche Chess de Microsoft, qui a pour objectif de tester du code multithread en contrôlant comment les différents threads d'exécution s'entrelacent de manière à reproduire les race conditions de manière déterministe ?

En effet, j'ai assisté à une présentation de ce projet au PDC(2), mais je ne suis a priori pas très convaincu par cette approche. Il essayent de forcer une erreur à apparaître, ce qui est une approche novatrice, mais avec laquelle on n'est jamais certains d'avoir écrit suffisamment de tests. Ce que nous tentons de faire avec Parallel Inspector, c'est détecter la possibilité d'une erreur, même si elle ne s'est pas manifestée au cours de l'exécution.

Un certain nombre de personnes chez Microsoft semblent très excitées par ce projet, donc je suis peut-être passé à côté de quelque-chose. En tout cas, il est très important de rester à l'écoute de toutes les techniques qui peuvent rendre le débogage de programmes parallèles plus simple.

Que pensez-vous des évolutions de C++0x concernant le multithread ?

Avoir un modèle mémoire(3) bien défini rend un langage meilleur, plus portable, mais d'un autre côté, ça complexifie la tâche pour un compilateur de tirer tous les avantages possibles du matériel. Habituellement, chez Intel, les gens proches du matériel aiment bien qu'un langage soit un peu plus ambigu, mais au final, c'est un avantage pour le logiciel que tout soit clairement défini. Je suis certain qu'il y a certains points avec lesquels on peut être plus ou moins d'accord, mais ce qui compte le plus n'est pas tant la manière dont les choses sont définies, que le fait qu'il y ait une chose clairement définie.

Le C++0x ne contient pas de fonctionnalités pour adresser les deux problèmes du parallélisme : le déterminisme ou le scaling. Ce qu'il fait, et qui est important, c'est fournir un langage plus solide à partir duquel on peut construire des outils qui adressent ces problèmes. Et je suis content qu'ils n'aient pas été distraits en tentant d'ajouter des fonctionnalités haut niveau pour le parallélisme. Je pense que ces fonctionnalités sont plus du ressort d'une bibliothèques comme TBB, PPL or Ct. Je pense qu'il reste beaucoup d'expérimentation à faire avant d'en faire des parties permanentes d'un langage.

Le comité de normalisation du C++ a généralement fait un bon travail en ne standardisant quelque-chose que quand on est certain que l'on en a besoin, et que les compilateurs peuvent l'implémenter. Le comité Fortran, de son côté, a fait des standards qui ne sont pas implémentés en 6/7 ans. Personne n'a un compilateur compatible Fortran 2003, même si on s'en approche.

Que pensez-vous de la bibliothèque pour le parallélisme que Microsoft va inclure dans VC++10, PPL ?

Ma première réaction est que j'aurais souhaité qu'ils utilisent simplement TBB, car je ne pense pas qu'elle résolve un problème différent. Je pense que ces bibliothèques vont être assez similaire, et je pense que l'on pourra faire de TBB un sur-ensemble de ce qu'ils feront. C'est ce que nous comptons faire, ainsi, si on utilise leur bibliothèque, et qu'il manque quelque-chose, il sera possible de basculer vers TBB. Même sur le plan syntaxique, on va tenter d'être très proche d'eux, quitte à fournir une double interface pour certaines fonctions.

Je pense que les gens verront que TBB marche mieux que PPL, mais je n'ai pas de preuves à ce sujet, PPL est dans une phase préliminaire, n'a pas encore été livré, sa définition évolue encore, il faut voir où ça ira. TBB est sur le marché depuis un long moment, beaucoup de gens l'utilisent, et elle a bénéficié de leurs retours. Par exemple, ce dont je vous parlais sur la gestion des E/S dans la nouvelle version de TBB, n'a pas encore d'équivalent pour PPL. Enfin, TBB est portable, ce qui n'est pas prévu pour PPL.

Quelles différences y a-t-il entre la version libre de TBB et celle fournie dans Parallel Studio ?

Techniquement : aucune, c'est le même code source. La version livrée avec Parallel Studio est une version commerciale, avec un support et le code source n'est pas fourni. La version libre ne bénéficie pas de support de la part d'Intel, vous devez aller dans des forums pour trouver de l'aide. Mais pour être honnête, les gens n'ont pas l'air d'avoir besoin de beaucoup de support pour utiliser TBB.

La version libre est sous licence « GPL with Classpath exception », ce qui signifie qu'on peut se lier avec depuis un programme non GPL. C'est un peu comme la licence LGPL, mais la définition de se lier pour LGPL vient du C, et pour une bibliothèque comme TBB, qui utilise des templates, ce n'est pas suffisant. Mais pour certains clients, c'est important d'avoir une version commerciale, qui ne soit pas GPL, sans cela, ils n'utiliseraient pas TBB. D'autres projets, comme MySql, utilisent ce schéma où le même code source est livré sous un double système de licence.

Quoi qu'il en soit, la version commerciale et la version libre fonctionnent de manière identique.

Pourriez vous nous parler un peu plus de Ct ?

Si vous allez sur le site http://software.intel.com/en-us/data-parallel/ vous pourrez avoir plus d'informations sur ce sujet. Il y a un certain nombre de whitepapers sur le sujet, et certains ont des exemple de code source.

Le principe de base est assez simple. On utilise la surcharge d'opérateur pour déclarer un vecteur et être capable de dire a=b*c. On peut faire nombre de calculs avec ces vecteurs, mais on n'a pas le droit d'avoir un pointeur qui pointe sur le contenu de ces vecteurs. Cette restriction nous permet de savoir que seul Ct manipule le vecteur, et nous autorise donc à paralléliser le code de manière déterministe. Ces vecteurs peuvent être pleins ou creux, ce qui est souvent nécessaire pour les calculs mathématiques, mais cet aspect est totalement géré et encapsulé par notre bibliothèque.

Est-ce une technique semblable aux expression template, comme par exemple dans Blitz++ ?

Probablement. Par exemple, les calculs ne sont pas exécutés immédiatement, mais de manière paresseuse, de manière à agréger certains calculs. Ainsi, quand on fait a=b+c+d, on attend d'avoir l'ensemble de l'expression pour faire le calcul de manière efficace, sans exécuter boucle sur boucle sur boucle, et cette agrégation peut avoir lieu sur plusieurs instructions. Ça réduit les déplacements mémoire, et c'est très bon pour le parallélisme, car on peut avoir une vision d'ensemble, et ainsi mieux paralléliser. Et l'avantage, c'est que tout ça a lieu en restant du pur C++.