C et Java

"charly" <spam@yahoo.fr> a écrit dans le message de
news:4004094c$0$17141$626a54ce@news.free.fr...

Le gain de performance est-il suffisament élevé pour être réellement
interessant ?

Ben oui, c'est une des raisons pour laquelle le C est encore utilisé
dans certaines applications (OS, calcul scientifique...).

Se "débarasser" de la portabilité de Java, c'est effectivement nier un
des principes de java ( à mon humble avis) mais si l'accroissement en
performance en vaut la peine...

Sinon, juste comme ça, la portabilité n'est sans doute pas ce qui distingue
le plus Java et C...

charly wrote:

Bonjour,

une petite question me trotte dans la tete.

Soient les éléments suivants :

- Certaines choses sont réputées être leeeentes en Java (je ne parle pas
d'affichage graphique) par rapport à C ou c++.

- Un des impératifs de Java est la portabilité : soit.

Mnt, supposons que je veuille développer une appli pour une plateforme
spécifique et que la portabilité, peu me chaud :)

C'est une mauvaise supposition à mon avis. Un jour ou l'autre il sera
peut-être nécessaire de "porter" l'appli sur une autre plateforme.

Je développe certaines fonctionnalités, en C par exemple car présupposé
+ rapide (j'ai dit "présupposé" pas "est" :) ), et les rend accessible à
mon appli Java via JNI (je crois que c'est çà mais pas sûr, mais je sais
que le principe existe :) ).

Ouai mais il faut faire gaffe. Passer par JNI a un cout aussi. Donc
appeler une méthode native pour faire a+b n'est pas une bonne idée, ce
sera plus long que de le faire directement en Java

Maintenant, je compile le tout et j'obtiens un fichier exécutable que
sur linux ou que sur Windows, par ex. (pas portable).

Non. Tu obtiens des fichiers .class pour la partie Java et une librairie
dynamique pour la partie C/C++

La question maintenant :) :

Le gain de performance est-il suffisament élevé pour être réellement
interessant ?

Oui pour certains trucs. Mais c'est surtout intéressant pour pouvoir
faire des choses qu'on ne peut pas faire directement en Java ou accéder
à des dll déjà existantes et qu'on ne veut/peut pas redévelopper en Java.

Se "débarasser" de la portabilité de Java, c'est effectivement nier un
des principes de java ( à mon humble avis) mais si l'accroissement en
performance en vaut la peine...

On n'a parfois pas le choix et C/C++ est portable avec un peu d'effort.

Vos avis ?

A éviter quand on peut. Le gain en vitesse n'est généralement pas une
bonne raison.

PS : c'est une question ouverte, pas un troll :) (genre C, ca va plus
vite que Java, gna gna...)

Un lien très intéressant concernant l'interfacage C++/Java :
http://sourceforge.net/projects/jace/

J'ai testé et c'est véritablement impressionnant. JNI est difficile à
utiliser, Jace est un véritable plaisir.

Cédric

Bonsoir,

Pour rappel Java n'est pas lent intrinsequement,
Ce qui est lent (traduction prend du temps), c'est le démarage de la VM
(multipass verifier, bytecode checker, dependency graph...). Or sur une
application graphique une fenetre n'apparait qu'une fois la VM chargée !!!

Pour vous en convaincre définitivement :
http://www.osnews.com/story.php?news_idV02

Et encore, il a été prouvé par d'autre bench plus poussé que dans de
plus en plus de cas Java est plus rapide que le C.

Le secret est simple, l'optimisation n'est pas fait à la compil, mais à
l'exécution au dernier moment là ou il y a plus d'information sur le
contexte d'appel, et donc un meilleur ratio de gain de performance.
C'est l'une des découvertes des technologies JIT. Là ou c'est tout
benef, c'est que plus du code est utilisé plus il est optimisé (JIT
adaptatif).

