Journal : Lisaac plus rapide que le C !
Posté par Nicolas Boulay () le 24 avril 2008
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 !
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 #925645.
Run by 
Cette page a été générée par Templeet en 0.0535s (dont 0.0068 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Tout mauvais...
Aujourd'hui et dans un futur proche, les machines vont être beaucoup plus difficile à programmer correctement.
En effet, la RAM est "loin" du CPU. C'est à dire qu'un algo correcte prend en compte le fait que la RAM est "loin" et qu'en fait il doit considérer les différents niveaux de la mémoire cache.
Histoire de compliquer la tâche encore plus, nos CPU sont maintenant mutli-cœurs et embarquent un contrôleur de mémoire (pour les design modernes, Intel est à la bourre mais AMD est à l'heure sur ce sujet). Donc pour les algo vraiment intensifs il s'agit de considérer cette dimension (et je ne parle pas des pages de mémoire virtuelle and co).
Le lead de la glibc Ulrich Drepper a fait un bon papier qui illustre par la pratique une partie de ce que je viens de dire:
http://lwn.net/Articles/259710/
Les architectures sont tellement comlexes aujourd'hui qu'un des seuls moyens d'avoir un bon algo dans un context technique bien précis, c'est d'utiliser les outils d'instrumentation.
Donc à vos valgrind et oprofile.
[^]oprofile?
Donc à vos valgrind et oprofile.
Perso, j'utilise Valgrind pour les memory leaks et utilisation de blocs non initialisés (bonne bête celui-la, il m'a été d'une grand aide, un bonheur pour trouver des petits bugs chiants...), et gprof pour le profiling (très facile, une option pour gcc, une commande ensuite pour créer le fichier lisible).
Est-ce que oprofile fait la même chose que gprof? si oui, il est meilleur?
A première vue, il a l'air plus costaud à manipuler, donc je me demande si ça vaut le coup que je regarde plus en profondeur son utilisation.
[^]Re: oprofile?
J'utilise oprofile quand je ne peux pas utiliser valgrind et surtout callgrind. Car ce dernier avec kcachegrind te permet d'avoir une precision monstrueuse sur quelle instruction, quelle fonction est la source de la consomation de CPU. C'est vraiment l'outil absolut de profiling.
D'ailleur dans la meme collection massif pour savoir quelle fonction alloue le plus de ram ou cachegrind pour savoir qui fait le plus de boulette dans le cache c'est vraiment terrible. Si tu n'utilises que l'outil memcheck de valgrind, tu n'as encore rien decouvert de sa puissance. Et ils enterent tous gprof. Je te conseille d'essayer.
[^]Re: oprofile?
La dernière fois que j'ai regardé, ces outils du framework valgrind étaient des émulations logicielles. Leurs résultats sont malgré tout très pertinents dans la majorité des cas, mais est-ce que maintenant ces outils utilisent le kernel linux et/ou les capacités d'instrumentation hardware des CPUs? Ce qui m'avait séduit chez oprofile c'est l'utilisation de l'instrumentation hardware des CPUs. Grâce à lui j'ai pu, sans aucune modif du code, localiser où mon firefox traînait les pattes: la libfb de xorg... la morale de cette histoire: un site web complexe en 2500*1600 sans accélération matérielle... et bien c'est fini...
Cela dit, ayé, latency top est dans Linux. J'avoue que j'ai pas testé, mais si quelqu'un a déjà essayé de repérer des goulots d'étranglement avec, et bien qu'il nous fasse part de son expérience!
[^]Re: Tout mauvais...
C'est très exactement pour cette raison que je pense qu'un langage de haut niveau est plus facile à optimiser que le C. (A la base je suis ingé hardware et j'ai bossé sur le projet f-cpu)
Il y a des tas d'optimisation inaccessible en C sans casser la sémantique, par exemple, sur le layout mémoire. Tu n'as pas le droit de toucher à l'ordre des champs d'un struct en C, Lisaac peut le faire. (je crois qu'il y a une option pour le faire maintenant dans gcc mais cela peut casser des programmes)
Un langage de haut niveau permet mieux d'exprimer ce que le codeur veut faire ce qui donne suffisamment d'information au compilateur pour générer le meilleur code possible.
[^]Re: Tout mauvais...
En fait, on peut remonter ca d'un niveau:
Un algorithme ecrit sur papier permet de mieux expliquer ce que l'algorithmicien veut faire, ce qui donne suffisement d'information au developeur pour ecrire le meilleur code possible, incluant le choix des des structures de donnees.
Pour avoir travaille pendant plus de 5 ans dans le domaine de l'optimisation de code, mon experiece m'a montre que meme un algorithme ecrit dans un language de haut niveau ne retranscrit pas necessairement exactement ce que l'algorithme etait cense faire. La retranscription en code inclue parfois de devoir utiliser des fonctions de bases du language qui ont parfois beaucoup trop de semantique associe et de ce fait limite les optimisations possibles.
Idem pour la documentation du choix de l'implementation. On arrive a determiner par les commentaires ce que le developeur a voulu faire, mais on ne sait rien sur ce qu'il n'a pas fait: Quels etaient les autres solutions envisagees et pourquoi ont-elles ete ecartees? Ca permet de ne pas forcement se retapper tout le boulot de verification, ou meme de se rendre compte que le developeur a l'origine n'a pas tenu compte de quelque chose.
[^]Re: Tout mauvais...
C'est clair. Surtout que pour optimiser pour une machine particulière tu peux etre amener a utiliser des équivalence, réordonné l'algo; voir meme perdre un peu de precission si ca ne gene pas.