Jérémy JUST <jeremy_just@netcourrier.com> wrote:
> Le Sun, 7 May 2006 08:45:14 +0000 (UTC),
> talon@lpthe.jussieu.fr (Michel Talon) a écrit :
>
> > Moi je fais tourner un programme qui ne fait que du perl (...), qui
> > passe sont temps à l'interpréter
>
> Perl est un langage compilé.

Perl est un langage compilé en bytecode. L'interprète passe son temps à
interpréter le bytecode. C'est exactement comme si Java passait son temps à
interpréter le bytecode sans le compiler à la volée en code machine. Là
est toute la différence. Toute la différence est dans le compilateur JIT,
par exemple psyco pour python. Comme le dit l'auteur de psyco:
"
Psyco shows that it is possible to execute Python code at speeds
approaching that of fully compiled languages, by "specialization". The
current prototype operates on i386-compatible processors and shows 2
to 100 times speed-ups, depending on code.
"
Le compilateur JIT de java, lui, marche effectivement.

>
> Si tu passes ton temps à interpréter du Perl, c'est que tu utilises
> sans arrêt des « eval() », et tu es censé savoir ce que tu fais.
>

Tu es sûr que tu sais ce que tu fais, toi même?

>

--

Michel TALON

Jérémy JUST <jeremy_just@netcourrier.com> wrote:
> Le Sat, 6 May 2006 21:01:17 +0000 (UTC),
> talon@lpthe.jussieu.fr (Michel Talon) a écrit :
>
> > Autant dire qu'une machine avec beaucoup de processeurs ne va pas
> > faire gagner grand chose.
>
> D'un autre côté, pour un serveur web, on peut sans inconvénient
> lancer un processus par processeur et ne pas s'embarrasser de threads.
>

Et si ces processus ont besoin de partager des données on retombe dans les
complexités de la communication interprocessus (ce qui ne veut pas dire que le
partage par des threads soit simple). De plus le point qui est important est
que les threads peuvent être utiles même pour un seul processeur, dans la
mesure où un thread bloquant ne bloque pas l'ensemble du processus.


>

--

Michel TALON

Le Fri, 12 May 2006 09:11:21 +0000, Michel Talon écrivait:

>
> Perl est un langage compilé en bytecode. L'interprète passe son temps à
> interpréter le bytecode. C'est exactement comme si Java passait son temps à
> interpréter le bytecode sans le compiler à la volée en code machine.

Heureusemen Perl 6 aura un compilateur JIT. D'ailleurs PUGS est il un JIT?
Il faut que je vérifie...

--
Les défauts n'apparaissent qu'après que le programme ait passé (avec
succès) la phase d'intégration.
Loi de Klipstein.

Emmanuel Florac <eflorac@ezglkhzglihzrhg.com> wrote:
> Le Fri, 12 May 2006 09:11:21 +0000, Michel Talon écrivait:
>
> >
> > Perl est un langage compilé en bytecode. L'interprète passe son temps à
> > interpréter le bytecode. C'est exactement comme si Java passait son temps à
> > interpréter le bytecode sans le compiler à la volée en code machine.
>
> Heureusemen Perl 6 aura un compilateur JIT. D'ailleurs PUGS est il un JIT?
> Il faut que je vérifie...
>

Oui, sauf que faire un compilateur JIT est un problème non trivial. Regarde le
nombre d'années qu'il a fallu à Sun pour avoir quelque chose d'efficace.
IBM en a fait un trés bon, mais ils ont parmi les plus gros labos de recherche
au monde. Idem pour Microsoft avec le C#. J'ai un doute sérieux que les
mêmes ressources soient à la disposition de Perl.

--

Michel TALON

Le Fri, 12 May 2006 11:33:33 +0000, Michel Talon écrivait:

> J'ai un doute sérieux que les
> mêmes ressources soient à la disposition de Perl.

Ils ont tout le temps, ça compense

--
Le travail est la malédiction des classes qui boivent.
O. Wilde.

Emmanuel Florac <eflorac@ezglkhzglihzrhg.com> wrote:
> Le Fri, 12 May 2006 11:33:33 +0000, Michel Talon écrivait:
>
> > J'ai un doute sérieux que les
> > mêmes ressources soient à la disposition de Perl.
>
> Ils ont tout le temps, ça compense
>

