Java Python

Vincent Bernat

09/01/2004 à 17:52

OoO Lors de la soirée naissante du vendredi 09 janvier 2004, vers
17:16, (Michel Talon) disait:

On parlait d'autre jour de la performance comparée de Java, Python C
etc. Voici un test, qui ne vaut peut être pas lourd, mais qui tend à
montrer que Java est capable de faire jeu égal avec C grace à
hotspot, que l'équivalent Microsoft C# fait à peu prés pareil, mais
que les langages purement interprétés (ici Python) ont des
performances dramatiquement plus mauvaises.

http://osnews.com/printer.php?news_idV02

Python n'est pas "fully interpreted". Bref, si l'auteur ne sait pas de
quoi il parle, cela commence très mal. Une différence importante entre
Python et les autres langages donnés est que Python dispose d'un
typage très faible et d'aucune déclaration de variables. On ne peut
donc pas allouer une place fixe à une variable, tout comme on doit à
tout moment vérifier le type de la variable.
--
BOFH excuse #251:
Processes running slowly due to weak power supply

Richard Delorme

09/01/2004 à 20:13

On parlait d'autre jour de la performance comparée de Java, Python
C etc. Voici un test, qui ne vaut peut être pas lourd, mais qui tend à
montrer que Java est capable de faire jeu égal avec C grace à hotspot,
que l'équivalent Microsoft C# fait à peu prés pareil, mais que les
langages purement interprétés (ici Python) ont des performances
dramatiquement plus mauvaises.
http://osnews.com/printer.php?news_idV02

Je n'aime pas trop ce test car trop éloigné de la vie réel : peu
d'appels de fonctions, peu d'allocation/désallocations dynamiques, et de
toutes ces choses qui désavantagent java au détriment du C ou du C++. Ce
qui m'étonne toujours aussi, c'est d'observer un facteur 2 de
performance en faveur de visual-c++ par rapport à java et d'en conclure
que c'est presque pareil, alors que les benchmarks sur le matériel
s'extasie sur des écarts de performances de 10% (qui se traduit par
d'énormes écarts de prix).
Néanmoins cet article a le mérite de fournir les tests, ce qui permet de
les vérifier sur sa machine linux.

Avec :

Options de compilation pour le C (avec gcc 3.3.1) :
-O3 -s -march=athlon-xp -mfpmath=sse -ffast-math -fomit-frame-pointer
Options de compilation pour Java (1.4.1 Black-down) : javac -g:none -O,
exécution avec java -server.

Matériel :
CPU athlon-xp 2000+
RAM 768 MB
Disque Maxtor 80GB/UDMA 100
OS : linux-gentoo (noyau 2.4.23)
Système de Fichier : Reiserfs

J'obtiens (en secondes) :

langage | int | long | double | trigo | I/O | total
-------------------------------------------------------
C 7.33 18.79 5.83 3.23 1.03 35.81
java 7.64 24.69 12.77 40.93 4.39 90.44

Chez moi, l'écart entre le C et java est encore plus grand que dans
l'article. J'ai comme un doute sur le résultat de gcc dans l'article,
mais bon. Java est lent. Point.

--
Richard

talon

09/01/2004 à 20:37

Richard Delorme wrote:

Système de Fichier : Reiserfs

J'obtiens (en secondes) :

langage | int | long | double | trigo | I/O | total
-------------------------------------------------------
C 7.33 18.79 5.83 3.23 1.03 35.81
java 7.64 24.69 12.77 40.93 4.39 90.44

Chez moi, l'écart entre le C et java est encore plus grand que dans
l'article. J'ai comme un doute sur le résultat de gcc dans l'article,
mais bon. Java est lent. Point.

Je suis d'accord avec tout ce que tu dis. En ce qui me concerne, ce qui
m'a le plus surpris, c'est que java fait presque aussi bien que C sur
le int. Il est notoire que java est trés mauvais en flottant, donc je ne
m'inquiète pas sur le trig. De toute façon qui est assez fêlé pour faire
du calcul scientifique en Java? Mais faire aussi bien que du C avec du
bytecode, ça c'est absolument époustouflant, ça en dit trés long sur
la puissance et la complexité de hotspot. Ce qui est aussi remarquable
c'est la comparaison avec ce que donne Python, c'est à dire non pas un
mais deux ordres de grandeur plus lent (c'est à dire 100 fois plus
lent). Je ne sais pas ce que voulait dire Vincent avec son histoire de
langage interprété, mais bon, Python, comme Perl, comme Ruby sont des
langages qui interprètent du bytecode et n'ont pas de compilateur
machine comme le hotspot, et le résultat, on le voit. Je veux bien
croire que sur un programme "réaliste" on n'observe pas des choses aussi
caricaturales, mais elles veulent quand même dire quelque chose.
En ce qui concerne la claque que prend gcc par rapport à Visual C++,
elle n'est pas trés significative à mon avis. Je doute fort que gcc
donne des résultats phénoménaux sous Windows, il est quand même surtout
testé sous Unix. En outre j'ai toujours entendu dire que les compilos de
Microsoft et d'Intel optimisaient beaucoup mieux que gcc, sauf les
versions les plus récentes de gcc et encore. Bon le résultat de tout ce
bins, à mon avis, c'est pas Java est lent, c'est au contraire Java est
extraordinairement rapide. Si tu prends en compte les garanties de
sécurité qu'il offre par le cloisonnement dans une machine virtuelle
(thème cher à M. L.), la simplicité qu'il a par rapport à une calamité
comme C++, ça fait beaucoup d'arguments positifs. Le fait qu'il dévore
la mémoire finira bien par devenir négligeable vu l'évolution de la
technologie. Evidemment même topo pour C#.

--

Michel TALON

Richard Delorme <abulmo@nospam.fr> wrote:

Système de Fichier : Reiserfs

J'obtiens (en secondes) :

langage | int | long | double | trigo | I/O | total
-------------------------------------------------------
C 7.33 18.79 5.83 3.23 1.03 35.81
java 7.64 24.69 12.77 40.93 4.39 90.44

Chez moi, l'écart entre le C et java est encore plus grand que dans
l'article. J'ai comme un doute sur le résultat de gcc dans l'article,
mais bon. Java est lent. Point.

