Des futex2 pour le noyau Linux afin d'accélérer les jeux : c'est en route... pour la quatrième fois !

Même si vous êtes un fan hardcore de Linux, il y a peu de chances que vous ayez entendu parler des futex, à moins que vous ne soyez développeurs dans cet écosystème. En effet, derrière ces futons futex se cache un mécanisme de synchronisation des threads et des processus utilisateurs, nécessaire à la programmation parallèle. Cependant, le code implémentant ces futex n’a pas subi de mise à jour majeure depuis 2008 (leur sortie datant de 2003), et pour cause : nul n’est assez aventureux pour modifier une interface fonctionnelle, largement répandue, et ainsi risquer le courroux de Linux Torvalds.

Cependant, les choses pourraient bien être amenées à évoluer. En effet, le système actuel consiste à partager une variable de 32 bits entre les différents threads ou processus à synchroniser, de sorte que certains puissent attendre et ainsi être mis en pause par l’OS tant que la variable ne prend pas une certaine valeur. Lorsque cette variable est modifiée, le processus écrivain envoie alors un second signal chargé de réveiller les autres processus en attente continuant ainsi leur exécution. Au fil du temps, ce mécanisme a révélé deux principales faiblesses : d’une part, la restriction à 32 bits rend la chose inappropriée pour certaines architectures embarquées, où 8 bits seraient parfois suffisants et moins énergivores, alors que le x86 actuel est tout à fait capable d’opérations atomiques sur 64 bits. D’autre part — et c’est là que réside, pour nous, l’intérêt d’une mise à jour —, il n’existe pas de mécanisme permettant de cascader les futex de manière efficace, id est, d’attendre des changements de valeur sur plusieurs adresses simultanément. Rajoutez également la problématique, certes mineure, du NUMA (le fait que les temps d’accès à un endroit fixe en mémoire puisse dépendre du cœur qui cherche à y accéder, particulièrement sur les Threadrippers, les EPYC ou les configurations multisockets), et vous obtenez un nombre de raisons suffisant pour vouloir dépoussiérer ces futex et les mettre à niveau en futex2, une nouvelle implémentation plus généraliste.

Finalement, le pingouin serait forcé de suivre quelque peu la fenêtre ?

Plus exactement, c’est au niveau de l’attente sur plusieurs objets que les regards se fixent actuellement. D’ailleurs, si vous avez suivi très attentivement le comptoir, vous avez pu voir que ces futex avaient déjà été mentionnés... dans le cadre du Ray Tracing sur Linux. Kamoulox ? Pas vraiment. L’explication au schmilblick se trouve dans Wine, la surcouche de compatibilité permettant de faire tourner des logiciels Windows sous l’OS manchot. Puisque Wine est une surcouche et non un émulateur, son rôle est seulement de traduire les appels système, c’est-à-dire les requêtes d’un logiciel au noyau — par exemple pour de l’affichage ou des accès aux fichiers... ou ces fameuses primitives de synchronisation. Sous le système de la Raymonde, la fonction WaitForMultipleObjects() est une pierre angulaire de la programmation parallèle, et permet de réveiller un processus lors du premier objet à être modifié parmi une liste ; une fonctionnalité particulièrement lente à émuler avec les futex actuels (en interne, dans ce cas, un système nommé esync est en fait préféré, à base de descripteurs de fichiers). En somme, si vous voulez des performances proches d’une exécution native avec Wine, il faudra passer tôt ou tard aux futex2, et donc passer un sérieux coup de balai sur l’ancienne interface.

C’est ainsi que nous retrouvons, au poste d’auteur de cette quatrième (!) demande de commentaires (une étape classique précédant la pull resquest, qui concerne, elle, l’intégration dans le code en tant que tel dans le tronc commun) concernant un code implémentant ces futex2, une entreprise prénommée Collabora. La firme, spécialisée dans le conseil et la programmation Linux est déjà passée dans nos colonnes grâce à son rôle dans l’optimisation du noyau Linux pour la compatibilité Windows — le tout sous un contrat avec Valve.

De bonnes nouvelles seraient donc à venir, même si la route est encore longue avant de voir ces futex2 dans le noyau Linux ; et, par la suite, supportés dans Wine. Pour autant, il y a fort à parier que les gains seraient conséquents, particulièrement dans les jeux gourmands niveau CPU, citons la série des Civilization à titre d’exemple... Mais pas seulement ! Si vous êtes aventureux, la dernière mouture de Proton supporte, depuis la 4.11, les noyaux non-officiellement patchés autorisant uniquement l'attente multiple sur les vieux futex (via FUTEX_WAIT_MULTIPLE, une proposition jamais acceptée ayant donné naissance à ces futex2), rendez-vous par ici pour des retours utilisateurs au niveau des performances. Restez connecté, le Comptoir vous tiendra au courant de l’évolution de la chose ! (Source : GamingOnLinux)