Quand nous avons lancé le projet Symbolibre, il était clair d’entrée de jeu que la calculatrice devait être formelle. Mais cela laisse un (grand) nombre de possibilités en termes de choix de moteur : PARI/GP, Xcas, SageMath, SymPy, Scilab se font concurrence, et je suis loin de les citer tous.

Plusieurs critères contraignent bien sûr ce choix. Même si le Raspberry Pi Zero que nous avons choisi comme base est largement plus puissant que les calculatrices de lycée, faire le calcul formel en Python reste inenvisageable en termes de performance. Nous pouvons donc d’emblée éliminer SymPy. Nous n’utiliserons pas non plus les diverses interfaces graphiques car nos applications auront les leurs, il nous faut donc un programme accessible en ligne de commande, et dans l’idéal une bibliothèque. Première approche sur SageMath

Notre première approche, et clairement la plus ambitieuse, a été de tester SageMath. La raison était double. D’une part nous voulions tester les limites du Pi Zero, et comme SageMath est essentiellement un ensemble d’interfaces vers d’autres moteurs natifs, les performances du calcul pur ne sont pas tant un problème. D’autre part nous voulions que le projet Symbolibre participe au monde libre, en contribuant à compléter le module de simulation d’automates de SageMath par des machines de Turing (dans le même esprit que l’équipe du Librem 5 contribue à Wayland, si je peux me permettre la comparaison grandiose). Un de nos groupes a travaillé sur cette contribution pendant l’année.

SageMath est écrit en Python, mais il délègue souvent le calcul à d’autres programmes de calcul formel typiquement implémentés dans des langages natifs ; notamment PARI/GP (C) et Giac, le moteur de calcul derrière Xcas (C++). Notre intuition était de réduire le nombre d’interfaces externes que SageMath expose pour l’alléger en taille et en performance.

Mais bien sûr la théorie et la pratique se rejoignent bien mieux en théorie qu’en pratique. En principe, les modules de SageMath sont désactivés avant la configuration par un mécanisme simple : il suffit d’écrire disabled dans le fichier SAGE_ROOT/build/pkgs/<module>/type pour chaque module à désactiver. Cela indique une préférence qui sera ignorée lors de la construction des dépendances si le module désigné est une dépendance d’un autre module actif.

Et il y en a, des modules ! La compilation de SageMath sur mon ordinateur portable (4 coeurs, 8 Gio de RAM, disque SSD) prend autour de 2 heures. À titre indicatif, voici les modules qui ont occupé le plus de temps de compilation (pour une cible native – la cross-compilation ajoute quelques technicités mais pas de délais fondamentaux) :

C’est ensuite que le problème principal se pose : SageMath est un rassemblement modulaire d’outils variés, mais le code de SageLib n’est pas vraiment modulaire ; il y a par exemple plusieurs milliers d’appels à Singular répartis sur plus de 200 fichiers. Ce genre de dépendance ne peut pas être contourné, et en parcourant l’arbre on se retrouve très vite avec seulement deux modules désactivables : le langage r et son interface Python rpy2. Améliorer la modularité du code est l’un des objectifs futurs de SageMath, de pair avec la transition vers Python 3, mais ça va certainement prendre encore un moment.

Pour l’instant, impossible de désactiver les modules cruciaux, et les performances s’en ressentent largement : 1 minute 55 secondes et 175 Mio de RAM pour lancer le shell SageMath. La RAM n’est pas le problème critique car le Pi Zero dispose de 512 Mio. Cela impose d’avoir une seule instance de SageMath et de communiquer par IPC, ce qui n’est pas idéal mais toujours faisable. En revanche, le temps de démarrage est rédhibitoire. Même en lançant SageMath au boot, il faut compter au moins deux minutes avant de pouvoir faire des calculs.

Seconde approche avec Giac

Notre attention s’est ensuite tournée vers Giac, le moteur de calcul formel de Bernard Parisse, qui équipe la HP Prime. Il y a là plusieurs raisons. Giac fait d’abord partie de SageMath, ce qui nous a permis de le tester immédiatement puisqu’il était déjà compilé. C’est aussi depuis longtemps le moteur de calcul formel de la HP Prime, ce qui nous donne une garantie par l’expérience de ses fonctionnalités et performances.

Et de fait, Giac s’utilise comme une bibliothèque C++ avec une charge bien plus raisonnables pour notre Pi Zero : les programmes triviaux s’exécutent en moins d’une seconde et sur 15 Mio de RAM. Ce genre de coût au démarrage est déjà bien plus raisonnable, y compris si chaque application a sa propre instance de la bibliothèque.

Nous développons maintenant la calculatrice Symbolibre avec Giac. L’interface C++ simplifie la vie des applications natives, et le module giacpy permettra de faire du calcul formel en Python dans l’application de programmation. Dans cette histoire, il est intéressant de voir que les ordinateurs modernes nous cachent bien la complexité des logiciels. Le temps de chargement d’un shell SageMath par rapport à un shell Giac se joue à une poignée de secondes ; mais dès qu’on change de plateforme, la différence se creuse soudainement. D’où notre attention particulière sur le choix des logiciels, pour garder le système efficace.