Je suis d'accord avec tout ce que tu dis. En ce qui me concerne, ce qui
m'a le plus surpris, c'est que java fait presque aussi bien que C sur
le int. Il est notoire que java est trés mauvais en flottant, donc je ne
m'inquiète pas sur le trig. De toute façon qui est assez fêlé pour faire
du calcul scientifique en Java? Mais faire aussi bien que du C avec du
bytecode, ça c'est absolument époustouflant, ça en dit trés long sur
la puissance et la complexité de hotspot. Ce qui est aussi remarquable
c'est la comparaison avec ce que donne Python, c'est à dire non pas un
mais deux ordres de grandeur plus lent (c'est à dire 100 fois plus
lent). Je ne sais pas ce que voulait dire Vincent avec son histoire de
langage interprété, mais bon, Python, comme Perl, comme Ruby sont des
langages qui interprètent du bytecode et n'ont pas de compilateur
machine comme le hotspot, et le résultat, on le voit. Je veux bien
croire que sur un programme "réaliste" on n'observe pas des choses aussi
caricaturales, mais elles veulent quand même dire quelque chose.
En ce qui concerne la claque que prend gcc par rapport à Visual C++,
elle n'est pas trés significative à mon avis. Je doute fort que gcc
donne des résultats phénoménaux sous Windows, il est quand même surtout
testé sous Unix. En outre j'ai toujours entendu dire que les compilos de
Microsoft et d'Intel optimisaient beaucoup mieux que gcc, sauf les
versions les plus récentes de gcc et encore. Bon le résultat de tout ce
bins, à mon avis, c'est pas Java est lent, c'est au contraire Java est
extraordinairement rapide. Si tu prends en compte les garanties de
sécurité qu'il offre par le cloisonnement dans une machine virtuelle
(thème cher à M. L.), la simplicité qu'il a par rapport à une calamité
comme C++, ça fait beaucoup d'arguments positifs. Le fait qu'il dévore
la mémoire finira bien par devenir négligeable vu l'évolution de la
technologie. Evidemment même topo pour C#.

--

Michel TALON

Vous avez filtré cet utilisateur ! Consultez son message

Richard Delorme wrote:

Système de Fichier : Reiserfs

J'obtiens (en secondes) :

langage | int | long | double | trigo | I/O | total
-------------------------------------------------------
C 7.33 18.79 5.83 3.23 1.03 35.81
java 7.64 24.69 12.77 40.93 4.39 90.44

Chez moi, l'écart entre le C et java est encore plus grand que dans
l'article. J'ai comme un doute sur le résultat de gcc dans l'article,
mais bon. Java est lent. Point.

Je suis d'accord avec tout ce que tu dis. En ce qui me concerne, ce qui
m'a le plus surpris, c'est que java fait presque aussi bien que C sur
le int. Il est notoire que java est trés mauvais en flottant, donc je ne
m'inquiète pas sur le trig. De toute façon qui est assez fêlé pour faire
du calcul scientifique en Java? Mais faire aussi bien que du C avec du
bytecode, ça c'est absolument époustouflant, ça en dit trés long sur
la puissance et la complexité de hotspot. Ce qui est aussi remarquable
c'est la comparaison avec ce que donne Python, c'est à dire non pas un
mais deux ordres de grandeur plus lent (c'est à dire 100 fois plus
lent). Je ne sais pas ce que voulait dire Vincent avec son histoire de
langage interprété, mais bon, Python, comme Perl, comme Ruby sont des
langages qui interprètent du bytecode et n'ont pas de compilateur
machine comme le hotspot, et le résultat, on le voit. Je veux bien
croire que sur un programme "réaliste" on n'observe pas des choses aussi
caricaturales, mais elles veulent quand même dire quelque chose.
En ce qui concerne la claque que prend gcc par rapport à Visual C++,
elle n'est pas trés significative à mon avis. Je doute fort que gcc
donne des résultats phénoménaux sous Windows, il est quand même surtout
testé sous Unix. En outre j'ai toujours entendu dire que les compilos de
Microsoft et d'Intel optimisaient beaucoup mieux que gcc, sauf les
versions les plus récentes de gcc et encore. Bon le résultat de tout ce
bins, à mon avis, c'est pas Java est lent, c'est au contraire Java est
extraordinairement rapide. Si tu prends en compte les garanties de
sécurité qu'il offre par le cloisonnement dans une machine virtuelle
(thème cher à M. L.), la simplicité qu'il a par rapport à une calamité
comme C++, ça fait beaucoup d'arguments positifs. Le fait qu'il dévore
la mémoire finira bien par devenir négligeable vu l'évolution de la
technologie. Evidemment même topo pour C#.

--

Michel TALON

gutkneco+news

12/01/2004 à 09:04

Michel Talon wrote:

Je ne sais pas ce que voulait dire Vincent avec son histoire de
langage interprété, mais bon, Python, comme Perl, comme Ruby sont des
langages qui interprètent du bytecode et n'ont pas de compilateur
machine comme le hotspot, et le résultat, on le voit.

On voit aussi les perfs atteignables par un Python sur une VM 'moderne'
comme le CLR:
<http://primates.ximian.com/~miguel/archive/2003/Dec-09.html>

Prototype, pas significatif, etc etc.

Ol.
--
Olivier Gutknecht

gutkneco+news

12/01/2004 à 09:04

Richard Delorme wrote:

On parlait d'autre jour de la performance comparée de Java, Python
C etc. Voici un test, qui ne vaut peut être pas lourd, mais qui tend à
montrer que Java est capable de faire jeu égal avec C grace à hotspot,
que l'équivalent Microsoft C# fait à peu prés pareil, mais que les
langages purement interprétés (ici Python) ont des performances
dramatiquement plus mauvaises.
http://osnews.com/printer.php?news_idV02

Je n'aime pas trop ce test car trop éloigné de la vie réel : peu
d'appels de fonctions, peu d'allocation/désallocations dynamiques, et de
toutes ces choses qui désavantagent java au détriment du C ou du C++.

Entièrement d'accord. C'est un microbenchmark très peu représentatif,
hormis les opérations de base sur différents types.

