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 #926154.
Run by 
Cette page a été générée par Templeet en 0.0575s (dont 0.0059 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Perl et autre
Perl c'est lent, c'est gros, c'est mou, mais c'est utile.
Oui perl grossit comme le C produit des bugs.
Mais ces langages ont ceci en commun qu'ils ont été construit par leurs utilisateurs. Des gens capable de produire de libs au kilomètre de voir revoir et rerevoir du code par ce que c'est ce dont ils avaient besoin, pour leur travail, tous les jours ...
Java par son aspect anti-cobold s'est également inscrit cette lignée. Ou encore l'affreux php.
Lisaac est peut être un tres bon langage. Mais il lui manque peut-être l'essentiel. Répondre à un vrai besoin. Trouver sa communauté.
Or le besoin aujourd'hui est de pondre du code parallellisable certes mais surtout parallellisé vraiment.
Et je n'ai pas l'impression que ce soit l'objectif premier. Dommage.
[^]Re: Perl et autre
C'est marrant, tu tombes pile sur le bon sujet.
C'est pas le premier certes, mais ça deviendra une feature majeur dans quelques mois. On en reparlera en détail avec une news spéciale.
Lisaac va implémenter COP, Concurent Object Programming.
En gros, COP permet d'automatiser la programmation parralèlle, en donnant au compilateur le sale boulot.
Pas de lib, pas de thread, pas de verrou.
En Lisaac, un programme début de deux façons :
Section Header
+ name := OBJ;
ou
Section Header
- name := OBJ;
Dans le premier cas, on a un objet à prototype classique, clonable. Chaque clone de cet objet sera différent, comme d'habitude.
Dans le second, chaque clone de l'objet donnera lieu à un thread.
Le modèle est conçu pour gérer automatiquement les priorités entre thread, avec un modèle bien à lui, que je me sens pas capable de vous expliquer ici :-)
Pour ceux qui veulent en savoir plus, rendez-vous P97 http://isaacproject.u-strasbg.fr/download/Lisaac_RM_03.pdf
On verra comment ce modèle fonctionnera, on a bien l'attention de jouer avec quelques mois avant de se déclarer satisfait.
Pour le reste ton analyse est très vraie, et très intéressante.
[^]Re: Perl et autre
En passant, une présentation du langage Clojure se trouve ici : http://clojure.blip.tv/
On y parle principalement de programmation concurrente, des méthodes classiques existantes (lock (mutex, semaphore et cie), STM, etc.) ainsi que de l'approche de Clojure.
Même si vous ne vous intéressez pas particulièrement à ce langage je vous conseille d'y jeter un oeil.
[^]Re: Perl et autre
Petite correction :
Le "permalink" de la présentation dont je parlais : http://blip.tv/file/812787
Elle est disponible en mp4 ici : http://blip.tv/file/get/Richhickey-ClojureConcurrency730.mp4
Les slides et le code présenté sont disponibles sur le premier lien.
(J'espère qu'on pourra une fois un jour peut-être éditer les messages)
[^]Re: Perl et autre
Pour donner un peu plus de précision sur COP:
Un objet '-' définit un thread avec une file d'appels. Chaque appel de slot sur cet objet va être mis en attente, et l'objet le traitera en temps venu.
Si on attend une valeur de retour, l'appel est bloquant. Il ne l'est pas dans le cas contraire.
On peut avec des paramètres et des valeurs de retour faire transiter des objets entre les threads. pour éviter les problèmes liés à la mémoire partagée, les objets partagés de type '+' sont rendus immuables (lecture seule). Les objets '-' par contre peuvent être partagés librement car ils ne sont accessibes que par envoi de messages entre threads, ne posant aucun problème de concurrence.
J'attend avec impatience de voir ce que ça va donner :)
Mildred
La Roue du Temps
[^]Re: Perl et autre
Euh, tout le comportement du programme change sur une différence de deux pixels ?
Je trouvais que les majuscules faisaient un peu trop années 1970, mais bon, on doit pouvoir s’habituer. Mais alors franchement, là, c’est du n’importe quoi.
Vous pouviez pas trouver une notation encore plus illisible, genre un . contre une , ?
[^]Re: Perl et autre
Je ne sais pas si tu connais un peu le langage, mais en fait, ça fait sens.
Un prototype s'écrit de la manière suivante:
Section Header
+ name := MON_PROTOTYPE;
+ description := "Juste un exemple";
// ...
Section Inherit
+ parent: Expanded OBJECT;
Section Public
- main <-
( + a, b:INTEGER;
a := 3;
b := 5;
a.to_string+" + "+b.to_string+" = "+(a+b).to_string+"\n".print;
);
Tu vois que les variables locales (a, b), les méthodes (main) et variables d'instance (parent), ou les propriétés décrivant l'objet (name, description, ...) sont toujours introduites par un signe + ou -.
le + correspond en général a une variable classique. Chaque objet à sa propre copie. Et devant 'name' cela signifie aussi que ton objet est probablement privé à un thread (sinon, il devient immuable).
Le - correspond au static du C, C++, Java ... La vairable est partagée entre tous les clones d'un même prototype, et est concervée entre les appels de fonction. Pour 'name' cela correspond que ton objet peut être partagé sans problèmes entre plusieurs threads sans devenir immuable (et ce faisant, il peut être lui-même un thread, selon la programmation).
A mon avis cela ne pose pas tant que ça un problème de lisibilité si la coloration syntaxique met en gras ces signes. Et je pense que dans le cas général, ce sera évident lorsqu'un objet sera + ou -.
Et si cela pose vraiment problème, c'est toujours modifiable. Par exemple dans la version 0.1 du langage, il y avait en plus du + et du - un signe * qui a été remplacé par le mot clef Expanded (qui signifie que l'objet est stocké complètrement dans la variable, ce n'est pas une référence).
La Roue du Temps
[^]Re: Perl et autre
"A mon avis cela ne pose pas tant que ça un problème de lisibilité si la coloration syntaxique met en gras ces signes."
Un code ne devrait-il pas être clair même sans coloration syntaxique ? S'il faut se crever les yeux sur un pov' caractère qui peut changer radicalement le résultat attendu (ne pas bien différencier une variable privée d'une variable statique, y a quand même là une source d'erreur énorme !).
[^]Re: Perl et autre
Enfin peut être, mais je dois te dire que d'après mon expérience, ce n'est pas une source d'erreur du tout, alors ...
La Roue du Temps