LLVM - Page 1

C'est plus un topic pour la curiosité qu'autre chose, mais bon ^^ Puis ça intéressera ptêt Popo

http://www.macgeneration.com/unes/voir/127129/apple-tire-le-jus-des-processeurs/2

Jusqu'ici le compilateur qui avait la bénédiction de la pomme, et qu'on retrouvait dans son outil de programmation Xcode, c'était GCC, vénérable compilateur open-source créé au milieu des années 80. LLVM quant à lui a été initié en 2000 en tant que projet de recherche à l'Université de l'Illinois par Chris Lattner, dont il diffusera la version 1.0 en 2003. Apple a commencé à participer au projet à partir de 2005, puis a embauché Lattner pour financer son travail. L'année dernière, le projet a abouti à la sortie de Clang, un compilateur autonome basé sur LLVM et mené par Apple, qui permet une compilation rapide tout en faisant une utilisation restreinte de la mémoire, en apportant des diagnostics explicites, une architecture modulaire basée sur des bibliothèques, et une intégration soignée à un environnement de développement tel que celui d'Xcode, le tout proposé sous la houlette de la licence open-source BSD. Apple proposera dorénavant LLVM au sein d'Xcode, parallèlement à GCC 4.2, laissant le choix aux programmeurs du compilateur qui conviendra le mieux à leur projet.