Ce qui m'étonne toujours aussi, c'est d'observer un facteur 2 de
performance en faveur de visual-c++ par rapport à java et d'en conclure
que c'est presque pareil, alors que les benchmarks sur le matériel
s'extasie sur des écarts de performances de 10% (qui se traduit par
d'énormes écarts de prix).

Attention, là il faut nuancer: le seul point où Java se fait démolir
vraiment, c'est sur la trigo, qui n'est pas forcément comme disait
Michel un cas très représentatif dans les programmes réels. Si l'on
regarde le reste, on a une perf meilleure en math int que VC++, en gros
équivalente en I/O et double math, et très honorable en long math (moins
bien que vc++ et mieux que gcc). Le tout sur un processeur où la
génération de code de gcc est censée être la meilleure. Je trouve ça
très impressionnant pour Java 1.4.2, bien mieux que ce que à quoi je
m'attendais.

Options de compilation pour le C (avec gcc 3.3.1) :
-O3 -s -march=athlon-xp -mfpmath=sse -ffast-math -fomit-frame-pointer
Options de compilation pour Java (1.4.1 Black-down) : javac -g:none -O,
exécution avec java -server.

Matériel :
CPU athlon-xp 2000+
RAM 768 MB
Disque Maxtor 80GB/UDMA 100
OS : linux-gentoo (noyau 2.4.23)
Système de Fichier : Reiserfs

J'obtiens (en secondes) :

langage | int | long | double | trigo | I/O | total
-------------------------------------------------------
C 7.33 18.79 5.83 3.23 1.03 35.81
java 7.64 24.69 12.77 40.93 4.39 90.44

Un autre essai, qui donne des résultats proches, mais nettement moins
marqués:

Lang int double long trigo io total
C (xlc) 5.4 6.3 (58.5) 3.44 1.09 (74.73)
C (gcc) 5.63 10.00 9.870 3.49 1.120 30.1
Java 6.011 9.143 11.239 25.533 5.842 57

