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 !

> Lire le journal (157 commentaires, moyenne: 3,4).

Re: Prêt à être utilisé par les masses?

Posté par Mildred (Jabber id, page perso, ) le 26/04/2008 à 00:14. (lien). Évalué à 4.

Perso, je dirais que non (et je vais travailler pour que ça devienne oui).
Pourquoi ?

D'une part, il n'y a pas de gestion correcte des erreurs (et la lib standard n'est pas très jolie). On a les contrats (formidable) mais ils ne permettent pas de gérer toutes les erreurs. Comment gérer par exemple une erreur d'allocation mémoire.
Pour le moment, si une allocation échoue, on a droit à un exit(1) ... Je n'aime pas trop.

D'autre part, le temsp de compilation est exponentiel. De ce coté, Benoît a fournit un travail extraordinaire ! Mais cela n'empêche pas que ce soit quelque chose que je considère gênant.
Si on arrive a modulariser le compilateur (compiler des modules séparément) alors on aura peut être un temps de compilation exponnentiel sur chaque module (mais raisonnable car chaque module aura une taille limitée). Bien sûr, il faut bien concevoir l'application et déterminer où seront les interfaces. Ces choix influront probablement sur les optimisation que Lisaac pourra faire.
Enfin pour le moment c'est juste une idée (que je n'ai même pas encore soumise à la mailing liste).

Et bien sûr, le dernier point, c'est le problème des bibliothèques que j'ai résolu en local mais qui n'est pas (encore ?) dans le tronc. En gros, actuellement, tu as un fichier path.li global (installé dans /usr, donc un utilisateur ne peux pas le modifier) qui liste les dossiers de ton projet et les dossiers des bibliothèques.
Impossible d'installer une bibliothèque sans toucher à ce fichier
Impossible de commencer un projet (organisé en plusieurs dossiers) sans toucher à ce fichier.

A mon avis, il faut se mettre au boulot et sans doute que dans un an ces problèmes auront disparu. J'espère.

Mildred

--
La Roue du Temps

[ Répondre ]

Vous ne pouvez plus rajouter de commentaires! (trop vieux)