URL: https://linuxfr.org/users/steckdenis/journaux/llvm-dans-un-gestionnaire-de-paquets
Title: LLVM dans un gestionnaire de paquets ?
Authors: steckdenis
Date: 2009年09月01日T16:44:52+02:00
Tags: llvm
Score: 24
Bonjour,
Aujourd'hui, comme je n'avais pas grand-chose à faire, j'ai testé llvm. Mon but n'est pas de voir s'il peut me compiler KDE, ffmpeg, GNOME ou autre, non, il y a de fortes chance qu'il n'y arrive pas.
En fait, j'ai une idée derrière la tête, idée qui va vous plaire, une bonne idée.
Le principe est simple : créer un gestionnaire de paquets, sauf que cette fois-ci, j'ai trouvé ce qui sera révolutionnaire dedans. En effet, les paquets seront petits, très petits. Ils seront rapides, très rapide également.
Comment y arriver ? C'est simple :
* Prendre un bon gros programme
* Le compiler avec clang, et sortir un fichier .ll
* Petite chaîne de compilation llvm (assembleur, optimisations, bytecode)
* Empaqueter **ça**, c'est à dire une représentation compacte (le bytecode), et surtout indépendante de l'architecture du processeur
* Du côté client, on récupère le paquet. Il contient les instructions pour la suite de la compilation (donc juste les libs à passer en paramètre -l à ld)
* Compiler le bytecode en code natif, adapté à la machine
Ça paraît trop beau pour être vrai, j'en pleure presque. Snif, fini les problèmes, on va être a des millions de kilomètres de ce que le proprio fait, de Windows, de Mac, etc. Voici la liste des avantages :
* Des mirroirs légers, très légers : tout n'est qu'en une seule architecture, et le bytecode est largement plus petit que le code compilé !
* Une éxécution super rapide chez le poste client, car optimisé aux petits oignons pour **son CPU**, quel qu'il soit (dernier Core i7, AMD Phenom, un PPC, un Cell, un ARM, etc)
* Sans boulot supplémentaire, on supporte toutes les architectures que LLVM supporte. De plus, les paramètres -march et -mcpu de lli (le programme qui transforme le source llvm en bytecode) sont très simples à utiliser, et j'ai avec succès généré une application pour PPC sur mon x86_64. Ainsi, les LiveCD qui doivent être précompilés sont générés très facilement et rapidement
Et voici les inconvénients qu'on pourrait penser que ce système a, mais qu'il n'a pas :
* Transformer le bytecode en assembleur est très rapide, l'assemblage aussi, et le linkage également. Le temps éventuellement perdu est de toute façon gagné en temps de téléchargement (mon fichier bytecode pour un tout petit fichier C est près de 10 fois plus petit que le binaire non-strippé, et 5x plus petit que quand il est strippé !)
* Le statut expérimental de llvm et clang : ils marchent bien, surtout llvm. Au pire, on utilise le front-end llvm-gcc, ce qui nous apporte également le C++
* Pas besoin de build-dependecies, tous les fichiers .h ont été parsés, et le code se trouve directement dans le fichier bytecode.
Côté inconvénients, je ne vois rien, pour le moment.
**Les tests**
Et oui, j'ai testé. Je suis partit d'un tout petit fichier C, le TP Plus ou Moins qu'on peut trouver [ici](http://www.siteduzero.com/tutoriel-3-13976-tp-plus-ou-moins-votre-premier-jeu.html) (je n'avais pas envie de trouver un fichier C moi-même, et celui là est plus "réel" qu'un Hello Word).
Ensuite, la compilation :
$ clang-cc test.c -emit-llvm -o - | llvm-as | opt -std-compile-opts> bytecode.bc
$ clang -o binaire_llvm test.c
$ ./binaire_llvm
Quel est le nombre ? 4
C'est moins !
[ ... donc ça marche ;-) ... ]
$ gcc -o binaire_gcc test.c
$ ./binaire_gcc
Quel est le nombre ? 3
C'est plus !
[ ... Lui aussi marche ... ]
$ strip --strip-all binaire_gcc # Soyons honnête sur la comparaison
$ strip --strip-all binaire_llvm
$ llc -o bytecode_asm.s bytecode_llvm.bc # Maintenant, compileation du bytecode
$ clang -o bytecode_bin bytecode_asm.s
$ ./bytecode_bin
Quel est le nombre ?
[ ... c'est bon aussi ... ]
$ ls -l
5104 sep 1 12:50 binaire_gcc
5112 sep 1 12:50 binaire_llvm
5128 sep 1 13:12 bytecode_bin
1116 sep 1 12:48 bytecode_llvm.bc
On voit donc que le bytecode est 5 fois plus petit que le résultat compilé et strippé.
Intéressant non ? Plus qu'à tester sur de gros programmes (ce que je vais faire).
PS: J'ai refait le même test avec un code C plus gros (le TP du pendu :P ), et le bytecode fait 3472 octets, alors que le fichier binaire le plus petit (celui de llvm) fait 5536 octets. Je vais tester avec encore plus gros.
PS 2: (décidément, linuxfr down me permet de bien tester) son TP du sokoban est remarquable : je compile chaque fichier .c en byte code, puis utilise llvm-ld pour générer **tout.bc**, puis lie le tout en un fichier **sokoban**. Tout.bc pèse à peine 5264 octets, alors que sokoban, strippé, pèse 11416 octets ! La version sokoban de gcc pèse 12904 octets. LLVM est le grand gagnant !
Encore un PS (j'ai eu le temps): marche à la perfection avec Cream, un navigateur web en GTK 2. Super et rapide : [Cream](http://cream-browser.sourceforge.net/). 63k pour le fichier bytecode, et 77k pour le binaire. Ca me paraît petit comme gain, peut-être que GTK met beaucoup de données qui ne sont pas des binaires dans son code.