Darwin Kernel Version 7.2.0, PowerPC 970 2Ghz, 512 Mo.
java 1.4.1 en -client, javac en -g:none, -O
gcc en -O3 -march0 -mpowerpc64. Pas de fastmath, pas d'Altivec.
xlc en -O5 (testé en 5 minutes, pas cherché comment lui faire manger du
long long natif d'ou le mauvais résultat sur ce point). Le compilo est
beta sur cette plateforme.

A noter aussi qu'en java -server, les résultats étaient similaire sauf
sur le bench long, où l'on passait de 11.23 à 107.13 ! Comme quoi il y a
bien des choix d'optimisation très distincts entre Hotspot Client et
Server. D'autre part, l'implémentation de son test io en Java est
discutable vu qu'il n'utilise pas les nouvelles classes d'IO de Java
1.4, qui peuvent être nettement plus performantes.

Ol.
--
Olivier Gutknecht

Richard Delorme <abulmo@nospam.fr> wrote:

On parlait d'autre jour de la performance comparée de Java, Python
C etc. Voici un test, qui ne vaut peut être pas lourd, mais qui tend à
montrer que Java est capable de faire jeu égal avec C grace à hotspot,
que l'équivalent Microsoft C# fait à peu prés pareil, mais que les
langages purement interprétés (ici Python) ont des performances
dramatiquement plus mauvaises.
http://osnews.com/printer.php?news_idV02

Je n'aime pas trop ce test car trop éloigné de la vie réel : peu
d'appels de fonctions, peu d'allocation/désallocations dynamiques, et de
toutes ces choses qui désavantagent java au détriment du C ou du C++.

Entièrement d'accord. C'est un microbenchmark très peu représentatif,
hormis les opérations de base sur différents types.

Ce qui m'étonne toujours aussi, c'est d'observer un facteur 2 de
performance en faveur de visual-c++ par rapport à java et d'en conclure
que c'est presque pareil, alors que les benchmarks sur le matériel
s'extasie sur des écarts de performances de 10% (qui se traduit par
d'énormes écarts de prix).

Attention, là il faut nuancer: le seul point où Java se fait démolir
vraiment, c'est sur la trigo, qui n'est pas forcément comme disait
Michel un cas très représentatif dans les programmes réels. Si l'on
regarde le reste, on a une perf meilleure en math int que VC++, en gros
équivalente en I/O et double math, et très honorable en long math (moins
bien que vc++ et mieux que gcc). Le tout sur un processeur où la
génération de code de gcc est censée être la meilleure. Je trouve ça
très impressionnant pour Java 1.4.2, bien mieux que ce que à quoi je
m'attendais.

Options de compilation pour le C (avec gcc 3.3.1) :
-O3 -s -march=athlon-xp -mfpmath=sse -ffast-math -fomit-frame-pointer
Options de compilation pour Java (1.4.1 Black-down) : javac -g:none -O,
exécution avec java -server.

Matériel :
CPU athlon-xp 2000+
RAM 768 MB
Disque Maxtor 80GB/UDMA 100
OS : linux-gentoo (noyau 2.4.23)
Système de Fichier : Reiserfs

J'obtiens (en secondes) :

langage | int | long | double | trigo | I/O | total
-------------------------------------------------------
C 7.33 18.79 5.83 3.23 1.03 35.81
java 7.64 24.69 12.77 40.93 4.39 90.44

Un autre essai, qui donne des résultats proches, mais nettement moins
marqués:

Lang int double long trigo io total
C (xlc) 5.4 6.3 (58.5) 3.44 1.09 (74.73)
C (gcc) 5.63 10.00 9.870 3.49 1.120 30.1
Java 6.011 9.143 11.239 25.533 5.842 57

Darwin Kernel Version 7.2.0, PowerPC 970 2Ghz, 512 Mo.
java 1.4.1 en -client, javac en -g:none, -O
gcc en -O3 -march0 -mpowerpc64. Pas de fastmath, pas d'Altivec.
xlc en -O5 (testé en 5 minutes, pas cherché comment lui faire manger du
long long natif d'ou le mauvais résultat sur ce point). Le compilo est
beta sur cette plateforme.

A noter aussi qu'en java -server, les résultats étaient similaire sauf
sur le bench long, où l'on passait de 11.23 à 107.13 ! Comme quoi il y a
bien des choix d'optimisation très distincts entre Hotspot Client et
Server. D'autre part, l'implémentation de son test io en Java est
discutable vu qu'il n'utilise pas les nouvelles classes d'IO de Java
1.4, qui peuvent être nettement plus performantes.

Ol.
--
Olivier Gutknecht

Vous avez filtré cet utilisateur ! Consultez son message

Richard Delorme wrote:

On parlait d'autre jour de la performance comparée de Java, Python
C etc. Voici un test, qui ne vaut peut être pas lourd, mais qui tend à
montrer que Java est capable de faire jeu égal avec C grace à hotspot,
que l'équivalent Microsoft C# fait à peu prés pareil, mais que les
langages purement interprétés (ici Python) ont des performances
dramatiquement plus mauvaises.
http://osnews.com/printer.php?news_idV02

Je n'aime pas trop ce test car trop éloigné de la vie réel : peu
d'appels de fonctions, peu d'allocation/désallocations dynamiques, et de
toutes ces choses qui désavantagent java au détriment du C ou du C++.

Entièrement d'accord. C'est un microbenchmark très peu représentatif,
hormis les opérations de base sur différents types.

Ce qui m'étonne toujours aussi, c'est d'observer un facteur 2 de
performance en faveur de visual-c++ par rapport à java et d'en conclure
que c'est presque pareil, alors que les benchmarks sur le matériel
s'extasie sur des écarts de performances de 10% (qui se traduit par
d'énormes écarts de prix).

Attention, là il faut nuancer: le seul point où Java se fait démolir
vraiment, c'est sur la trigo, qui n'est pas forcément comme disait
Michel un cas très représentatif dans les programmes réels. Si l'on
regarde le reste, on a une perf meilleure en math int que VC++, en gros
équivalente en I/O et double math, et très honorable en long math (moins
bien que vc++ et mieux que gcc). Le tout sur un processeur où la
génération de code de gcc est censée être la meilleure. Je trouve ça
très impressionnant pour Java 1.4.2, bien mieux que ce que à quoi je
m'attendais.

Options de compilation pour le C (avec gcc 3.3.1) :
-O3 -s -march=athlon-xp -mfpmath=sse -ffast-math -fomit-frame-pointer
Options de compilation pour Java (1.4.1 Black-down) : javac -g:none -O,
exécution avec java -server.

Matériel :
CPU athlon-xp 2000+
RAM 768 MB
Disque Maxtor 80GB/UDMA 100
OS : linux-gentoo (noyau 2.4.23)
Système de Fichier : Reiserfs

J'obtiens (en secondes) :

langage | int | long | double | trigo | I/O | total
-------------------------------------------------------
C 7.33 18.79 5.83 3.23 1.03 35.81
java 7.64 24.69 12.77 40.93 4.39 90.44

Un autre essai, qui donne des résultats proches, mais nettement moins
marqués:

Lang int double long trigo io total
C (xlc) 5.4 6.3 (58.5) 3.44 1.09 (74.73)
C (gcc) 5.63 10.00 9.870 3.49 1.120 30.1
Java 6.011 9.143 11.239 25.533 5.842 57

Darwin Kernel Version 7.2.0, PowerPC 970 2Ghz, 512 Mo.
java 1.4.1 en -client, javac en -g:none, -O
gcc en -O3 -march0 -mpowerpc64. Pas de fastmath, pas d'Altivec.
xlc en -O5 (testé en 5 minutes, pas cherché comment lui faire manger du
long long natif d'ou le mauvais résultat sur ce point). Le compilo est
beta sur cette plateforme.

A noter aussi qu'en java -server, les résultats étaient similaire sauf
sur le bench long, où l'on passait de 11.23 à 107.13 ! Comme quoi il y a
bien des choix d'optimisation très distincts entre Hotspot Client et
Server. D'autre part, l'implémentation de son test io en Java est
discutable vu qu'il n'utilise pas les nouvelles classes d'IO de Java
1.4, qui peuvent être nettement plus performantes.

Ol.
--
Olivier Gutknecht

talon

15/01/2004 à 17:41

Richard Delorme wrote:

Options de compilation pour le C (avec gcc 3.3.1) :
-O3 -s -march=athlon-xp -mfpmath=sse -ffast-math -fomit-frame-pointer
Options de compilation pour Java (1.4.1 Black-down) : javac -g:none -O,
exécution avec java -server.

Matériel :
CPU athlon-xp 2000+
RAM 768 MB
Disque Maxtor 80GB/UDMA 100
OS : linux-gentoo (noyau 2.4.23)
Système de Fichier : Reiserfs

J'obtiens (en secondes) :

langage | int | long | double | trigo | I/O | total
-------------------------------------------------------
C 7.33 18.79 5.83 3.23 1.03 35.81
java 7.64 24.69 12.77 40.93 4.39 90.44

Chez moi, l'écart entre le C et java est encore plus grand que dans
l'article. J'ai comme un doute sur le résultat de gcc dans l'article,
mais bon. Java est lent. Point.

Par curiosité, j'ai compilé le Java 1.4.2 sous FreeBSD et j'ai fait le
test. Première impression tu as une machine *super* rapide. Chez moi
(Athlon-tbird 1.1 Ghz) on n'a pas de suite le résultat!
Bref pour moi, dans l'ordre int, double, long je trouve
C 10.9 9.4 29.3
java 13.3 22.5 170.7
Tu as bien vu, au niveau du long, j'ai un résultat catastrophiquement lent.
Je me suis dit que c'était peut être la version freebsd qui avait des
problèmes, donc j'ai pris la même version 1.4.2 du sdk chez Sun et je
l'ai mise sur mon Debian P4 3 Ghz (merci alien):
java 8.2 19.8 24.8

Les deux machines font tourner un calcul et donc java n'occupait que 80%
du processeur dans les deux cas.

Effectivement ceci montre que le HotSpot sur la version 1.4 sous FreeBSD
n'est pas encore au point. Ca montre aussi les performances lamentables
du P4 par rapport à l'Athlon, comme je le remarque souvent (cette
machine est toute récente, avec un P4 de technologie récente). Il n'y a
pas de pb mémoire, j'ai 1 Gig.

Enfin à titre de comparaison et par curiosité, voici le résultat,
toujours sur l'athlon 1.1 Ghz, mais avec un autre JIT, ici le
jdk-1.3.1 et OpenJIT:
java 16.9 18.7 48.4

Ainsi sauf sur le int, OpenJIT fait mieux que HotSpot et même bien
mieux sur le long. Etrange.
Evidemment, sans JIT, le temps tend vers l'infini, je n'ai pas la
patience d'attendre le résultat, et c'est pareil avec python.

Pour les ceux ici nombreux qui prétendent que les langages interprétés
(notamment perl) sont rapides, cette petite expérience est tout à fait
éclairante. Elle montre bien que sur un grand nombre d'itérations
faisant effectivement intervenir de l'interprétation de bytecode, le
résultat est calamiteux. Evidemment s'il n'y a que trés peu d'itérations
faisant en fait intervenir du code compilé (dans le cas d'espèce
l'exemple favori étant le moteur d'expressions régulières) on a
l'illusion que le langage interprété peut faire aussi bien ou mieux que
du C, mais c'est évidemment sans espoir. Un JIT permet de ne pas être
catastrophique, à condition qu'il soit bien programmé, ce qui est
apparemment d'un difficulté énorme.

--

Michel TALON

Richard Delorme <abulmo@nospam.fr> wrote:

Options de compilation pour le C (avec gcc 3.3.1) :
-O3 -s -march=athlon-xp -mfpmath=sse -ffast-math -fomit-frame-pointer
Options de compilation pour Java (1.4.1 Black-down) : javac -g:none -O,
exécution avec java -server.

Matériel :
CPU athlon-xp 2000+
RAM 768 MB
Disque Maxtor 80GB/UDMA 100
OS : linux-gentoo (noyau 2.4.23)
Système de Fichier : Reiserfs

J'obtiens (en secondes) :

langage | int | long | double | trigo | I/O | total
-------------------------------------------------------
C 7.33 18.79 5.83 3.23 1.03 35.81
java 7.64 24.69 12.77 40.93 4.39 90.44

Chez moi, l'écart entre le C et java est encore plus grand que dans
l'article. J'ai comme un doute sur le résultat de gcc dans l'article,
mais bon. Java est lent. Point.

Par curiosité, j'ai compilé le Java 1.4.2 sous FreeBSD et j'ai fait le
test. Première impression tu as une machine *super* rapide. Chez moi
(Athlon-tbird 1.1 Ghz) on n'a pas de suite le résultat!
Bref pour moi, dans l'ordre int, double, long je trouve
C 10.9 9.4 29.3
java 13.3 22.5 170.7
Tu as bien vu, au niveau du long, j'ai un résultat catastrophiquement lent.
Je me suis dit que c'était peut être la version freebsd qui avait des
problèmes, donc j'ai pris la même version 1.4.2 du sdk chez Sun et je
l'ai mise sur mon Debian P4 3 Ghz (merci alien):
java 8.2 19.8 24.8

Les deux machines font tourner un calcul et donc java n'occupait que 80%
du processeur dans les deux cas.

Effectivement ceci montre que le HotSpot sur la version 1.4 sous FreeBSD
n'est pas encore au point. Ca montre aussi les performances lamentables
du P4 par rapport à l'Athlon, comme je le remarque souvent (cette
machine est toute récente, avec un P4 de technologie récente). Il n'y a
pas de pb mémoire, j'ai 1 Gig.

Enfin à titre de comparaison et par curiosité, voici le résultat,
toujours sur l'athlon 1.1 Ghz, mais avec un autre JIT, ici le
jdk-1.3.1 et OpenJIT:
java 16.9 18.7 48.4

Ainsi sauf sur le int, OpenJIT fait mieux que HotSpot et même bien
mieux sur le long. Etrange.
Evidemment, sans JIT, le temps tend vers l'infini, je n'ai pas la
patience d'attendre le résultat, et c'est pareil avec python.

Pour les ceux ici nombreux qui prétendent que les langages interprétés
(notamment perl) sont rapides, cette petite expérience est tout à fait
éclairante. Elle montre bien que sur un grand nombre d'itérations
faisant effectivement intervenir de l'interprétation de bytecode, le
résultat est calamiteux. Evidemment s'il n'y a que trés peu d'itérations
faisant en fait intervenir du code compilé (dans le cas d'espèce
l'exemple favori étant le moteur d'expressions régulières) on a
l'illusion que le langage interprété peut faire aussi bien ou mieux que
du C, mais c'est évidemment sans espoir. Un JIT permet de ne pas être
catastrophique, à condition qu'il soit bien programmé, ce qui est
apparemment d'un difficulté énorme.

--

Michel TALON

Vous avez filtré cet utilisateur ! Consultez son message

Richard Delorme wrote:

Options de compilation pour le C (avec gcc 3.3.1) :
-O3 -s -march=athlon-xp -mfpmath=sse -ffast-math -fomit-frame-pointer
Options de compilation pour Java (1.4.1 Black-down) : javac -g:none -O,
exécution avec java -server.

Matériel :
CPU athlon-xp 2000+
RAM 768 MB
Disque Maxtor 80GB/UDMA 100
OS : linux-gentoo (noyau 2.4.23)
Système de Fichier : Reiserfs

J'obtiens (en secondes) :

langage | int | long | double | trigo | I/O | total
-------------------------------------------------------
C 7.33 18.79 5.83 3.23 1.03 35.81
java 7.64 24.69 12.77 40.93 4.39 90.44

Chez moi, l'écart entre le C et java est encore plus grand que dans
l'article. J'ai comme un doute sur le résultat de gcc dans l'article,
mais bon. Java est lent. Point.

Par curiosité, j'ai compilé le Java 1.4.2 sous FreeBSD et j'ai fait le
test. Première impression tu as une machine *super* rapide. Chez moi
(Athlon-tbird 1.1 Ghz) on n'a pas de suite le résultat!
Bref pour moi, dans l'ordre int, double, long je trouve
C 10.9 9.4 29.3
java 13.3 22.5 170.7
Tu as bien vu, au niveau du long, j'ai un résultat catastrophiquement lent.
Je me suis dit que c'était peut être la version freebsd qui avait des
problèmes, donc j'ai pris la même version 1.4.2 du sdk chez Sun et je
l'ai mise sur mon Debian P4 3 Ghz (merci alien):
java 8.2 19.8 24.8

Les deux machines font tourner un calcul et donc java n'occupait que 80%
du processeur dans les deux cas.

Effectivement ceci montre que le HotSpot sur la version 1.4 sous FreeBSD
n'est pas encore au point. Ca montre aussi les performances lamentables
du P4 par rapport à l'Athlon, comme je le remarque souvent (cette
machine est toute récente, avec un P4 de technologie récente). Il n'y a
pas de pb mémoire, j'ai 1 Gig.

