La gestion des accès concurrents, c'est compliqué.

Palaiseau, le lundi 7 décembre 2020

Le candidat du jour pour le calendrier de l'avent aurait dû être #954270. J'ai d'ailleurs eu de la chance, en grattant un peu du côté du projet en amont, il se trouve que quelqu'un d'autre à eu le problème documenté dans le rapport de bug, et cela a même conduit à une correction. Le problème est donc corrigé dans une version de kmc qu'on n'avait pas obtenu, parce qu'il manquait un élément dans le scanneur de versions du système de suivi de paquet (configuré avec le fichier debian/watch) ; les nouvelles versions après kmc 2.3 prennent un v en plus de leur numéro.

Maintenant la mauvaise nouvelle : kmc 2.3 compile pour quasiment toutes les architectures supportées de près ou de loin par le projet Debian, mais kmc 3.1 ne fonctionne désormais, par construction, que sur les processeurs Intel supportant au moins le SSE2. Les violations d'architectures sont contraires à la charte du projet Debian : les programmes résultants vont se planter avec une erreur d'instruction illégale sur les machines un peu anciennes qui ne supportent pas les extensions. De plus, ces extensions sont spécifiques à l'architecture amd64, elles sont entièrement différentes pour les autres CPU, ce qui empêche leur construction. Par exemple :

• sur Aarch64 (ou ARM architecture 64-bits), les extensions vectorielles ont la désignation de Neon ;
• sur Risc-V, les extensions vectorielles ont pour désignation RVV, mais il me semble que c'est encore à l'état de projet.

Pour m'en sortir, il me reste SIMDe, un projet qui permet de rendre portable des intrinsics spécifiques à certaines extensions de CPU. Cette solution nécessite de reprendre une bonne partie du paquet, et je pense que je vais avoir besoin d'aide.

Sinon il reste l'option peu satisfaisante de s'en tenir à kmc 2.3, et d'empêcher de lancer plus de 24 fils d'exécution sans explicitement forcer le compte avec l'option -t du programme...

	Name	Last modified	Size
	Parent Directory		-