Coté graphique, toute personne ayant travaillé avec le pipe Java2D ou
travaillé avec des composant type JLoox, te diras que Java est superieur
en perf à ce niveau (pas de mérite car les primitives de base sont
délégés a l'OS ...).

Quand au lancement de la VM, le seul vrai moment on l'ont peut encore
dire "Java est lent", on attent avec impatience la Shared VM dans le
1.5, voir les fils sur le JL pour plus d'infos...


En clair, aurais poser la question en 97 on t'aurais dit effectivement
que C + Java avec JNI, est peut-être une solution.

Mais aujourd'hui, franchement compte tenue des perf, je vois trés peu de
raison de faire un appli mixte.

Et puis, si t'as besoin de faire un serveur de calcul, alors des techno
style Javaspace seront netement plus interessante en terme d'archi, car
tu pourra faire du calcul massivement parralelle sans difficulté....


Au passage pour les auteurs de la FAQ: Vu le nombre de post qui traite
du sujet de la "rapidité" de Java, ça serait bien que la FAQ Java traite
du sujet on éviterer les préjugés et les clichés ;-)


A+, et bon codage à toi !
TM

charly wrote:

Bonjour,

une petite question me trotte dans la tete.

Soient les éléments suivants :

- Certaines choses sont réputées être leeeentes en Java (je ne parle pas
d'affichage graphique) par rapport à C ou c++.

- Un des impératifs de Java est la portabilité : soit.

Mnt, supposons que je veuille développer une appli pour une plateforme
spécifique et que la portabilité, peu me chaud :)

Je développe certaines fonctionnalités, en C par exemple car présupposé
+ rapide (j'ai dit "présupposé" pas "est" :) ), et les rend accessible à
mon appli Java via JNI (je crois que c'est çà mais pas sûr, mais je sais
que le principe existe :) ).

Maintenant, je compile le tout et j'obtiens un fichier exécutable que
sur linux ou que sur Windows, par ex. (pas portable).

La question maintenant :) :

Le gain de performance est-il suffisament élevé pour être réellement
interessant ?

Se "débarasser" de la portabilité de Java, c'est effectivement nier un
des principes de java ( à mon humble avis) mais si l'accroissement en
performance en vaut la peine...


Vos avis ?

PS : c'est une question ouverte, pas un troll :) (genre C, ca va plus
vite que Java, gna gna...)

Bonsoir,

Pour rappel Java n'est pas lent intrinsequement,
Ce qui est lent (traduction prend du temps), c'est le démarage de la VM
(multipass verifier, bytecode checker, dependency graph...). Or sur une
application graphique une fenetre n'apparait qu'une fois la VM chargée !!!

Pour vous en convaincre définitivement :
http://www.osnews.com/story.php?news_idV02

J'aime bien tout ces tests qui montrent que java est deux fois plus lent
que C et dont on conclût que java est plus rapide que le C.

Et encore, il a été prouvé par d'autre bench plus poussé que dans de
plus en plus de cas Java est plus rapide que le C.

Quels benchs ?

--
Richard

Richard Delorme <abulmo@nospam.fr> wrote in message news:<40047b6d$0$6967$7a628cd7@news.club-internet.fr>...

Bonsoir,

Pour rappel Java n'est pas lent intrinsequement,
Ce qui est lent (traduction prend du temps), c'est le démarage de la VM
(multipass verifier, bytecode checker, dependency graph...). Or sur une
application graphique une fenetre n'apparait qu'une fois la VM chargée !!!

Pour vous en convaincre définitivement :
http://www.osnews.com/story.php?news_idV02

J'aime bien tout ces tests qui montrent que java est deux fois plus lent
que C et dont on conclût que java est plus rapide que le C.
Si tu lis seulement le total c'est effectivement vrai. Le problème

c'est que la différence ce fait uniquement sur le test en "64-bit
floating point trigonometry"

(Au passage, quelqu'un sait de quoi il retourne? Pourquoi c'est 2.6
fois plus lent que dans la verion 1.3.1?)

Si on fait sauter ce point on obtient:
1> Visual C++ : 45.3
2> java 1.4.2 : 46.1
3> gcc C : 58.1

Autrement dit, hors "64-bit floating point trigonometry", ça se tient
entre Java, VC++, et C (même si il est légèrement en retrait). Après
ça dépend de ce dont on a besoin. On sait déjà que si on veut faire
des calculs en "64-bit floating point trigonometry" il faut oublier
java. De même que hors windows il faut oublier VC++... Après c'est des
pouillèmes qui rentrent en jeux.

Ceci étant dit ce genre de benchs ne vaut que pour les applis de
calculs (sauf pour les IO), ça ne donne pas vraiment d'indication pour
d'autres applis qui passent finalement plus de temps à faire des
recherches dans des structures de donnée & cie...