Enfin à titre de comparaison et par curiosité, voici le résultat,
toujours sur l'athlon 1.1 Ghz, mais avec un autre JIT, ici le
jdk-1.3.1 et OpenJIT:
java 16.9 18.7 48.4

Ainsi sauf sur le int, OpenJIT fait mieux que HotSpot et même bien
mieux sur le long. Etrange.
Evidemment, sans JIT, le temps tend vers l'infini, je n'ai pas la
patience d'attendre le résultat, et c'est pareil avec python.

Pour les ceux ici nombreux qui prétendent que les langages interprétés
(notamment perl) sont rapides, cette petite expérience est tout à fait
éclairante. Elle montre bien que sur un grand nombre d'itérations
faisant effectivement intervenir de l'interprétation de bytecode, le
résultat est calamiteux. Evidemment s'il n'y a que trés peu d'itérations
faisant en fait intervenir du code compilé (dans le cas d'espèce
l'exemple favori étant le moteur d'expressions régulières) on a
l'illusion que le langage interprété peut faire aussi bien ou mieux que
du C, mais c'est évidemment sans espoir. Un JIT permet de ne pas être
catastrophique, à condition qu'il soit bien programmé, ce qui est
apparemment d'un difficulté énorme.

--

Michel TALON

Richard Delorme

