Vx : un langage pour programmer CPU, GPU et accélérateurs avec le type système
Sommaire
En bref
- Vx est un langage de programmation destiné aux systèmes hétérogènes (CPU, GPU, NPU, accélérateurs) qui intègre la localisation mémoire dans le système de types.
- Le compilateur rejette à la compilation les opérations transversales mémoire invalides (déréférence d'un pointeur GPU depuis le CPU) plutôt que de les laisser échouer à l'exécution.
- La déclaration du matériel cible (fichier machine) précède la compilation : le compilateur valide les placements de données contre les limites réelles du hardware, sans modèle de coût codé en dur.
- Le projet assume explicitement ne pas être adapté aux prototypes rapides ou à l'exploration d'architecture itérative.
Ce que dit la source
Vx répond au problème de la programmation hétérogène : écrire du code correct et performant pour plusieurs types de processeurs (CPU, GPU, NPU) suppose actuellement de jongler entre plusieurs langages, runtimes opaques, et découvrir trop tard (via un segfault ou un crash d'OOM à step 1200) que les données étaient mal placées en mémoire. Les langages courants traitent l'accélérateur comme une infrastructure sur laquelle on délègue via un runtime ; Vx le traite comme une sémantique du langage lui-même. Le compilateur capture, avant la compilation, la topologie du matériel réel (mémoire, bande passante, interconnexions) et valide que le placement et les transferts de données sont valides sur ce matériel spécifique.
- La localisation mémoire devient partie de la signature de type : un tenseur dans la mémoire haute bande passante d'une NPU a un type différent du même tenseur en DRAM hôte, et traverser la limite mémoire exige un appel explicite transfer(), lisible dans le source, plutôt que caché dans un profiler ou le runtime
- Le compilateur valide quatre classes de bugs avant l'exécution : déréférence de pointeur GPU depuis l'hôte, dépassement de capacité mémoire pour un placement donné, lecture d'un buffer dont le transfert asynchrone n'est pas visible, et utilisation après déplacement de propriété (via des types linéaires)
- La machine cible est décrite dans un fichier séparé (avec des chiffres exacts en SI/IEC, pas des floats), et le compilateur échoue à la compilation si une donnée ne tient pas dans la mémoire prévue, plutôt que de supposer une architecture abstraite de 1970
- Le compilateur parallélise le frontend en flat arrays (identifiants 256-bit par symbole) sans moteur de requête ni contention verrous ; l'émission MLIR doit être identique en mono ou multithreads, assertion vérifiée dans la suite de tests
- Vx cible x86-64, ARM64, NVIDIA GPU, Apple AMX/ANE via plugins MLIR ; les éditeurs de compilateur sont intégrés comme des passe-plugins plutôt que des patches du cœur
Dans les commentaires
Débat mitigé, dominé par la curiosité et quelques doutes pratiques. L'intérêt technique est manifeste chez certains (démarche d'admettre les limites d'utilité, comparaison avec des DSL et langages proches), mais l'absence d'avantage évident sur Mojo, les questions ouvertes sur la complétude du support matériel (Meteor Lake, support réel au-delà des feuilles de spec) et une inquiétude minoritaire sur le positionnement générique réduisent l'enthousiasme.
- Plusieurs commentateurs questionnent la justification de créer un nouveau langage quand Mojo, Zig ou Rust existent, et demandent ce que Vx apporte au-delà (notamment comparé à Mojo pour accélérateurs)
- L'affirmation "Every Chip" est critiquée comme hyperbole : le support couvre CPU mainstream et GPU/accélérateurs connus, mais des architectures réelles hétérogènes complexes (par ex. Intel Meteor Lake avec CPU, Arc GPU et NPU intégré) restent en question ouverte
- Quelques commentateurs soulèvent que la description du langage elle-même semble générée ou sur-polissée ("if you can't even be bothered to write it yourself"), malgré une reconnaissance de la clarté de sa distinction d'usage
- Manque d'évidences de performance réelles : un commentateur demande si les binaires générés surpassent ISPC, mais aucun benchmark n'est cité
Alternatives citées : Mojo (pour accélérateurs, langage compilé), ISPC (SIMD CPU), Rust (avec ecosystème GPU émergent), PyTorch (runtimes pour hétérogénéité).
Notre lecture
Vx esquisse une direction techniquement solide : codifier la sémantique de la mémoire hétérogène dans le système de types plutôt que dans le runtime est une réponse honnête aux limites des abstractions de 1970 face au silicium moderne. L'autocritique explicite ("pas le bon outil pour l'exploration d'architecture") renforce la crédibilité. Mais trois réserves majeures empêchent de conclure à un changement de paradigme : (1) l'avantage pratique sur Mojo reste flou, et Mojo a déjà un écosystème et un backing ; (2) le support matériel est attesté sur des processeurs flagship bien connus, mais le test sur des architectures réelles hétérogènes intégrées (comme les CPU+GPU+NPU consommateur) manque ; (3) pas de preuve de compétitivité en performance. À surveiller pour les équipes qui doivent compiler une logique identique sur 3+ architectures très différentes (clusters multi-GPU, inférence edge), mais probablement trop immature et trop petit écosystème aujourd'hui pour être un remplaçant CUDA/PyTorch. Valeur pédagogique et directionnelle élevée, risque d'adoption bas.