Openmc et snapdragon : enquête sur une incompatibilité inattendue
Comme beaucoup de personnes, j'ai récemment renouvelé mon ordinateur portable. Mon choix s'est porté sur une machine équipée d'un processeur Snapdragon, l'une de ces nouvelles générations de PC Windows ARM qui promettent autonomie, silence et performances en mobilité.
Sur le papier, tout semblait parfait.
Sauf qu'un détail m'avait échappé : je souhaitais également utiliser OpenMC, un code de calcul Monte Carlo largement utilisé pour les simulations de transport de particules en physique nucléaire.
Et c'est là que l'aventure a commencé.
Quand "Windows" ne veut pas dire "compatible"
Mon raisonnement initial était simple :
OpenMC fonctionne sous Windows ;
mon nouveau PC fonctionne sous Windows ;
donc OpenMC fonctionnera sous mon nouveau PC.
Logique.
Enfin... presque.
Ce que je n'avais pas suffisamment regardé n'était pas le système d'exploitation, mais l'architecture matérielle du processeur.
Mon ancien ordinateur utilisait un processeur AMD Ryzen classique basé sur l'architecture x86_64, celle qui équipe l'immense majorité des PC scientifiques depuis des années. C'est également l'architecture pour laquelle la majorité des packages scientifiques disponibles via Conda sont aujourd'hui compilés et testés.
Mon nouveau PC Snapdragon repose quant à lui sur une architecture ARM64.
Pour l'utilisateur moyen, cette distinction est quasiment invisible. Pour certains logiciels scientifiques, elle est fondamentale. Avec le recul, je me suis rendu compte que je confondais implicitement système d'exploitation et architecture matérielle. Pour beaucoup d'utilisateurs, "Windows" est une catégorie suffisante. En réalité, deux PC Windows peuvent avoir des niveaux de compatibilité très différents selon qu'ils reposent sur une architecture x86_64 ou ARM64.
Le début de l'effet domino
L'installation semblait pourtant simple. La documentation OpenMC recommande :
installer Conda ;
créer un environnement Python ;
installer OpenMC via conda-forge.
J'ai donc suivi les étapes.
Premier obstacle : le package OpenMC n'était pas disponible pour l'architecture linux-aarch64 utilisée dans mon environnement ARM.
Deuxième obstacle : certaines tentatives d'installation aboutissaient à des erreurs de type "Exec format error", symptôme classique d'un exécutable compilé pour une architecture différente.
Troisième obstacle : Docker, souvent utilisé comme solution de contournement, s'est révélé plus compliqué que prévu dans mon environnement Windows ARM.
Puis sont arrivés WSL, les problèmes de virtualisation, les composants Windows à activer, les incompatibilités de versions...
Bref, je me suis retrouvée à faire du dépannage système alors que mon objectif initial était simplement de lancer quelques simulations neutroniques.
Le processeur n'était pas mauvais
Je précise un point important. Le problème n'est pas que les processeurs Snapdragon sont mauvais.
Au contraire. Pour la bureautique, la navigation web, les réunions en ligne, le développement léger ou l'autonomie sur batterie, ces machines sont souvent excellentes.
Le problème est ailleurs.
L'écosystème scientifique reste aujourd'hui largement construit autour de l'architecture x86_64. De nombreux codes, bibliothèques et environnements de calcul ont été développés, testés et distribués pendant des années pour cette architecture.
L'arrivée des machines ARM dans le monde Windows est relativement récente, et tout l'écosystème n'a pas encore suivi.
La leçon : regarder jusqu'aux tripes de la machine
Cette expérience m'a rappelé une chose importante. Lorsque nous achetons un ordinateur destiné à un usage scientifique ou technique, nous regardons souvent :
la mémoire ;
la capacité du disque ;
l'autonomie et le poids ;
le prix ;
Mais rarement :
l'architecture du processeur ;
la disponibilité des bibliothèques scientifiques ;
la compatibilité des environnements de calcul ;
l'existence de packages précompilés.
Pourtant, ce sont parfois ces critères qui déterminent réellement si une machine sera utilisable pour notre activité.
Quelques vérifications avant achat
Si vous utilisez des outils scientifiques ou techniques, je vous recommande désormais de vérifier :
l'architecture du processeur (x86_64 ou ARM64) ;
l'existence de versions compatibles de vos logiciels principaux ;
la disponibilité des packages Conda ;
la compatibilité Docker éventuelle ;
les retours d'expérience de la communauté.
Quelques minutes de vérification peuvent éviter plusieurs jours de dépannage.
Épilogue
Finalement, OpenMC fonctionne aujourd'hui parfaitement sur mon ordinateur Linux x86_64. Mon ordinateur Snapdragon, lui, reste une excellente machine de mobilité.
La morale de l'histoire ?
Lorsqu'on achète un ordinateur pour faire de la science, les caractéristiques les plus importantes ne sont pas toujours celles affichées sur l'étiquette. Parfois, la réponse se cache beaucoup plus profondément : dans les tripes du processeur.