« Les logiciels de CAO sont mono-thread » : pourquoi ce n'est pas si simple

J'entends dire ici ou là que les logiciels de CAO actuels sont nuls parce qu'ils ne savent pas tirer parti des processeurs modernes : « ils sont mono-thread ». À l'appui, une capture du gestionnaire des tâches pendant une reconstruction : un cœur à 100 %, les autres qui se tournent les pouces.

L'observation est souvent juste. La conclusion, beaucoup moins. Elle oublie trois réalités : certaines opérations sont séquentielles par nature, paralléliser ne rapporte pas toujours ce qu'on espère, et ces logiciels traînent derrière eux des dizaines d'années de code.

Je ne vais pas parler du code des autres, que je ne connais pas de l'intérieur. Je vais parler du nôtre : nous écrivons chez Wiip le noyau géométrique de Cadoscopia 3D, un logiciel gratuit. On y a parallélisé certaines choses. D'autres restent séquentielles, et ce n'est pas par manque d'envie.

1. Certaines opérations sont séquentielles par nature

Une pièce dans un modeleur paramétrique, c'est un arbre de construction : une liste de fonctions qui s'appliquent l'une après l'autre.

Esquisse 1 ──► Extrusion ──► Perçage ──► Chanfrein sur l'arête du perçage
                   │
Esquisse 2 ────────┘ (dessinée sur une face de l'extrusion)

Le perçage s'appuie sur une face créée par l'extrusion. Le chanfrein s'appuie sur une arête créée par le perçage. On ne perce pas une face qui n'existe pas encore, et on ne chanfreine pas une arête qui n'a pas encore été calculée. Avoir 24 cœurs n'y change rien : chaque étape attend le résultat de la précédente.

Dans notre noyau, le rejeu de l'arbre suit l'ordre de ce graphe de dépendances, une fonction après l'autre. Après chaque fonction, il faut en plus retrouver les arêtes et les faces que les fonctions suivantes désignent : la face sur laquelle on a posé l'esquisse 2 a peut-être été découpée en deux par l'opération précédente. Ce suivi se fait à partir de l'historique de l'opération qui vient de s'exécuter. Il ne peut donc pas commencer avant elle.

Ce qu'on sait faire, en revanche, c'est ne pas tout rejouer : quand on modifie une fonction, celles qui la précèdent et qui n'ont pas changé sont réutilisées telles quelles. C'est une économie bien plus sûre que le parallélisme sur ce genre de chaîne.

Autre opération séquentielle, cette fois par choix : la publication d'une modification. Quand vous changez un paramètre, le nouveau modèle est calculé en arrière-plan, sans figer la fenêtre. Mais il n'est publié qu'une fois entièrement calculé, d'un seul geste : soit vous voyez l'ancien modèle, soit le nouveau, jamais un mélange des deux. Une seule modification à la fois devient la version courante. C'est ce qui permet d'annuler proprement et de ne jamais fabriquer une pièce à partir d'un résultat périmé.

2. Paralléliser n'est pas si simple

Là où les opérations sont indépendantes, on peut répartir le travail sur plusieurs cœurs. Le maillage des faces d'une pièce, par exemple : pour l'afficher, on découpe chaque face en triangles, et une face peut se mailler sans attendre ses voisines. C'est ce que nous avons fait pour l'ouverture des fichiers STEP.

Voici ce que ça a rapporté, mesuré sur 32 fichiers STEP, trois passes chacun, sur un poste qui dispose de 24 processeurs logiques :

• le maillage seul est devenu 19,3 % plus rapide avec quatre travailleurs ;
• le temps total d'ouverture, lui, n'a gagné que 8,5 % grâce au parallélisme ;
• sur certaines pièces, le gain est nul, voire légèrement négatif.

Quatre cœurs pour 19 % de gain sur l'étape concernée : on est très loin d'un « quatre fois plus vite ». Pourquoi ?

Toutes les étapes ne se parallélisent pas. Lire le fichier, résoudre les références entre entités, construire et valider le modèle : tout cela reste devant le maillage. Le gain sur une étape se dilue dans le temps total.

Les faces ne sont pas si indépendantes. Deux faces voisines partagent une arête, et leurs maillages doivent se raccorder exactement le long de cette arête, sans trou. Nous échantillonnons donc les arêtes une fois, avant les faces. Chaque face lit ces points communs et n'écrit que dans ses propres résultats : pas de verrou pendant le calcul, mais une étape séquentielle avant.

L'ordre des résultats compte. Si on assemble les triangles dans l'ordre où les travailleurs finissent, deux ouvertures du même fichier donnent deux maillages différents. Pour garder un résultat identique d'une fois sur l'autre, on attend que tous les travailleurs aient fini, puis on fusionne dans l'ordre des faces de la pièce. Ce rendez-vous coûte du temps. Nous avons vérifié que les maillages restaient identiques, au triangle près, à ceux du code séquentiel.

Le reste du programme doit suivre. Les messages de diagnostic, les mesures, l'annulation par l'utilisateur : tout ce qui était naturellement ordonné dans le code séquentiel doit être repensé. Les diagnostics sont rejoués dans l'ordre des faces, et une annulation attend la fin effective de tous les travailleurs avant de rendre la main.

Paralléliser n'est pas toujours la meilleure première idée. Juste avant ce travail, nous avions mesuré l'ouverture étape par étape. Le profil montrait surtout du travail évitable dans la validation du modèle et dans l'évaluation des surfaces NURBS. En corrigeant ces deux points, sans un seul thread de plus, le temps total d'ouverture a baissé de 30 %. Plus que ce que le parallélisme a rapporté ensuite.

3. Des dizaines d'années d'historique

Notre noyau est jeune, et nous l'avons écrit en sachant que certaines parties seraient parallélisées. Malgré cela, paralléliser le maillage a demandé de changer la façon dont les résultats sont stockés, d'écrire la fusion déterministe, de borner la mémoire, de traiter l'annulation et de tout remesurer.

Les grands logiciels de CAO sont nés à une époque où un poste n'avait qu'un processeur, et leur code a été enrichi depuis par des générations de développeurs. Un code écrit pour un seul fil d'exécution suppose, sans le dire, que personne d'autre ne touche à ses données pendant qu'il travaille : caches partagés, structures modifiées en place, effets de bord dont plus personne ne connaît l'étendue. Introduire du parallélisme dans un tel ensemble, c'est s'exposer à des bogues qui n'apparaissent qu'une fois sur mille, sur la machine d'un utilisateur, et qu'on ne reproduit pas. Face à un gain de quelques pour cent, le risque de casser des fichiers qui s'ouvrent correctement depuis des années pèse lourd.

Le parallélisme a donc plus de chances d'arriver par morceaux, là où le travail s'y prête — le maillage, l'affichage, les calculs indépendants — que dans la reconstruction de l'arbre de fonctions, qui reste séquentielle pour les raisons vues plus haut.

En résumé

Un cœur à 100 % pendant une reconstruction ne prouve pas l'incompétence de l'éditeur. Il montre souvent une chaîne de dépendances que personne ne peut casser. Là où le travail est vraiment indépendant, le parallélisme aide, mais modestement, et au prix d'un vrai travail de conception. Et le meilleur gain vient parfois d'un simple profilage du code séquentiel.

Si vous développez un complément pour un logiciel de CAO et que ses performances vous posent problème, commencez par mesurer. C'est ce que nous faisons, et c'est un des services que nous proposons.