Stephen Jones est ingénieur logiciel principal chez SpaceX et ancien architecte CUDA à NVIDIA
Pour cet article, Stephen Jones donne son point de vue sur des aspects de la technologie qui intéressent beaucoup Redimensionnerles utilisateurs. En tant que contributeur majeur à CUDA, de nombreux utilisateurs de Rescale ont effectué des analyses en tirant parti de ses travaux sur la technologie GPU, et d'autres ont créé leurs propres codes à l'aide des bibliothèques CUDA. D'un point de vue personnel, étant revenu travailler avec des logiciels d'ingénierie après plusieurs années en génie logiciel général, j'ai décidé qu'il serait intéressant de poser à Stephen quelques questions sur les avancées technologiques de ces dernières années et sur la manière dont il envisage les tendances futures.

Pour lancer le bal, j'ai commencé par l'évolution du calcul parallèle :
Stephen Jones : Il y a environ 10 ans, toute informatique est devenue informatique parallèle. Les processeurs ont cessé de devenir individuellement plus rapides et La loi de Moore s'est poursuivi en ajoutant davantage de processeurs (les processeurs grand public ont tous au moins 4 cœurs, et les serveurs peuvent en avoir 16 ou plus – tout programme non parallèle n'utilise donc pas plus de 25 % de la machine). Je pense qu'un effet clé vient du fait que la programmation parallèle est différente de la programmation série de plusieurs manières fondamentales, ce qui la rend beaucoup plus difficile. Je m'attends à ce qu'à l'avenir (sic) la programmation parallèle soit réalisée par des outils (compilateurs, bibliothèques, langages de programmation automatisés) et non par des humains, et que cela marquera un changement radical dans la manière dont toute programmation est abordée.

Chez Rescale, nous avons une clientèle diversifiée. Beaucoup de nos partenaires industriels ou académie travailler avec des clusters de calcul haute performance (HPC) sur site. J'ai demandé à Stephen ce que HPC signifiait pour lui :
Stephen Jones : Je vois cela comme un terme général couvrant la pointe de la technologie informatique. L’univers est complexe, et nous sommes très loin de pouvoir le modéliser précisément ; par conséquent, nous pouvons toujours trouver des tâches pour des ordinateurs de plus en plus grands. Ce qui se passe, c'est qu'à mesure que la technologie progresse dans ce qu'un ordinateur peut faire, elle révèle de nouveaux problèmes que nous ne pouvions pas résoudre auparavant. HPC existera toujours et sera toujours un marché de niche. D'un autre côté, il ne sera pas de sitôt supplanté par des ordinateurs de bureau « suffisamment puissants » en raison de la complexité de l'univers susmentionnée. Il s’agit en effet d’un incubateur technologique très intéressant, tant au niveau matériel que logiciel.

Ingénieurs et scientifiques dans le monde entier utilisent le Redimensionner la plateforme pour compléter et étendre les ressources que leur organisation peut fournir. J'ai demandé à Stephen comment il envisageait l'utilisation des technologies cloud dans le HPC :

Stephen Jones : C'est l'un des grands catalyseurs des 10 dernières années. Le cloud d'Amazon, en particulier, change la donne et (à mon avis) l'une des choses les plus étonnantes du monde informatique. Il est désormais acceptable, lorsque vous essayez de financer votre startup, de dire « mon infrastructure est AWS, nous ne dépensons donc pas d'argent en matériel ». Ce qui est particulièrement intéressant, c'est qu'il permet le HPC ainsi que l'infrastructure informatique de base, de sorte que l'on commence à voir des startups faire de nouvelles choses avec l'informatique à grande échelle qui étaient auparavant hors de portée de ces petits acteurs. En effet, nous pouvons avoir 100 fois plus de personnes développant pour le HPC que jamais auparavant, et cela doit produire de nouvelles applications intéressantes.

Dans mon rôle d'ingénieur d'application ici chez Rescale, j'ai récemment construit et installé des packages open source qui tirent parti de CUDA et NVIDIA matériel sur la plateforme Rescale. J'ai interrogé Stephen sur son expérience personnelle de travail sur CUDA :