15/01/2004 à 19:17

Richard Delorme wrote:

Options de compilation pour le C (avec gcc 3.3.1) :
-O3 -s -march=athlon-xp -mfpmath=sse -ffast-math -fomit-frame-pointer
Options de compilation pour Java (1.4.1 Black-down) : javac -g:none -O,
exécution avec java -server.

Matériel :
CPU athlon-xp 2000+
RAM 768 MB
Disque Maxtor 80GB/UDMA 100
OS : linux-gentoo (noyau 2.4.23)
Système de Fichier : Reiserfs

J'obtiens (en secondes) :

langage | int | long | double | trigo | I/O | total
-------------------------------------------------------
C 7.33 18.79 5.83 3.23 1.03 35.81
java 7.64 24.69 12.77 40.93 4.39 90.44

Chez moi, l'écart entre le C et java est encore plus grand que dans
l'article. J'ai comme un doute sur le résultat de gcc dans l'article,
mais bon. Java est lent. Point.

Par curiosité, j'ai compilé le Java 1.4.2 sous FreeBSD et j'ai fait le
test. Première impression tu as une machine *super* rapide.

J'espère bien, sa mise à jour l'an dernier m'a coûté au moins 200 euros...

Chez moi
(Athlon-tbird 1.1 Ghz) on n'a pas de suite le résultat!
Bref pour moi, dans l'ordre int, double, long je trouve
C 10.9 9.4 29.3
java 13.3 22.5 170.7
Tu as bien vu, au niveau du long, j'ai un résultat catastrophiquement lent.
Je me suis dit que c'était peut être la version freebsd qui avait des
problèmes, donc j'ai pris la même version 1.4.2 du sdk chez Sun et je
l'ai mise sur mon Debian P4 3 Ghz (merci alien):
java 8.2 19.8 24.8

Tu devrais aussi essayer gcc et icc (le compilo d'Intel) sur ton p4,
j'ai des doutes sur les facultés de gcc a bien optimiser pour lui (ou
alors les auteurs de l'article ont merdé), car chez moi gcc fait aussi
bien sous windows-XP ou linux, à des chouillas près, donc l'OS n'est pas
à mettre (trop) en cause.

Les deux machines font tourner un calcul et donc java n'occupait que 80%
du processeur dans les deux cas.

Attention, Java mesure le temps réels et non le temps CPU comme le C, la
comparaison est donc un poil biaisé.

Effectivement ceci montre que le HotSpot sur la version 1.4 sous FreeBSD
n'est pas encore au point. Ca montre aussi les performances lamentables
du P4 par rapport à l'Athlon, comme je le remarque souvent (cette
machine est toute récente, avec un P4 de technologie récente). Il n'y a
pas de pb mémoire, j'ai 1 Gig.

Aussi, j'aimerais bien voir les performance de l'athlon-64 (ou de
l'opteron). Normalement, il devrait être aussi rapide sur les longs que
que les entiers, et complètement ridiculiser ton P4 :-)

Enfin à titre de comparaison et par curiosité, voici le résultat,
toujours sur l'athlon 1.1 Ghz, mais avec un autre JIT, ici le
jdk-1.3.1 et OpenJIT:
java 16.9 18.7 48.4

Ainsi sauf sur le int, OpenJIT fait mieux que HotSpot et même bien
mieux sur le long. Etrange.
Evidemment, sans JIT, le temps tend vers l'infini, je n'ai pas la
patience d'attendre le résultat, et c'est pareil avec python.

Pour les ceux ici nombreux qui prétendent que les langages interprétés
(notamment perl) sont rapides, cette petite expérience est tout à fait
éclairante. Elle montre bien que sur un grand nombre d'itérations
faisant effectivement intervenir de l'interprétation de bytecode, le
résultat est calamiteux. Evidemment s'il n'y a que trés peu d'itérations
faisant en fait intervenir du code compilé (dans le cas d'espèce
l'exemple favori étant le moteur d'expressions régulières) on a
l'illusion que le langage interprété peut faire aussi bien ou mieux que
du C, mais c'est évidemment sans espoir. Un JIT permet de ne pas être
catastrophique, à condition qu'il soit bien programmé, ce qui est
apparemment d'un difficulté énorme.