Pas vraîment. Déjà perl6 lui même a été repoussé et repoussé indéfiniment.
S'il faut 10 ans pour avoir un JIT qui marche il est bien possible que plus
personne ne se servira de perl depuis longtemps à ce moment là. Déjà que perl
passe sérieusement de mode en ce moment, les gens ne parlent plus que de ruby.


--

Michel TALON

Le Fri, 12 May 2006 12:25:28 +0000, Michel Talon écrivait:

>
> Pas vraîment. Déjà perl6 lui même a été repoussé et repoussé indéfiniment.
> S'il faut 10 ans pour avoir un JIT qui marche il est bien possible que plus
> personne ne se servira de perl depuis longtemps à ce moment là. Déjà que perl
> passe sérieusement de mode en ce moment, les gens ne parlent plus que de ruby.

Tu sais, la mode... Perl6 n'est pas repoussé indéfiniment, on peut
l'utiliser dès aujourd'hui!

--
A thing of beauty is a joy forever.
J. Keats.

Ah! Singe débotté, hisse un jouet fort et vert!
Marcel Bénabou.

Emmanuel Florac <eflorac@ezglkhzglihzrhg.com> writes:

> Le Fri, 12 May 2006 12:25:28 +0000, Michel Talon écrivait:
>
>>
>> Pas vraîment. Déjà perl6 lui même a été repoussé et repoussé indéfiniment.
>> S'il faut 10 ans pour avoir un JIT qui marche il est bien possible que plus
>> personne ne se servira de perl depuis longtemps à ce moment là. Déjà que perl
>> passe sérieusement de mode en ce moment, les gens ne parlent plus que de ruby.
>
> Tu sais, la mode... Perl6 n'est pas repoussé indéfiniment, on peut
> l'utiliser dès aujourd'hui!

Et tant que les gens ne font que parler de ruby, ils ne codent pas

PK

--
|\_,,,---,,_PatriceKARATCHENTZEFF
ZZZzz/,`.-'`'-.;-;;,_mailto:p.karatchentzeff@free.fr
|,4-))-,_.,\(`'-'http://p.karatchentzeff.free.fr
'---''(_/--'`-'\_)

On Fri, 12 May 2006 09:15:52 +0000 (UTC)
talon@lpthe.jussieu.fr (Michel Talon) wrote:

>> D'un autre côté, pour un serveur web, on peut sans inconvénient
>> lancer un processus par processeur et ne pas s'embarrasser de threads.
> Et si ces processus ont besoin de partager des données

Il me semble que la norme CGI impose que les requêtes soient
indépendantes.


--
Jérémy JUST <jeremy_just@netcourrier.com>

Le Fri, 12 May 2006 16:44:40 +0200, Patrice Karatchentzeff a écrit:

>
> Et tant que les gens ne font que parler de ruby, ils ne codent pas

En effet Et on approche les 10000 modules CPAN... Il reste du chemin à
faire pour Ruby. Et puis certains sont vraiment monstrueux, regardez ce
que peut faire Moot, ou Catalyst...

--
Il y a toujours un bug de plus.
Loi de Lubarsky.

Jérémy JUST , dans le message <4464cbd2$0$7681$626a54ce@news.free.fr>, a
écrit:
> Il me semble que la norme CGI impose que les requêtes soient
> indépendantes.

Un serveur web peut faire autre chose que du CGI.

Le Fri, 12 May 2006 22:01:05 +0200,
Emmanuel Florac <eflorac@imaginet.fr> a écrit :

> regardez ce que peut faire Moot, ou Catalyst...

Tu aurais une URL pour Moot? J'ai l'impression de ne rien trouver de
ce nom sur CPAN.


--
Jérémy JUST <jeremy_just@netcourrier.com>

Le Sat, 13 May 2006 13:50:44 +0200, Jérémy JUST a écrit:

>
> Tu aurais une URL pour Moot? J'ai l'impression de ne rien trouver de
> ce nom sur CPAN.

Emmêlage de clavier c'est Moose...

http://search.cpan.org/search?mode=module&query=Moose

--
entia non sont multiplicanda praeter necessitatem.
John Ponce of Cork.