GNU Octave rencontre JupyterLite : le calcul devient possible partout, à tout moment

• Xeus-Octave rejoint désormais l’écosystème des noyaux JupyterLite, rendant possible l’exécution directe de code GNU Octave dans le navigateur
• GNU Octave est un langage open source de calcul scientifique compatible avec Matlab, et ce projet l’a porté vers un environnement WebAssembly (WASM)
• Pour résoudre les problèmes liés au code basé sur Fortran et aux dépendances BLAS/LAPACK, un toolchain personnalisé combinant LLVM Flang, Emscripten et Netlib LAPACK a été utilisé
• Comme LLVM ne prend pas encore en charge les symboles communs Fortran (Common Block), le problème a été provisoirement résolu par un patch temporaire, avec une prise en charge officielle prévue dans LLVM 22
• JupyterLite étend ainsi sa prise en charge de R à Octave, marquant une étape importante dans l’extension de l’écosystème de programmation scientifique basé sur le navigateur

---

Présentation de Xeus-Octave et du portage vers WebAssembly

• Xeus-Octave est un noyau Jupyter permettant d’exécuter du code GNU Octave dans le navigateur, empaqueté via emscripten-forge
  • GNU Octave est un langage gratuit et open source capable d’exécuter directement des scripts Matlab
  • Grâce à cette intégration, il peut désormais être utilisé immédiatement dans JupyterLite sans installation séparée
• À l’image de Xeus-R-Lite développé précédemment, le projet s’appuie sur un toolchain de compilation de code Fortran (LLVM Flang + Emscripten)
• Pour les bibliothèques de dépendances utilisées dans les calculs mathématiques d’Octave, Netlib LAPACK a été choisi à la place d’OpenBLAS, afin d’améliorer la compatibilité de build

Défis techniques du processus de build WebAssembly

• Des erreurs de build sont apparues dans LLVM en raison du problème de prise en charge des blocs communs Fortran (Common Symbol Block)
  • Le streamer Wasm de LLVM v20 n’implémente pas les symboles communs, ce qui a nécessité des modifications du code
  • Grâce à une collaboration entre l’équipe QuantStack et Serge Guelton, LLVM a reçu un patch temporaire pour les traiter comme des symboles faibles (weak symbols)
• La prise en charge officielle devrait être incluse dans la sortie de LLVM v22, et la version corrigée de LLVM est actuellement publiée pour Linux
• Octave lui-même a également été adapté à la cible WASM, avec notamment la désactivation des fonctions GUI et l’unification des signatures de fonctions Fortran

Intégration et démonstration de Xeus-Octave

• Une fois le build terminé, l’exécution de Xeus-Octave dans JupyterLite devient possible en ajoutant simplement une recette emscripten-forge
  • Une démonstration de tracé en temps réel est disponible dans le notebook de démo
• Xeus-Octave est construit sur Xeus, un framework de noyau Jupyter basé sur C++, ce qui permet d’exécuter et de visualiser des commandes Octave directement dans le navigateur

Prochaines étapes

• La prochaine étape consiste à intégrer l’écosystème de paquets Octave à conda-forge et emscripten-forge
  • L’utilitaire pkg d’Octave sera adapté à l’environnement navigateur afin de définir un processus d’installation dans un environnement conda
• Cela devrait encore renforcer l’environnement de programmation scientifique et mathématique basé sur le navigateur

Principaux contributeurs et contexte

• La développeuse principale Isabel Paredes, de QuantStack, avait auparavant travaillé sur le portage vers WebAssembly du langage R et du framework ROS
• Emscripten-forge est piloté par Thorsten Beier, avec la participation de plusieurs contributeurs, dont Anutosh Bhat et Martin Renou
• JupyterLite est maintenu principalement par Jeremy Tuloup, et Xeus autour de Johan Mabille
• Xeus-Octave a été développé par Giulio Girardi et Antoine Prouvost

[GN⁺]

Avis Hacker News

• Pour celles et ceux qui découvrent peut-être Octave, Octave est une quasi-réplique open source du logiciel propriétaire MATLAB voir plus en détail sur Wikipédia
  • Le terme « quasi-réplique » est un peu exagéré ; j’aime les logiciels open source, mais pour des travaux plus avancés, j’ai l’impression qu’Octave n’a pas encore complètement rattrapé MATLAB, voir les différences entre Octave et MATLAB
  • Comme le professeur Andrew Ng utilisait Octave dans ses premiers MOOC sur le machine learning, c’est utile si vous cherchez des supports pratiques et des exemples, playlist YouTube
  • Il y a 15 ans, en licence, j’ai utilisé Octave à la place de MATLAB dans un cours d’analyse numérique, et pour ce que nous faisions à l’époque, la compatibilité du langage était parfaitement au rendez-vous
  • Je ne suis pas utilisateur de MATLAB, mais j’ai bien le sentiment que recopier le langage ne suffit pas à recréer tout MATLAB ; MATLAB est une suite logicielle basée sur une GUI, avec beaucoup d’apps utilisables sans coder, ainsi qu’un support officiel de l’éditeur. L’open source avait autrefois une image un peu étrange ou peu fiable, mais ces dernières années ce domaine évolue vite
  • Scilab est un autre logiciel inspiré de MATLAB, mais il met davantage l’accent sur les fonctionnalités que sur la compatibilité, plus que ne le fait Octave
