On Sun, 07 May 2006 08:45:14 +0000, Michel Talon wrote:
Par exemple un thread fait des requêtes DNS, tandis qu'un autre gère l'affichage. Si ta requête DNS met des plombes à revenir et bloque l'affichage, tu as l'impression que ton programme est figé, et ça c'est désastreux.
Bah disons que par exemple, avec Firefox (écrit en C++, je crois), si la requete DNS mets une plombe, la page que je veux visiter ne s'affichera que dans une plombe :-). Oui, je sors....
On Sun, 07 May 2006 08:45:14 +0000, Michel Talon wrote:
Par exemple un thread fait des requêtes DNS, tandis
qu'un autre gère l'affichage. Si ta requête DNS met des plombes à revenir
et bloque l'affichage, tu as l'impression que ton programme est figé, et ça
c'est désastreux.
Bah disons que par exemple, avec Firefox (écrit en C++, je crois), si la
requete DNS mets une plombe, la page que je veux visiter ne s'affichera
que dans une plombe :-).
Oui, je sors....
On Sun, 07 May 2006 08:45:14 +0000, Michel Talon wrote:
Par exemple un thread fait des requêtes DNS, tandis qu'un autre gère l'affichage. Si ta requête DNS met des plombes à revenir et bloque l'affichage, tu as l'impression que ton programme est figé, et ça c'est désastreux.
Bah disons que par exemple, avec Firefox (écrit en C++, je crois), si la requete DNS mets une plombe, la page que je veux visiter ne s'affichera que dans une plombe :-). Oui, je sors....
Moi je fais tourner un programme qui ne fait que du perl (...), qui passe sont temps à l'interpréter
Perl est un langage compilé.
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.
-- Jérémy JUST
Nicolas George
Jérémy JUST , dans le message , a écrit :
Perl est un langage compilé.
Seulement partiellement. Ce qui est manipulé après la phase de compilation n'est pas du langage machine, c'est un arbre syntaxique qui reste à exécuter.
Jérémy JUST , dans le message
<20060512002643.06f12125@norbert.inapg.inra.fr>, a écrit :
Perl est un langage compilé.
Seulement partiellement. Ce qui est manipulé après la phase de compilation
n'est pas du langage machine, c'est un arbre syntaxique qui reste à
exécuter.
Seulement partiellement. Ce qui est manipulé après la phase de compilation n'est pas du langage machine, c'est un arbre syntaxique qui reste à exécuter.
talon
Jérémy JUST wrote:
Le Sun, 7 May 2006 08:45:14 +0000 (UTC),
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 Sun, 7 May 2006 08:45:14 +0000 (UTC),
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.
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
talon
Jérémy JUST wrote:
Le Sat, 6 May 2006 21:01:17 +0000 (UTC),
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
Jérémy JUST <jeremy_just@netcourrier.com> wrote:
Le Sat, 6 May 2006 21:01:17 +0000 (UTC),
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.
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
Emmanuel Florac
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.
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.
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.
talon
Emmanuel Florac 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.
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.
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
Emmanuel Florac
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.
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.
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.
talon
Emmanuel Florac 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.
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.
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.
