Développeur : LLVM 2.2 : Un concurrent pour GCC ?
Posté par patrick_g (page perso, ). Modéré le 18 février 2008.
LLVM n'est pourtant pas tout à fait comparable au compilateur GCC. En effet GCC est un projet complet et monolithique car Richard Stallman a choisi explicitement de ne pas le rendre modulaire afin de ne pas permettre a des programmes propriétaires de s'interfacer avec lui.
LLVM au contraire est placé sous licence BSD et a choisi une conception très modulaire afin d'être réutilisé au maximum par tous. Il se limite à des fonctions d'optimisation et de génération de binaire ; il ne peut analyser lui-même le code source des programmes à compiler (c'est le projet Clang qui est prévu pour ça).
Il sera intéressant de voir ce qui va se passer sur le long terme dans l'écosystème du libre et si LLVM va être capable d'attirer des développeurs utilisant actuellement GCC.
![[en]](../images/en.png)
Les nouveautés de LLVM 2.2 (634 hits)-
Tutoriels pour LLVM (530 hits)
-
Clang (358 hits)
> Lire la dépêche (173 commentaires, moyenne: 2,8).
Vous avez demandé le commentaire #906198.
Run by 
Cette page a été générée par Templeet en 0.0856s (dont 0.0089 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Performances ?
Ca à l'air tout joli comme architecture.
Mais au niveau des performances ça donne quoi ? Parce que bon c'est quand même un des buts premiers des compilateurs et GCC n'est pas forcément non plus le plus rapide du monde. Si c'est pour avoir voir un compilateur mieux architecturé mais encore plus lent...
[^]Re: Performances ?
Euh, tu parles de la vitesse du compilateur ou de la vitesse du code produit ?
[^]Re: Performances ?
Au niveau du code générer je crois qu'il y a encore pas mal de boulot à faire pour avoir du code plus performant que gcc.
[^]Re: Performances ?
LLVM 2.0+gcc 4.2 est 20% plus rapide que gcc 4.2 seul :
http://lucille.atso-net.jp/blog/?p=294
L'architecture de LLVM permet des optimisations que gcc n'est âs capable de produire.
Je serai intéressé par des benchmarks frais ;-)
[^]Re: Performances ?
Je n'arrive pas à lire le lien mais je serais très étonné que le résultat résumé soit réaliste et significatif. Effectivement, sur architecture Intel (au hasard :-) em64t mes propres benchmarks et plusieurs autres que j'ai pu trouver sur le net montrent que gcc est environ 10% moins rapide que le compilateur intel (ifort/icc) qui fait tout de même figure de référence sur cette architecture. Alors 20% de mieux que gcc... Je suis un peu dubitatif.
PMA
[^]Re: Performances ?
Ah oui, l'url semble HS maintenant. Une copie avec Google Cache :
gcc 4.0.1(apple) (latest gcc from Xcode Tools)
$ gcc -o bmt -O3 -DSMALL himenoBMTxps.c
$ ./bmt
...
Gosa : 1.167853e-04
MFLOPS measured : 544.017453 cpu : 56.726971
Score based on Pentium III 600MHz : 6.634359
gcc 4.2
$ gcc-4.2 -o bmt -O3 -DSMALL himenoBMTxps.c
$ ./bmt
...
Gosa : 1.753087e-05
MFLOPS measured : 953.891485 cpu : 54.242544
Score based on Pentium III 600MHz : 11.632823
Emit LLVM code with llvm-gcc-4-2.0, then exec it with LLVM JIT.
$ ~/src/llvm-gcc4-2.0-x86-darwin8/bin/llvm-gcc -emit-llvm \
-O3 -DSMALL -c himenoBMTxps.c
$ ~/src/llvm-2.0/Release/bin/lli himenoBMTxps.o
Gosa : 2.229028e-05
MFLOPS measured : 1147.841139 cpu : 42.767418
Score based on Pentium III 600MHz : 13.998063
The result tells me that LLVM JIT does good job(20% faster than natively geneted code by gcc-4.2),
altough we must pay attention that “Gosa”(which means computational error in Japanese) is a bit higher than gcc-4.2’s result.
gcc-4.0.1 is fairly bad… I don’t know why…
[^]Re: Performances ?
Ho mais tu triches, ton code générer par llvm n'est pas exécuter nativement comme pour gcc, mais dans une VM qui fait des optimisations JIT.
Et je pari que comme par hasard, le code est friand d'optimisation JIT...
[^]Re: Performances ?
Hum, en quoi est-ce de la "triche" ? Le but est d'aller le plus vite possible, qu'importe les moyens. gcc n'a pas de JIT, il va moins vite. LLVM utilise du JIT, il va plus vite. Bah vive le JIT non ?
[^]Re: Performances ?
Ouai enfin le benchmark, c'est quoi? Un seul test, plusieurs?
Si c'était un truc connu genre SpecInt, ce serait peut-être plus crédible, la évaluer un compilateur sur un obscur benchmark, c'est peut-être un peu leger..
[^]Re: Performances ?
euh non, le but c'est de pouvoir optimiser de façon le plus générique possible, entre une optimisation qui permet de gagner 10% du temps sur un cas particulier, mais qui donne du code 20% moins rapide 99% du temps, et une qui donne du code 5% plus rapide 100% du temps,
devine qui on va choisir.
Bref, un benchmark ça veut RIEN dire, encore moins quand y a rien de précisé.
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Performances ?
Que le programme soit choisi pour mettre en valeur les qualités de llvm, c'est de bonne guerre. En revanche, l'argument « ho et la, machine virtuelle, tricher... », je ne suis pas d'accord. Pour l'utilisateur, entre taper ./toto et ./titi, c'est du pareil au même. Ensuite, que toto soit une machine virtuelle qui interprete un programme bytecode ou un script python ou un binaire, c'est du pareil au même. Donc si avec des machines virtuelles, on peut toujours avoir de meilleur performances, pourquoi gcc ne s'y met pas ?
[^]Re: Performances ?
Au niveau du code générer je crois qu'il y a encore pas mal de boulot à faire pour avoir du code plus performant que gcc.
Ah bon? Ce n'est pourtant pas particulièrement difficile. Des compilos qui font du code plus efficace que gcc ça ne manque pas.
Sur cible ARM, gcc se prend une grande claque par rapport à RVCT ...
[^]Re: Performances ?
Après, il faut voir que gcc est multi-plateforme. Il y a surement des plateformes où le générateur final est à la traine et donc gcc se fait exploser sur les benchs.
Ce qui est intéressant, c'est que sur une plate-forme a priori bien maintenue, intel, gcc n'est pas si à la traine que ça. Ca veut dire que globalement, il tient la route.
phil.freehackers.org
[^]Re: Performances ?
Je ne dis pas le contraire.
Mais la plateforme ARM n'est pas ce que l'on peut appeler une plateforme marginale. Je n'ai pas de chiffre mais à vue de nez je dirais qu'il y a plus de code dans le monde qui tourne sur du ARM que sur du x86 ...
[^]Re: Performances ?
"Je n'ai pas de chiffre mais à vue de nez je dirais qu'il y a plus de code dans le monde qui tourne sur du ARM que sur du x86 ... "
Cette phrase m'ayant surpris, je suis allé chez l'ami Wikipedia ([[Processeur ARM]]) et j'y ai vu ceci :
"L'architecture ARM est très répandue notamment dans la téléphonie mobile. De nombreux systèmes sont portés sur cette architecture. À savoir Linux avec Android, Mac OS X avec l'iPhone, et Windows Mobile."
Il y a donc plus de téléphones mobiles que d'ordinateurs dans le monde ?
[^]Re: Performances ?
Oh que oui! En France le taux de pénétration des téléphones mobiles doit tourner autour de 90%, les PC environ 60 ou 70% (?). En asie dans des pays comme la Chine et l'Inde les téléphones mobiles sont très répandu alors que les PC ...
[^]Re: Performances ?
il n'y a pas que les pc grands publics qui sont à base de x86, hein.
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Performances ?
Non bien sur mais il n'y a pas non plus que les téléphones mobiles qui sont à base de ARM...
Perso ça fait plus de 10 ans que je bosse dans l'embarqué et je n'ai jamais eu à bosser sur une plateforme x86.
PS: je n'ai pas dit qu'il n'y avait d'embarqué sur x86.
[^]Re: Performances ?
Il ne faut pas oublier que l'archi x86 (32 ou 64 bits) comprend tout plein de mécanismes hardware qui font que du code pas très optimisé tourne au final pas si mal. Par exemple sur architecture Core, on a des prefetchers hardware au niveau des caches, un cache de micro-instructions (bon ok, tout petit, mais quand meme), une exécution dans le désordre des instructions ... Bref, le compilateur est beaucoup soulagé par une architecture qui fait beaucoup de choses sans qu'on lui demande.
[^]Re: Performances ?
Ah bon? Ce n'est pourtant pas particulièrement difficile.
Ben propose tes patchs a gcc.
Sur cible ARM, gcc se prend une grande claque par rapport à RVCT .
Qui est le compilo de ARM et qui ne gère que ARM.
De plus le passage gcc3.x à gcc 4.x à quand même améliorer les choses en taille et vitesse.
PS : pour llvm, regarde le README arm pour juger l'état