Journal : Lisaac plus rapide que le C !
Posté par Nicolas Boulay () le 24 avril 2008
0
Tout le monde s'en fout, mais cela fait des années que je suis persuadé qu'un langage de très haut niveau à plus de potentiel d'optimisation qu'un langage aussi bas niveau que le C. Et pourtant dés que l'on veut de la performance, on pense C.C'est fait, Lisaac, un langage impératif à prototype, a plus de point que le C dans le langage shoutout. Il s'agit de microbenchmarks, dont l'algorithme est imposé.
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all(...)
Cela fait un test un peu plus complet que le code mpeg2 qui servait de test.
http://isaacproject.u-strasbg.fr/li/li_benchs.html
Chapeau à Ben !
> Lire le journal (157 commentaires, moyenne: 3,4).
Vous avez demandé le commentaire #925588.
Run by 
Cette page a été générée par Templeet en 0.0575s (dont 0.0063 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
...
Heu, a part pour les arbres binnaires, il n'y a pas de grosses differences : http://shootout.alioth.debian.org/gp4/benchmark.php?test=all(...)
Et puis bon le pb de shootout, c'est que les "tests" ne sont pas forcement représentatif.
[^]Re: ...
"Et puis bon le pb de shootout, c'est que les "tests" ne sont pas forcement représentatif."
C'est pas le problème du shoutout, c'est le problème des microbenchs en général par rapport à un bench applicatif.
Mais si un langage n'est pas devant dans ce genre de cas, il a très peu de chance d'être devant dans des cas plus gros.
[^]Re: ...
Et puis bon le pb de shootout, c'est que les "tests" ne sont pas forcement représentatif.
J'ai regarder le cas des arbres binnaires, et on peut voir un beau malloc dans l'implementation.
Celui ci est appelé un certain nombre de fois (59157182).
Un coup de profiler confirme que ce test benchmark l'allocateur memoire de la libc...
[^]Re: ...
Effectivement, en 5 minutes, j'ai remplacé l'allocation par de la pré-allocation et les perfs sont multipliées par 10. Niveau consommation de mémoire ce n'est pas ça (mais on s'en fout ici, ça peut être réglé avec un peu plus d'effort).
Sans optimisation :
bash-3.2$ time ./binarytrees.gcc_run 16
stretch tree of depth 17 check: -1
131072 trees of depth 4 check: -131072
32768 trees of depth 6 check: -32768
8192 trees of depth 8 check: -8192
2048 trees of depth 10 check: -2048
512 trees of depth 12 check: -512
128 trees of depth 14 check: -128
32 trees of depth 16 check: -32
long lived tree of depth 16 check: -1
real 0m11.233s
user 0m8.983s
sys 0m0.000s
Avec :
bash-3.2$ /usr/bin/gcc -pipe -Wall -O3 -fomit-frame-pointer -march=pentium4 -lm binarytrees.c -o binarytrees.gcc_run
bash-3.2$ time ./binarytrees.gcc_run 16
stretch tree of depth 17 check: -1
131072 trees of depth 4 check: -131072
32768 trees of depth 6 check: -32768
8192 trees of depth 8 check: -8192
2048 trees of depth 10 check: -2048
512 trees of depth 12 check: -512
128 trees of depth 14 check: -128
32 trees of depth 16 check: -32
long lived tree of depth 16 check: -1
real 0m1.235s
user 0m0.843s
sys 0m0.140s
void* mem_chunks = NULL;
char* mem_pos = NULL;
char* mem_chunks_nbr = 0;
void
*my_malloc(size_t NBYTES)
{
char* temp;
if (! mem_chunks)
mem_pos = mem_chunks = malloc(NBYTES * 100000000);
temp = mem_pos;
mem_pos += NBYTES;
mem_chunks_nbr++;
return temp;
}
void
*my_free(void *APTR)
{
if (! --mem_chunks_nbr) {
free(mem_chunks);
mem_chunks = NULL;
}
return NULL;
}
[^]Re: ...
Bug :
s/char* mem_chunks_nbr = 0;/int mem_chunks_nbr = 0;/
[^]Re: ...
Les tests sont intéressants, même si il faut les prendre avec des pincettes. Ca donne un aperçu du potentiel.
Un autre indice que le C n'est pas la panacée est arrivé par python. La version .NET de python (IronPython) est arrivé soit à égalité, soit a été légèrement plus rapide que la version en C de l'interpréteur python sur une série de benchmark officiels.
Ca veut bien dire que on peut faire plus vite que du C. Je pense que c'est vrai en particulier sur des projets complexes, où le compilateur peut prendre une décision plus informée que l'être humain.
Sinon pour lisaac, si je me souviens bien, lisaac analyse l'ensemble du programme pour en optimiser tous ses aspects. Ca veut dire que sur un petit programme, il peut enlever des contraintes que le programmeur en C garderait. Après, sur un très gros programme, on peut imaginer qu'il pourra enlever beaucoup moins de contraintes et donc aura plus de mal à générer du code performant. Ou peut-être au contraire, il découvrira des optimisations inaperçues à la vue du programmeur.
L'absence de notion de bibliothèque est aussi un problème. Si j'ai bien compris les dernières explications sur le sujet, la notion de bibliothèque va justement réduire les capacités d'optimisation de lissac, puisque celui-ci ne pourra pas optimiser la partie du code externe.
Si tout le monde migrait a lissac, ce serait un peu comme passer à une gentoo en stage 1. Un truc de geek quoi.
phil.freehackers.org
[^]Re: ...
Le système de bibliothèques sur lequel je travaille n'enlève rien aux optimisations ... Car ce sont des bibliothèques sources (il n'est pas encore possible de compiler les bibliothèques séparément).
Reste à soumettre ça dans le tronc principal :)
Sinon, pour l'avenir, on peut très bien imaginer des modules binaires (donc compilation séparée et possibilité de chargement runtime) qui utilise une interface bien définie quelque part. Et dans ce cas, il paraît évident que certaines optimisations vont partir. Mais comme en général on se débrouille pour avoir une interface minimale entre des modules, ça ne devrait pas être gênant je pense.
La Roue du Temps