Stephen Jones : Il est évidemment difficile pour moi d'être objectif à ce sujet, car j'ai été l'architecte de CUDA pendant plusieurs années. Une chose que l’on voit en parallèle avec les langages de programmation HPC est une approche très « du plus petit dénominateur commun » : personne ne veut investir dans un code très complexe qui ne fonctionnera que sur une seule machine et l’empêchera d’en acheter une autre. Le résultat est le problème « conçu par un comité », associé à un résultat « maître de rien ». CUDA est intéressant car il va volontairement à l'autre extrême : il ne fonctionne que sur un seul type de machine mais est donc capable de repousser les limites car il ne se limite pas à vouloir plaire à tout le monde. Cela se porte bien en ce moment car le GPU NVIDIA est largement répandu dans le HPC ; le résultat est que CUDA étudie d'abord de nombreux nouveaux aspects du modèle de programmation. De nombreuses fonctionnalités de CUDA se retrouvent dans d'autres langages sous une forme ou une autre (OpenCL, OpenMP, Renderscript) parce qu'elles s'avèrent utiles. Ce qui permet vraiment à CUDA, c'est que les concepteurs de langage peuvent obtenir le support matériel des concepteurs de puces (car ils sont dans la même entreprise), et ainsi repousser de nouvelles limites qui ne sont tout simplement pas ouvertes aux concepteurs de langage indépendants. Il y a beaucoup de choses innovantes dans CUDA, et encore plus à venir, grâce à cette association étroite.

Une chose que j'ai remarquée avec les nouveaux codes est l'amélioration de la productivité que les chercheurs obtiennent grâce à l'utilisation judicieuse de Python dans les projets scientifiques. J'ai demandé à Stephen quelle combinaison d'outils (pouvant inclure des langages) il recommanderait aux scientifiques ou aux ingénieurs espérant atteindre une productivité maximale afin qu'ils puissent effectuer leur travail réel :

Stephen Jones : Je crois qu'il faut toujours écrire des logiciels dans le langage le plus haut niveau et avec le moins de lignes possible. Même dans un code haute performance, seulement 10 % des lignes de code consomment 90 % des cycles. Si ces 10 % implémentent un algorithme bien connu (algèbre linéaire, transformée de Fourier, etc.), vous pouvez souvent utiliser une implémentation standard que quelqu'un d'autre a peaufinée.

Cela signifie que vous pouvez souvent vous permettre de faire *tout* dans un langage de haut niveau, tel que SciPy ou NumPy, et d'utiliser les bibliothèques sous-jacentes pour faire le gros du travail. Je dirais que vous seriez fou de ne pas le faire – cela conduit à un code plus maintenable, avec moins de lignes et moins de bugs, et surtout pour l'industrie : vous pouvez beaucoup plus facilement embaucher des personnes qui connaissent Python, que des personnes qui connaissent les arcanes de bas niveau. langages parallèles de niveau. Votre base de code a alors une bien meilleure longévité.

Là où les choses deviennent intéressantes, c'est lorsque les opérations gourmandes en CPU ne sont pas des algorithmes standards. Vous devez ensuite les implémenter vous-même, et encore une fois, je recommanderais le langage du plus haut niveau avec lequel vous pouvez vous en sortir. Cela implique de réfléchir à l'équilibre entre maintenabilité et performances : vous souhaiterez peut-être accepter de ne pas atteindre des performances optimales en échange de l'écriture d'un code plus maintenable et évolutif. NumPy, par exemple, me permet de faire de la parallélisation liée à CUDA (sic) dans un framework Python, avec une accélération très respectable pour très peu d'effort.

Chez SpaceX, je vise environ 75 % des performances maximales, car les 25 % restants rendront le code beaucoup plus difficile à développer et – surtout – beaucoup moins pérenne. Cela ne vaut tout simplement pas ces 25 % supplémentaires si je dois le recoder pour de nouvelles architectures toutes les quelques années. Certes, nous n'utilisons pas Python pour notre code de performance, mais nous l'utilisons pour une foule de choses qui seraient bien trop compliquées en C++.
En ce qui concerne les outils de développement, je cherche toujours quel langage et/ou plate-forme dispose des meilleurs outils de diagnostic. Les débogueurs, les profileurs et les analyses peuvent me faire gagner littéralement 50 % de mon temps de développement. Donc, une combinaison de cela et d’un langage de haut niveau est la première chose à laquelle je m’adresse. Comme vous pouvez le constater, je suis fan de Python, mais cela dépendra vraiment du cas d'utilisation. Matlab dispose également d'excellents outils, bien qu'ils soient livrés avec un verrouillage du framework.