Il faudrait donner un sujet à 2 groupes d'excellents développeurs, un
c++ l'autre java, et voir en un temps donné le résultat... En répètant
plusieurs fois l'expérience on pourrait peut-être se faire une idée
des possibilité réelles...

Merci pour vos infos, le bench était très interessant.

Pour l'intéret des DLL et pour des parties critiques à faire en C, il
est utile d'avoir des infos autres que des légendes et autres trolls que
l'on trouve sur des forums...

Remarque, il est dommage que ces infos ne soient pas plus "publiques"
afin de briser certaines idées reçues...

Merci encore

Richard Delorme <abulmo@nospam.fr> wrote in message news:<40047b6d$0$6967$7a628cd7@news.club-internet.fr>...

Bonsoir,

Pour rappel Java n'est pas lent intrinsequement,
Ce qui est lent (traduction prend du temps), c'est le démarage de la VM
(multipass verifier, bytecode checker, dependency graph...). Or sur une
application graphique une fenetre n'apparait qu'une fois la VM chargée !!!

Pour vous en convaincre définitivement :
http://www.osnews.com/story.php?news_idV02

J'aime bien tout ces tests qui montrent que java est deux fois plus lent
que C et dont on conclût que java est plus rapide que le C.

Si tu lis seulement le total c'est effectivement vrai. Le problème
c'est que la différence ce fait uniquement sur le test en "64-bit
floating point trigonometry"

(Au passage, quelqu'un sait de quoi il retourne? Pourquoi c'est 2.6
fois plus lent que dans la verion 1.3.1?)

Si on fait sauter ce point on obtient:
1> Visual C++ : 45.3
2> java 1.4.2 : 46.1
3> gcc C : 58.1

J'ajoute java 1.3.1 :
4> java 1.3.1 : 75.5

Et je me permets de douter très sérieusement du résultat affiché pour
gcc. Un bon point du test est que les sources sont fournis, j'ai donc pu
refaire ça chez moi sur une configuration différente, mais de puissance
comparable, avec des résultats différents :

Options de compilation pour le C (avec gcc 3.3.1) :
-O3 -s -march=athlon-xp -mfpmath=sse -ffast-math -fomit-frame-pointer
-funroll-loops -funroll-all-loops -ftracer
Options de compilation pour Java (1.4.2 Sun) : 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.24) et Windows-XP
Système de Fichier : Reiserfs (linux) et ntfs (windows)

J'obtiens (en secondes) :

OS | langage | int | long | double | trigo | I/O | total
-------------------------------------------------------
linux | gcc 7.2 18.7 3.4 3.2 1.1 33.6
linux | java-sun 7.7 26.4 12.4 85.2 5.0 136.7
winXP | gcc 7.2 18.3 3.4 5.6 3.6 38.1
winXP | java-sun 7.6 17.3 15.6 45.3 7.3 89.9

J'ai les mêmes versions de gcc et de java que pour le test d'osnews,
mais pas les mêmes résultats. Java est proche de gcc pour les calculs
avec les entiers et est plus lent pour le reste (flottants & I/O). gcc
est beaucoup plus rapide chez moi que dans l'article au point que je
soupçonne une erreur quelque part.

Ceci étant dit ce genre de benchs ne vaut que pour les applis de
calculs (sauf pour les IO), ça ne donne pas vraiment d'indication pour
d'autres applis qui passent finalement plus de temps à faire des
recherches dans des structures de donnée & cie...

Je suis d'accord que ce test n'est pas représentatif des vraies
applications. Même pour un test sur les opérations de base, il manque
l'utilisation d'objets et de toute ces choses que l'on trouve dans les
vrais programmes.

Il faudrait donner un sujet à 2 groupes d'excellents développeurs, un
c++ l'autre java, et voir en un temps donné le résultat... En répètant
plusieurs fois l'expérience on pourrait peut-être se faire une idée
des possibilité réelles...

Il faudrait une vraie application, qui essaie de résoudre un problème
quelconque, assez simple pour y voir de nombreux aspects du langage mais
pas trop pour ne pas mettre en avant l'habileté des programmeurs. Si
quelqu'un a une idée ?

--
Richard