• Pour celles et ceux qui n’ont jamais entendu parler de JupyterLite, c’est comme le Jupyter Notebook/Lab classique, sauf que tout fonctionne entièrement dans le navigateur ; pas besoin de serveur ni de backend, tout s’exécute côté client
  • On pourrait penser que Python exécuté sur Web Assembly serait très lent
• Grâce à la même technologie (c’est-à-dire « xeus-stack » lien xeus-stack), il y a bien plus de langages/noyaux capables de tourner dans jupyterlite, par exemple c++, python, R, lua, javascript, etc. Pour tester, voir Try Jupyter Lab ou la documentation JupyterLite ; si vous voulez votre propre déploiement, vous pouvez utiliser le repo modèle xeus-lite-demo
• Octave est apprécié depuis longtemps par d’innombrables étudiants et a toujours servi d’alternative essentielle au niveau licence ; c’est un bon exemple de la contribution de GNU au progrès de l’humanité. Je le recommande vivement pour l’analyse numérique, et il est aussi facile à étendre avec GNU-Fortran ou GNU-C. Plusieurs extensions sont fournies, et c’est un DSL spécialisé dans le calcul numérique. Dans le même esprit, Scilab est aussi un package recommandable, mais moins extensible
• J’ai toujours le sentiment que, parmi les divers sujets évoqués par l’auteur, le véritable attrait du projet passe au second plan. J’aimerais que les diagrammes apparaissent davantage en amont, et que les fonctionnalités de la prochaine release ainsi que les problèmes rencontrés pendant leur développement soient davantage mises en avant
• J’ai toujours voulu transpiler GNU Octave vers d’autres langages. Octave pouvait déjà être embarqué comme bibliothèque C ; voir comment embarquer Octave en C/C++ et la documentation officielle sur les programmes autonomes. Il existe aussi un package OpenCL avec prise en charge de l’accélération GPU, voir le package OpenCL ; malheureusement, ce n’est pas une utilisation implicite du GPU, mais un modèle avec des types et fonctions GPU explicites, voir référence oclArray, ce qui signifie qu’on ne peut pas simplement exécuter du code Octave existant tel quel sur le GPU. Ce serait formidable si une accélération GPU basée sur OpenCL existait aussi dans le navigateur, mais WebCL n’a jamais vraiment dépassé le stade de l’implémentation, voir la documentation sur WebCL, Khronos WebCL ; aujourd’hui, WebCL est plutôt remplacé par WebGPU, voir comment utiliser WebCL dans Chrome, le guide de standardisation gpuweb et la documentation Chrome sur l’API web.
  • S’il faut vraiment dire ce que j’en pense, il est évident que si l’industrie s’obstine à préférer des approches propriétaires à des solutions ouvertes pourtant manifestes, c’est pour des raisons de profit ; il suffit de regarder l’histoire de nombreuses innovations comme la LED bleue. Si l’IA allège un peu la charge des développeurs, on pourra peut-être réexplorer ce type de voie plus clairement. En réalité, chaque innovation technique impose davantage de charge et une courbe d’apprentissage plus raide aux développeurs, alors même que la rémunération (notamment à l’embauche) stagne en pratique. Avec la généralisation du pair programming avec l’IA, je crains qu’on finisse par produire du code de moins bonne qualité et des codebases toujours plus complexes.
  • C’est pour cela que je suis attiré par les approches alternatives ; par exemple, des abstractions verboses en Python peuvent s’exprimer en une seule ligne dans Octave. Pour faire encore plus concis, il faudrait aller vers un langage d’assemblage fonctionnel de type LISP, mais cela reviendrait à renoncer à la commodité syntaxique des langages orientés tableaux.
  • Au fond, je pense que la voie la plus directe vers une IA de style J.A.R.V.I.S./Star Trek passe par des DSL comme Octave/MATLAB et par les outils de logique métier des années 1980, comme les tableurs, HyperCard, Microsoft Access ou FileMaker. J’imagine qu’un outil ouvert de type Octave avec accélération GPU augmenterait l’efficacité d’écriture logicielle et contribuerait aussi directement aux avancées de l’IA
  • Cette idée de méthodes alternatives, de DSL, tout ça me parle vraiment, voir cet article