Un mot sur les autres types de langage. Haskell, en particulier, suscite beaucoup d’intérêt ces jours-ci. En tant que langage de programmation fonctionnel, il se parallélise (sic) beaucoup plus naturellement qu'un langage impératif et cela semble intéressant. Le monde universitaire s'y intéresse beaucoup, mais je pense que le vivier de talents est trop restreint pour que je puisse l'utiliser dans l'industrie : embaucher de bonnes personnes est déjà assez difficile pour Python, encore moins pour C.
J'ai ensuite demandé ce qu'il voyait comme l'avenir du FORTRAN, un langage encore fréquemment utilisé dans les analyses techniques.

Stephen Jones : Cela disparaîtra à mesure que les ordinateurs deviendront moins capables de l'exécuter. Il n’est pas intrinsèquement parallèle, vous devez donc l’entourer d’un cadre tel que MPI. Je pense que les ordinateurs plus gros (exascale) seront de plus en plus difficiles à programmer avec MPI, et que cela marquera la fin du FORTRAN. Contrairement au C, FORTRAN n'est pas présent dans la programmation de bas niveau, il disparaîtra donc à mesure que les paquets poussiéreux seront enfin réécrits.
Un dernier mot, en regardant dans ma boule de cristal : je pense que l'avenir de la programmation réside dans l'écriture de logiciels. C'est-à-dire que j'écrirai un programme qui écrira les programmes pour moi. Les compilateurs font déjà beaucoup pour nous ; les frameworks de haut niveau comme Ruby gèrent toutes sortes de complexités pour la programmation Web ; l'auto-parallélisation (sic) est un mot à la mode en ce moment (même si ce n'est pas encore là). Les ordinateurs vont devenir de plus en plus difficiles à programmer, et nous ne pourrons le faire qu’avec l’aide d’autres ordinateurs…
Passant au sujet du travail avec ce que j'aime appeler de « vrais ingénieurs » (divulgation, mon premier travail d'ingénieur était dans un chantier de réparation navale), Stephen s'est montré tout aussi ouvert.

Stephen Jones : C'est vraiment intéressant de travailler en tant que développeur de logiciels dans un environnement d'ingénierie mécanique pure. Un ordinateur est un outil comme n’importe quel équipement de laboratoire, et personne ne pourrait imaginer faire de l’ingénierie sans un ordinateur ; cependant, les non-ingénieurs en logiciel de toutes les sociétés d'ingénierie que j'ai vues les utilisent comme des outils (c'est-à-dire d'une manière assez peu sophistiquée en matière de logiciel).

Enfin, le génie logiciel et ses relations avec l'ingénierie est un sujet qui m'intéresse beaucoup. J'ai demandé à Stephen son avis à ce sujet.

Stephen Jones : C'est un autre élément important. Je le vis tous les jours chez SpaceX, en essayant de combler cet écart. J'ai assisté il y a quelques mois à une conférence sur la simulation technique et j'ai rencontré une douzaine de personnes qui avaient toutes des histoires étonnamment similaires à raconter (tout comme moi) : le manque de compréhension des logiciels est répandu et constitue un véritable handicap pour les ingénieurs. Nous devons former les ingénieurs bien mieux que nous dans l'utilisation et la programmation des ordinateurs – ce n'est pas comme une perceuse ou une scie que l'on peut simplement apprendre à utiliser facilement sur le terrain. Les entreprises qui consacrent du temps à dispenser cette formation bénéficient d’avantages évidents en matière d’innovation technique et de productivité. Cela vaut d’ailleurs pour toutes les sciences, pas seulement pour l’ingénierie. En travaillant dans le domaine du HPC pour NVIDIA, j'ai rencontré d'innombrables physiciens, chimistes et biologistes brillants qui avaient du mal à réaliser leurs travaux scientifiques de pointe avec ces supercalculateurs extrêmement complexes. Les plus performants étaient ceux qui avaient activement appris à programmer, plutôt que ceux qui s'en sortaient simplement dans la confusion (sic). Dans de nombreux cas, le physicien le moins expérimenté fait un meilleur travail car il peut utiliser l’ordinateur plus efficacement. Il existe indéniablement une attitude – tant dans les sciences que dans l’ingénierie – selon laquelle les logiciels sont « moins purs », mais je soupçonne que cela se révélera générationnel, car les gens grandissent désormais avec des ordinateurs à portée de main depuis leur enfance.

Un grand merci à Stephen pour son point de vue unique. À Redimensionner, nous poursuivrons nos efforts pour permettre aux scientifiques et aux ingénieurs d’atteindre leurs objectifs en leur fournissant les ressources informatiques évolutives dont ils ont besoin.