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 #925899.
Run by 
Cette page a été générée par Templeet en 0.0693s (dont 0.0189 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Prêt à être utilisé par les masses?
Ca fait des années que j'entends parler de Lisaac. Je ne comprends absolument rien aux architectures de systèmes d'exploitation ni aux avantages et inconvénients de tel langage orienté objet haut niveau face à tel autre (ou "par contrat", ou "prototype", tout ça pour moi ne veux pas dire grand chose).
Et c'est du haut de ces maigres connaissances que je vais poser la question qui tue:
- Lisaac est-il prêt à être utilisé par les développeurs? (genre on peut faire des progs avec python, perl, tout ça! Et Lisaac?)
- Si réponse négative, les éléments manquants ne risquent-ils pas de venir foutre par terre ce joli petit bench?
En tout cas chapeau à Sonntag parce que ça a l'air costaud comme truc!
[ Répondre ]
[^]Re: Prêt à être utilisé par les masses?
Si ton but est de faire un programme dans ton coin, Lisaac est prêt pour ça. Pour contre, il n'est pas encore stable. Il y a quelques changements dans le langage lui-même qui sont dans le pipeline.
Tu peux regarder dans les exemples. Il y a même un petit tetris.
[ Répondre ]
[^]Re: Prêt à être utilisé par les masses?
Techniquement, on peut faire des programmes de base comme disait Nicolas, et par exemple des logiciels avec de l'OpenGL.
Bref, de quoi faire un jeu... sans son, et sans réseau.
Mais avec de bonnes perfs ;-)
[ Répondre ]
[^]Re: Prêt à être utilisé par les masses?
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 ]
[^]Re: Prêt à être utilisé par les masses?
Juste une question : Lisaac fait-il des optimisations globales ou pas ? (ie. a-t-il besoin d'analyser tout le programme pour savoir comment compiler chaque fonction/objet/prototype - je ne sais pas trop ce que ça manipule)
Si oui, souffre-t-il (potentiellement) du problème classique des compilateurs avec optimisations globales, à savoir : tu changes une ligne dans ton programme et ça modifie radicalement tes performances (en bien ou en mal, mais c'est en mal que c'est gênant), par des modifications qui se propagent en cascade ?
Mr Lapinot - Electrons prisonniers (blog)
[ Répondre ]
[^]Re: Prêt à être utilisé par les masses?
Juste une question : Lisaac fait-il des optimisations globales ou pas ? (ie. a-t-il besoin d'analyser tout le programme pour savoir comment compiler chaque fonction/objet/prototype - je ne sais pas trop ce que ça manipule)
Oui.
Si oui, souffre-t-il (potentiellement) du problème classique des compilateurs avec optimisations globales, à savoir : tu changes une ligne dans ton programme et ça modifie radicalement tes performances (en bien ou en mal, mais c'est en mal que c'est gênant), par des modifications qui se propagent en cascade ?
Euh radicalement, je ne sais pas, ça dépend de la ligne que tu rajoutes, ça dépend de l'influence de cette différence sur le reste du programme.
Le compilateur optimise toujours au mieux : c'est une machine bête et stupide, il trace tout les types, applique toutes les optims (en fonction des flags donné en argument), donc je vois pas trop où est le problème.
Ce que je veux dire, car c'est ce que je sens derrière ta question, c'est qu'il n'y a pas d'indéterminisme ni d'instabilité : pour un code lisaac donné, quand on connait le fonctionnement du compilateur, on peut facilement avoir une intuition de ce que ça donnera en C.
[ Répondre ]
[^]Re: Prêt à être utilisé par les masses?
Non, ce que je voulais dire c'est que le problème général avec les optimisations globales c'est (par exemple) que tu peux avoir un programme qui tourne bien, qui est efficace parce que le compilateur a fait une optimisation donnée, et puis tu modifies un petit truc qui rend cette optimisation inapplicable, et les performances sont fortement dégradées sans que tu comprennes forcément d'où ça vient (en tant que programmeur je parle, je comprends bien que le comportement du compilateur lui est déterministe). C'est particulièrement sensible dans les langages fonctionnels, où le fait que tu modifies une variable ou pas va faire qu'elle est traitée différemment --- pour Lisaac, je suppose que ce problème précis ne se pose pas, mais je me demandais s'il y en avait d'autres.
C'est toujours une question délicate, le choix entre des optimisations globales ou locales. Personnellement, je préfère les secondes, parce que ça prémunit contre les surprises, et il n'y a pas forcément besoin d'avoir une connaissance approfondie du compilo pour écrire un code efficace (je pense à des langages à la ML où la phase de compilation fait parfois un peu magie noire). Mais c'est une question d'équilibre et les deux écoles existent, avec de bons arguments de chaque côté.
Mr Lapinot - Electrons prisonniers (blog)
[ Répondre ]