Pour nuancer ce point de vue, j'ai rarement vue les défenseurs de Perl
ou de Python mettre en avant les performances. Ils sont plus là pour
concurrencer bash ou zsh que des langages comme java ou C. En plus, le
type long, en python, permet de faire du calcul sur plus de 64 bits, et
un benchmark la dessus n'est pas très fair-play.

--
Richard

Richard Delorme <abulmo@nospam.fr> wrote:

Options de compilation pour le C (avec gcc 3.3.1) :
-O3 -s -march=athlon-xp -mfpmath=sse -ffast-math -fomit-frame-pointer
Options de compilation pour Java (1.4.1 Black-down) : javac -g:none -O,
exécution avec java -server.

Matériel :
CPU athlon-xp 2000+
RAM 768 MB
Disque Maxtor 80GB/UDMA 100
OS : linux-gentoo (noyau 2.4.23)
Système de Fichier : Reiserfs

J'obtiens (en secondes) :

langage | int | long | double | trigo | I/O | total
-------------------------------------------------------
C 7.33 18.79 5.83 3.23 1.03 35.81
java 7.64 24.69 12.77 40.93 4.39 90.44

Chez moi, l'écart entre le C et java est encore plus grand que dans
l'article. J'ai comme un doute sur le résultat de gcc dans l'article,
mais bon. Java est lent. Point.

Par curiosité, j'ai compilé le Java 1.4.2 sous FreeBSD et j'ai fait le
test. Première impression tu as une machine *super* rapide.

J'espère bien, sa mise à jour l'an dernier m'a coûté au moins 200 euros...

Chez moi
(Athlon-tbird 1.1 Ghz) on n'a pas de suite le résultat!
Bref pour moi, dans l'ordre int, double, long je trouve
C 10.9 9.4 29.3
java 13.3 22.5 170.7
Tu as bien vu, au niveau du long, j'ai un résultat catastrophiquement lent.
Je me suis dit que c'était peut être la version freebsd qui avait des
problèmes, donc j'ai pris la même version 1.4.2 du sdk chez Sun et je
l'ai mise sur mon Debian P4 3 Ghz (merci alien):
java 8.2 19.8 24.8

Tu devrais aussi essayer gcc et icc (le compilo d'Intel) sur ton p4,
j'ai des doutes sur les facultés de gcc a bien optimiser pour lui (ou
alors les auteurs de l'article ont merdé), car chez moi gcc fait aussi
bien sous windows-XP ou linux, à des chouillas près, donc l'OS n'est pas
à mettre (trop) en cause.

Les deux machines font tourner un calcul et donc java n'occupait que 80%
du processeur dans les deux cas.

Attention, Java mesure le temps réels et non le temps CPU comme le C, la
comparaison est donc un poil biaisé.

Effectivement ceci montre que le HotSpot sur la version 1.4 sous FreeBSD
n'est pas encore au point. Ca montre aussi les performances lamentables
du P4 par rapport à l'Athlon, comme je le remarque souvent (cette
machine est toute récente, avec un P4 de technologie récente). Il n'y a
pas de pb mémoire, j'ai 1 Gig.

Aussi, j'aimerais bien voir les performance de l'athlon-64 (ou de
l'opteron). Normalement, il devrait être aussi rapide sur les longs que
que les entiers, et complètement ridiculiser ton P4 :-)

Enfin à titre de comparaison et par curiosité, voici le résultat,
toujours sur l'athlon 1.1 Ghz, mais avec un autre JIT, ici le
jdk-1.3.1 et OpenJIT:
java 16.9 18.7 48.4

Ainsi sauf sur le int, OpenJIT fait mieux que HotSpot et même bien
mieux sur le long. Etrange.
Evidemment, sans JIT, le temps tend vers l'infini, je n'ai pas la
patience d'attendre le résultat, et c'est pareil avec python.

Pour les ceux ici nombreux qui prétendent que les langages interprétés
(notamment perl) sont rapides, cette petite expérience est tout à fait
éclairante. Elle montre bien que sur un grand nombre d'itérations
faisant effectivement intervenir de l'interprétation de bytecode, le
résultat est calamiteux. Evidemment s'il n'y a que trés peu d'itérations
faisant en fait intervenir du code compilé (dans le cas d'espèce
l'exemple favori étant le moteur d'expressions régulières) on a
l'illusion que le langage interprété peut faire aussi bien ou mieux que
du C, mais c'est évidemment sans espoir. Un JIT permet de ne pas être
catastrophique, à condition qu'il soit bien programmé, ce qui est
apparemment d'un difficulté énorme.

Pour nuancer ce point de vue, j'ai rarement vue les défenseurs de Perl
ou de Python mettre en avant les performances. Ils sont plus là pour
concurrencer bash ou zsh que des langages comme java ou C. En plus, le
type long, en python, permet de faire du calcul sur plus de 64 bits, et
un benchmark la dessus n'est pas très fair-play.

--
Richard

Vous avez filtré cet utilisateur ! Consultez son message

Richard Delorme wrote:

Options de compilation pour le C (avec gcc 3.3.1) :
-O3 -s -march=athlon-xp -mfpmath=sse -ffast-math -fomit-frame-pointer
Options de compilation pour Java (1.4.1 Black-down) : javac -g:none -O,
exécution avec java -server.

Matériel :
CPU athlon-xp 2000+
RAM 768 MB
Disque Maxtor 80GB/UDMA 100
OS : linux-gentoo (noyau 2.4.23)
Système de Fichier : Reiserfs

J'obtiens (en secondes) :

langage | int | long | double | trigo | I/O | total
-------------------------------------------------------
C 7.33 18.79 5.83 3.23 1.03 35.81
java 7.64 24.69 12.77 40.93 4.39 90.44

Chez moi, l'écart entre le C et java est encore plus grand que dans
l'article. J'ai comme un doute sur le résultat de gcc dans l'article,
mais bon. Java est lent. Point.

Par curiosité, j'ai compilé le Java 1.4.2 sous FreeBSD et j'ai fait le
test. Première impression tu as une machine *super* rapide.