Je n'avais jamais entendu parler de LLVM, est-ce que vous connaissez ? Ça me paraît un peu bizarre qu'un compilo si jeune puisse rivaliser avec GCC qui commence à avoir de la bouteille, mais bon, pourquoi pas ? (surtout s'il est spécialisé)

Ils parlent qu'on peut arriver a gagner jusqu'a 33% en rapiditée mais je trouve pas ça etonant si c'est basé sur une mini vm...

A vrai dire, je suis sur qu'il est possible de faire des trucs plus rapide a partir d'un langague de haut niveau (C++, .Net, ObjC) avec une minivm qu'avec du code natif...


D'ailleurs j'ai vraiment l'impression qu'il s'agit d'une forme de .net framework...

Une forme de VM sur lequel peut venir des convertisseur de tel, tel ou tel langage vers le bytecode de la vm... c'est exactement ce qui est fant en .net....

Apres la différence viens surement du fait que LLVM n'a pas un framework applicatif comme .Net car il utilise le framework applicatif natif de la machine et non un integré... Mais je comprend ptet mal..

Ce que donne mes bench (Un seul lancement - pas de moyenne) :

LLVM 2.3 (Front end GCC 4.2.1)

Construct (3*(a*x+b*y+c*z) with a=1/2, b=2/3 and c=4/5...0.00401ms [249169 execs/sec]
eval (sum ai*ai*ai) - quite different - N=100......0.04ms
eval (sum ai*ai*ai) -  quite similar  - N=100......0.05ms
eval (sum ai*ai*ai) - quite different - N=1000......0.43ms
eval (sum ai*ai*ai) -  quite similar  - N=1000......0.43ms
eval (sum ai*ai*ai) - quite different - N=10000......2.40ms
eval (sum ai*ai*ai) -  quite similar  - N=10000......2.40ms
eval (sum ai*ai*ai) - quite different - N=100000......68.00ms
eval (sum ai*ai*ai) -  quite similar  - N=100000......60.00ms
eval (sum ai*ai*ai) - quite different - N=1000000......784.00ms
eval (sum ai*ai*ai) -  quite similar  - N=1000000......884.00ms
eval(sum(i*x^i, n=0..20000)...12ms
eval(x+f(x)+f(f(x))+...+f(5000)(x)), subs f to id...2324ms
eval(sum(i,i=0..20000)+x+sum(i,i=0..20000))...4ms
eval(sum(sin(n*PI/6), n=0..20000)...44ms
eval((2+3*I/4)^1000000)...752ms
evalf(sin(1+PI)^2+3^sqrt(1+PI^2)) to 100000 bits...2409ms
expand ((a0+...a500)^2), replace a0, reeval...664ms
expand ((x0+...x2+1)^16*(1+(x0+...x2+1)^16))...1268ms
expand ((x+y^400000000000+z)^20*(1+x+y+z^-1)^20)...1076ms
expand ((1+x)^1000*(2+x)^1000)...888ms
expand ((17+x)^600*(42+x)^600)...800ms
expand ((1+sqrt(5))^65000)...8ms
expand ((1+x+y)^500)...1688ms
divide ( (1+x)^1000+1 , (1-x)^500)...904ms
divide ( (1+x)^1000+1 , x^3-5*x+17)...152ms
divide ( (1+x+y^2)^50+1 , (1-x)^25+y)...1084ms
divide ( (1+x+y^2)^25+1 , x^3*y-5*x*y^42+17*y+1)...1584ms
gcd ( (1+2*x)^200*(x^3+2*x^2+1) , (1+2*x)^42*(x^3-2*x+42) )...112ms
gcd ( (1+2*x)^200*(x^3+2*x^2+1) , (1+2*x)^42*(x^3-2*x+42)+1 )...88ms
gcd ( (1+2*x+y)^100*(x^3+2*x^2*y+1) , (1+2*x+y)^42*(x^3-2*x+42) )...3024ms
gcd ( (x^2-y^2)*(a+b)^10 , (x-y)*(a-c)^10 )...0ms
gcd ( (x-y)^50+a , (x+y)^50 )...0ms
diff ( x/(1+sin(x^(y+x^2)))^2 , x)...0.00146ms
Total time 20685ms

ICC 10.0

Construct (3*(a*x+b*y+c*z) with a=1/2, b=2/3 and c=4/5...0.00333ms [300000 execs/sec]
eval (sum ai*ai*ai) - quite different - N=100......0.04ms
eval (sum ai*ai*ai) -  quite similar  - N=100......0.03ms
eval (sum ai*ai*ai) - quite different - N=1000......0.39ms
eval (sum ai*ai*ai) -  quite similar  - N=1000......0.35ms
eval (sum ai*ai*ai) - quite different - N=10000......2.00ms
eval (sum ai*ai*ai) -  quite similar  - N=10000......1.71ms
eval (sum ai*ai*ai) - quite different - N=100000......52.00ms
eval (sum ai*ai*ai) -  quite similar  - N=100000......40.00ms
eval (sum ai*ai*ai) - quite different - N=1000000......688.00ms
eval (sum ai*ai*ai) -  quite similar  - N=1000000......768.00ms
eval(sum(i*x^i, n=0..20000)...8ms
eval(x+f(x)+f(f(x))+...+f(5000)(x)), subs f to id...1380ms
eval(sum(i,i=0..20000)+x+sum(i,i=0..20000))...4ms
eval(sum(sin(n*PI/6), n=0..20000)...36ms
eval((2+3*I/4)^1000000)...764ms
evalf(sin(1+PI)^2+3^sqrt(1+PI^2)) to 100000 bits...2392ms
expand ((a0+...a500)^2), replace a0, reeval...524ms
expand ((x0+...x2+1)^16*(1+(x0+...x2+1)^16))...1125ms
expand ((x+y^400000000000+z)^20*(1+x+y+z^-1)^20)...1032ms
expand ((1+x)^1000*(2+x)^1000)...896ms
expand ((17+x)^600*(42+x)^600)...752ms
expand ((1+sqrt(5))^65000)...8ms
expand ((1+x+y)^500)...1664ms
divide ( (1+x)^1000+1 , (1-x)^500)...860ms
divide ( (1+x)^1000+1 , x^3-5*x+17)...120ms
divide ( (1+x+y^2)^50+1 , (1-x)^25+y)...876ms
divide ( (1+x+y^2)^25+1 , x^3*y-5*x*y^42+17*y+1)...1232ms
gcd ( (1+2*x)^200*(x^3+2*x^2+1) , (1+2*x)^42*(x^3-2*x+42) )...100ms
gcd ( (1+2*x)^200*(x^3+2*x^2+1) , (1+2*x)^42*(x^3-2*x+42)+1 )...96ms
gcd ( (1+2*x+y)^100*(x^3+2*x^2*y+1) , (1+2*x+y)^42*(x^3-2*x+42) )...3040ms
gcd ( (x^2-y^2)*(a+b)^10 , (x-y)*(a-c)^10 )...0ms
gcd ( (x-y)^50+a , (x+y)^50 )...0ms
diff ( x/(1+sin(x^(y+x^2)))^2 , x)...0.00104ms
Total time 18460ms

GCC 4.3.0

Construct (3*(a*x+b*y+c*z) with a=1/2, b=2/3 and c=4/5...0.00400ms [250000 execs/sec]
eval (sum ai*ai*ai) - quite different - N=100......0.04ms
eval (sum ai*ai*ai) -  quite similar  - N=100......0.07ms
eval (sum ai*ai*ai) - quite different - N=1000......0.48ms
eval (sum ai*ai*ai) -  quite similar  - N=1000......0.50ms
eval (sum ai*ai*ai) - quite different - N=10000......1.71ms
eval (sum ai*ai*ai) -  quite similar  - N=10000......1.50ms
eval (sum ai*ai*ai) - quite different - N=100000......60.00ms
eval (sum ai*ai*ai) -  quite similar  - N=100000......52.00ms
eval (sum ai*ai*ai) - quite different - N=1000000......764.00ms
eval (sum ai*ai*ai) -  quite similar  - N=1000000......916.00ms
eval(sum(i*x^i, n=0..20000)...12ms
eval(x+f(x)+f(f(x))+...+f(5000)(x)), subs f to id...1616ms
eval(sum(i,i=0..20000)+x+sum(i,i=0..20000))...4ms
eval(sum(sin(n*PI/6), n=0..20000)...40ms
eval((2+3*I/4)^1000000)...768ms
evalf(sin(1+PI)^2+3^sqrt(1+PI^2)) to 100000 bits...2428ms
expand ((a0+...a500)^2), replace a0, reeval...608ms
expand ((x0+...x2+1)^16*(1+(x0+...x2+1)^16))...1145ms
expand ((x+y^400000000000+z)^20*(1+x+y+z^-1)^20)...1032ms
expand ((1+x)^1000*(2+x)^1000)...836ms
expand ((17+x)^600*(42+x)^600)...748ms
expand ((1+sqrt(5))^65000)...8ms
expand ((1+x+y)^500)...1704ms
divide ( (1+x)^1000+1 , (1-x)^500)...876ms
divide ( (1+x)^1000+1 , x^3-5*x+17)...132ms
divide ( (1+x+y^2)^50+1 , (1-x)^25+y)...1004ms
divide ( (1+x+y^2)^25+1 , x^3*y-5*x*y^42+17*y+1)...1388ms
gcd ( (1+2*x)^200*(x^3+2*x^2+1) , (1+2*x)^42*(x^3-2*x+42) )...104ms
gcd ( (1+2*x)^200*(x^3+2*x^2+1) , (1+2*x)^42*(x^3-2*x+42)+1 )...88ms
gcd ( (1+2*x+y)^100*(x^3+2*x^2*y+1) , (1+2*x+y)^42*(x^3-2*x+42) )...3056ms
gcd ( (x^2-y^2)*(a+b)^10 , (x-y)*(a-c)^10 )...0ms
gcd ( (x-y)^50+a , (x+y)^50 )...0ms
diff ( x/(1+sin(x^(y+x^2)))^2 , x)...0.00134ms
Total time 19391ms

Pour moi il n'est ni extraordinaire, ni ridicule.
(GMP et MPFR étaient les mêmes pour tous ces tests).
Seul le test eval(x+f(x)+f(f(x))+...+f(5000)(x)), subs f to id...2324ms
se démarque des autres.

Est-ce que GMP et MPFR sont représentatifs ? (parce que ça doit pas mal utiliser les entiers, sans compter qu'il y a peut-être des questions de régularité de code, non ?) - j'y connais pas grand-chose en compilation,hein

Et pourquoi il a besoin d'un front-end ?

merci pour ces tests

j('alais dire la meme chose que flan, les resultat semblent pas si mal, mais est-ce que GMP et MPFR sont bien adapté a ce genre de chose ?

Flanker (./4) :
Est-ce que GMP et MPFR sont représentatifs ?

Ce sont les mêmes binaires pour les libraries utilisés pour les 3 tests.
Il est vrai par contre que certains sous-tests ne mesurent que GMP (expand ((17+x)^600*(42+x)^600)) ou que MPFR (evalf(sin(1+PI)^2+3^sqrt(1+PI^2)) to 100000 bits...)
Mais la majorité c'est du code compilé par le compilateur (code avec des if, des arbres, des décisions, de l'allocation, du déplacement, et du calcul à faire).

Flanker (./4) :
Et pourquoi il a besoin d'un front-end ?

Parce qu'ils se concentrent sur le middle-end et le back end, et que faire un parseur C++ c'est pas simple
(C'est mon opinion. Je ne sais pas leur vrai raison).

Flanker (./4) :
(parce que ça doit pas mal utiliser les entiers, sans compter qu'il y a peut-être des questions de régularité de code, non ?)

Qu'appelles-tu régularité de code ?

PpHd (./6) :

Flanker (./4) :
Et pourquoi il a besoin d'un front-end ?

Parce qu'ils se concentrent sur le middle-end et le back end, et que faire un parseur C++ c'est pas simple (C'est mon opinion. Je ne sais pas leur vrai raison).

Ok ^^
est-ce que le front-end a beaucoup d'importance ? (je suppose que non si c'est juste le parseur, mais bon...)

Flanker (./4) :
(parce que ça doit pas mal utiliser les entiers, sans compter qu'il y a peut-être des questions de régularité de code, non ?)

Qu'appelles-tu régularité de code ?

je ne sais pas vraiment en fait disons qu'un code avec juste quelques appels de fonctions et des belles boucles for doit être bien plus simple à optimiser qu'un code qui part dans tous les sens, avec des if à prédire, des switchs de partout, des fonctions à inliner ou pas, etc. ?

Flanker (./7) :
disons qu'un code avec juste quelques appels de fonctions et des belles boucles for doit être bien plus simple à optimiser qu'un code qui part dans tous les sens, avec des if à prédire, des switchs de partout, des fonctions à inliner ou pas, etc. ?

Dans ce bench, tu as les 2 genres.
Le premier pour certains ((expand ((17+x)^600*(42+x)^600), evalf(sin(1+PI)^2+3^sqrt(1+PI^2)) to 100000 bits), le second pour d'autre (eval (sum ai*ai*ai) - quite similar - N=1000000, eval(x+f(x)+f(f(x))+...+f(5000)(x)), subs f to id, expand ((a0+...a500)^2), replace a0, ..)

J'oubliais pour compiler avec llvm, ne pas oublier -fgnu89-inline

Et les conclusions pour les décideurs préssés : LLVM est 12% plus lent qu'ICC. GCC est 5% plus lent qu'ICC.

J'ai pas encore bien pigé si il y avais une VM ou pas, et si le code generé etait du bytecode pur, mais la ou Apple pourrais avoir a y gagner, c'est que les application compilé avec LLVM n'auraient pas besoin d'etre recompilé si l'archi CPU change. Et si en plus l'overhead est minimum, voir negatif dans certain cas, je pense en effet qu'il y aurais tout a y gagner.


PpHd: je pense que ce type de test n'est pas forcement le plus adapté pour tester llvm, je me trompe peut-être, mais je pense pas qu'apple ai menti en disant que dans certain cas ils arrivaient à gagner 33%...

D'ailleurs, c'est du C ou du C++ ton code ?

Godzil (./9) :
J'ai pas encore bien pigé si il y avais une VM ou pas, et si le code generé etait du bytecode pur, mais la ou Apple pourrais avoir a y gagner, c'est que les application compilé avec LLVM n'auraient pas besoin d'etre recompilé si l'archi CPU change. Et si en plus l'overhead est minimum, voir negatif dans certain cas, je pense en effet qu'il y aurais tout a y gagner.

Ca produit un binaire natif sans aucun besoin en VM. Comme un compilateur classique.
Le bytecode est juste un format intermédiaire pendant la compilation, qui permet de facilement appliquer des transformations (comme le format tree de gcc).
Voir les doc.

Godzil (./9) :
PpHd: je pense que ce type de test n'est pas forcement le plus adapté pour tester llvm, je me trompe peut-être, mais je pense pas qu'apple ai menti en disant que dans certain cas ils arrivaient à gagner 33%...

Au contraire, je pense que c'est un test très complet et représentatif.
33% ? Faut arrêter de réver. Lorsqu'un compilateur gagne 2%, c'est très bien (Sauf pour les boucles hyper simples, qui gagneraient à être écrite en assembleur mais qui sont tout sauf quelque chose de représentatif).

Godzil (./9) :
D'ailleurs, c'est du C ou du C++ ton code ?

Du c99.

Je pense que c'est la que llvm peut gagner, c'est sur les langages de plus haut niveau que le C

et le 33% je le tiens de la :

Dans le détail, LLVM maintient un semblant de compatibilité avec GCC tout en s'avérant bigrement plus efficace : le code compilé par LLVM ne requiert uniformément que deux tiers du temps nécessité par l'exécution du même code compilé par GCC. Un avantage de taille, donc, puisqu'une recompilation suffit à rendre tout logiciel 33% plus rapide! Pour cela LLVM tire parti des moindres optimisations pour le matériel moderne, à toutes les étapes de la compilation.

et : http://www.appleinsider.com/articles/08/06/20/apples_other_open_secret_the_llvm_complier.html

PpHd (./10) :
Ca produit un binaire natif sans aucun besoin en VM. Comme un compilateur classique.
Le bytecode est juste un format intermédiaire pendant la compilation, qui permet de facilement appliquer des transformations (comme le format tree de gcc). Voir les doc.

Oui j'ai vu ça apres avoir posté, c'est comme le bytecode de .net

Non, puisque le bytecode de .NET est ensuite interprété.

Non le bytecode de .Net n'est pas interprété (il n'a même pas été fait pour ça...), il est compilé en dynamique.
Et si j'ai bien compris, LLVM c'est pas exactement la même chose... C'est un truc qui prend en entrée du bytecode généré par le compilateur (GCC par ex), et en sortie fournit un binaire natif qui est celui que tu distribues, c'est bien ça ?

Il y a les 2 solutions, il y a un JIT et il y a des compilateurs natifs (directement en code machine, ou alors en C qui est ensuite compilé avec GCC).

Godzil (./11) :

et : http://www.appleinsider.com/articles/08/06/20/apples_other_open_secret_the_llvm_complier.html

Je cite

Sources report that LLVM-GCC "compiles code that consistently runs 33% faster" than code output from GCC.

Ca ressemble à du FUD marketing où je ne m'y connais pas.

PpHd (./15) :

Je cite

Sources report that LLVM-GCC "compiles code that consistently runs 33% faster" than code output from GCC.

Ca ressemble à du FUD marketing où je ne m'y connais pas.

Peut-etre, mais connaissant Apple, c'est pas trop leur genre, pas quand c'est aussi visible

./13 Le compilateur .NET génère un fichier non natif, qui sera interprété/exécuté dans un environnement d'exécution ensuite.
Si j'ai bien compris, LLVM est un compilateur au sens classique : il produit un binaire natif.

./16 > enfin, c'est quand même sûrement dans des cas super particuliers

Un autre bench mettant plus en oeuvre la puissance du compilateur (expand((1+x+y+z)^20*(1+(1+x+y+z)^20)):

ICC : 3656ms
GCC : 3772ms (+3% )
LLVM : 4256ms (+17% )

Il n'est quand même pas mauvais, ICC

Godzil (./16) :
Peut-etre, mais connaissant Apple, c'est pas trop leur genre, pas quand c'est aussi visible

Tu ne les connais pas bien alors. Ou alors tu es trop fanatique pour le reconnaître.

En fait, si j'ai bien compris ce qui est dit dans vos différents cite, ce n'est pas la compilation qui est plus rapide, mais l'exécution du programme compilé...

Bah, c'est ce qui compte. Le temps de compilation a peu d'importance.

pedrolane (./22) :
En fait, si j'ai bien compris ce qui est dit dans vos différents cite, ce n'est pas la compilation qui est plus rapide, mais l'exécution du programme compilé...

En général, les temps de compilation ne sont pas trop importants (du moment que tu mets pas 5H pour compiler ton programme).
Les temps données sont les temps d'éxécution du programme compilée avec les différents compilateurs.

Hmm, apparemment Mirosoft bosse sur quelque chose de semblable: Phoenix
Par contre c'est difficile de trouver beaucoup d'informations dessus, mais je vais regarder ça de plus près
(Et le pire c'est que j'ai trouvé ça alors que ça n'a presque aucun rapport avec ce que je cherchais )

Ils vont se taper un procès pour ce nom, comme Mozilla à l'époque...

http://www.itrmanager.com/tribune/240/llvm-habits-neufs-compilateur-br-jean-marie-chauvet.html

Les chiffres donnés dans l'article ont plutôt tendance à contredire PpHd (=> les exemples choisis doivent être bien particuliers), ou alors les choses ont beaucoup changé en un an...

Non, c'est les mêmes. Voir post ./11. Le FUD marketing n'a pas changé
Sinon je peux aussi te sortir le fait que GCC 4.4 est 38% plus rapide que GCC 4.3 sur un type de source super particulier...cf. http://linuxfr.org/2009/04/21/24809.html

Ok, ça ne m'étonne pas plus que ça en fait

quand j'aurais un peu plus de temps, je testerai tout de même sur quelques codes à moi, pour voir