J'espère bien, sa mise à jour l'an dernier m'a coûté au moins 200 euros...

Chez moi
(Athlon-tbird 1.1 Ghz) on n'a pas de suite le résultat!
Bref pour moi, dans l'ordre int, double, long je trouve
C 10.9 9.4 29.3
java 13.3 22.5 170.7
Tu as bien vu, au niveau du long, j'ai un résultat catastrophiquement lent.
Je me suis dit que c'était peut être la version freebsd qui avait des
problèmes, donc j'ai pris la même version 1.4.2 du sdk chez Sun et je
l'ai mise sur mon Debian P4 3 Ghz (merci alien):
java 8.2 19.8 24.8

Tu devrais aussi essayer gcc et icc (le compilo d'Intel) sur ton p4,
j'ai des doutes sur les facultés de gcc a bien optimiser pour lui (ou
alors les auteurs de l'article ont merdé), car chez moi gcc fait aussi
bien sous windows-XP ou linux, à des chouillas près, donc l'OS n'est pas
à mettre (trop) en cause.

Les deux machines font tourner un calcul et donc java n'occupait que 80%
du processeur dans les deux cas.

Attention, Java mesure le temps réels et non le temps CPU comme le C, la
comparaison est donc un poil biaisé.

Effectivement ceci montre que le HotSpot sur la version 1.4 sous FreeBSD
n'est pas encore au point. Ca montre aussi les performances lamentables
du P4 par rapport à l'Athlon, comme je le remarque souvent (cette
machine est toute récente, avec un P4 de technologie récente). Il n'y a
pas de pb mémoire, j'ai 1 Gig.

Aussi, j'aimerais bien voir les performance de l'athlon-64 (ou de
l'opteron). Normalement, il devrait être aussi rapide sur les longs que
que les entiers, et complètement ridiculiser ton P4 :-)

Enfin à titre de comparaison et par curiosité, voici le résultat,
toujours sur l'athlon 1.1 Ghz, mais avec un autre JIT, ici le
jdk-1.3.1 et OpenJIT:
java 16.9 18.7 48.4

Ainsi sauf sur le int, OpenJIT fait mieux que HotSpot et même bien
mieux sur le long. Etrange.
Evidemment, sans JIT, le temps tend vers l'infini, je n'ai pas la
patience d'attendre le résultat, et c'est pareil avec python.

Pour les ceux ici nombreux qui prétendent que les langages interprétés
(notamment perl) sont rapides, cette petite expérience est tout à fait
éclairante. Elle montre bien que sur un grand nombre d'itérations
faisant effectivement intervenir de l'interprétation de bytecode, le
résultat est calamiteux. Evidemment s'il n'y a que trés peu d'itérations
faisant en fait intervenir du code compilé (dans le cas d'espèce
l'exemple favori étant le moteur d'expressions régulières) on a
l'illusion que le langage interprété peut faire aussi bien ou mieux que
du C, mais c'est évidemment sans espoir. Un JIT permet de ne pas être
catastrophique, à condition qu'il soit bien programmé, ce qui est
apparemment d'un difficulté énorme.

Pour nuancer ce point de vue, j'ai rarement vue les défenseurs de Perl
ou de Python mettre en avant les performances. Ils sont plus là pour
concurrencer bash ou zsh que des langages comme java ou C. En plus, le
type long, en python, permet de faire du calcul sur plus de 64 bits, et
un benchmark la dessus n'est pas très fair-play.

--
Richard

Stephane TOUGARD

17/01/2004 à 08:07

Richard Delorme wrote:

Pour nuancer ce point de vue, j'ai rarement vue les défenseurs de Perl
ou de Python mettre en avant les performances. Ils sont plus là pour
concurrencer bash ou zsh que des langages comme java ou C. En plus, le
type long, en python, permet de faire du calcul sur plus de 64 bits, et
un benchmark la dessus n'est pas très fair-play.

Pourtant, il est des points est aussi rapide que des programmes en C (un
test sed vs Perl avait ete fait ici meme).

Ceci dit, les performances d'un langage tel que Perl ou Python face a
Java ou au C ne sont pas a chercher au niveau des performances brutes,
mais plutot au niveau de la portabilite exceptionnelle et de la rapidite
de developpement qui sont, elles, sans communes mesures.

Ensuite, faire un developpement en 10 jours au lieu de 60 avec les memes
effectifs et payer 3 serveurs au lieu d'1 (ce sont des ordres de
grandeurs sortis de mon chapeau mais, d'experience, realistes), ca
parait pas un mauvais calcul, en tous cas, pas toujours.

--
http://www.unices.org

talon

17/01/2004 à 17:57

Stephane TOUGARD wrote:

Ceci dit, les performances d'un langage tel que Perl ou Python face a
Java ou au C ne sont pas a chercher au niveau des performances brutes,
mais plutot au niveau de la portabilite exceptionnelle et de la rapidite
de developpement qui sont, elles, sans communes mesures.

Là je pense que tout le monde est d'accord

--

Michel TALON

Sam Hocevar

17/01/2004 à 20:02

On Sat, 17 Jan 2004 16:57:21 +0000 (UTC), Michel Talon wrote:

Ceci dit, les performances d'un langage tel que Perl ou Python face a
Java ou au C ne sont pas a chercher au niveau des performances brutes,
mais plutot au niveau de la portabilite exceptionnelle et de la rapidite
de developpement qui sont, elles, sans communes mesures.

Là je pense que tout le monde est d'accord

Non ; comme déjà dit il y a quelques mois je ne suis pas d'accord. Je
conteste que le développement en Perl ou Python soit « sans commune
mesure » par rapport à Java. Idem pour la portabilité : ça dépend
vraiment des plateformes qu'on vise, de nombreux exemples ont été donnés
où développer en Perl n'était tout simplement pas possible (PalmOS et
SymbianOS entre autres).

Mais je suis bien d'accord que dans de nombreux cas il est bien plus
facile et rapide de résoudre un problème avec Perl ou Python ; en faire
une vérité générale est cependant malhonnête.

Sam.
--
Sam Hocevar <http://sam.zoy.org/>

Java Python

10 réponses

Veuillez sélectionner un problème