Juste pour rigoler, je viens de m'amuser à faire un tout petit test de mauvaise qualité.
C'est une fonction qui s'appelle récursivement 5000 fois (je voulais faire plus, mais java part très vite en stackoverflow). Pour bien voir la différence (et gommer le lancement de la jvm que tu dis négligeable mais qui fait que c'est 80 fois plus lent dans l'état), c'est appelé 655536 (oui il y a un 5 de trop) dans une boucle for.
En c, je trouve avec la magnifique et aléatoire commande time un temps de 25 secondes.
En java je trouve 1 minute 46. Et je pense que des boucles for et des appels de fonction, c'est un peu la base.
Donc là je vois que sur mon pc java est plus de 4 fois plus lent que du bon vieux C. Et encore, j'ai un x86, je sais pas si t'as déjà touché du java sur les macs power pc, mais c'est vraiment l'horreur (on dirait un facteur 10).
Ton test n'a aucune valeur. Tu testes quelque chose qui va contre le paradigme de Java. La JVM n'a pas la TCO (Tail-Call Optimisation) et c'est bien connu. La seule chose que ton test montre, c'est ta propre incompétence en Java et la démonstration que tu es plus que mal placé pour faire ce test.
Ensuite, tu crois vraiment que faire un appel N fois va changer quelque chose à l'ordre de grandeur qu'il existe entre l'appel d'une fonction et le lancement d'une VM ? Et la compilation JIT si jamais tu n'as lancé ton test qu'une fois ?
Pour faire le test de manière propre, il faudrait avoir déjà lancé la JVM en mode serveur, et il faudrait utiliser l'IDIOME du langage que tu utilises.
Enfin, comparer C et Java ça n'a aucun sens. Pourquoi ne compares-tu pas C à Python ou C à Ruby pour qu'on rie ?
Va voir http://kano.net/javabench/ pour une véritable comparaison de C++ et de Java par quelqu'un qui connaît les deux langages.
Je passe ensuite sur le ramasse miettes imposé qui je pense est une abbération totale pour des grosses applications (firefox en utilise un, bonjour le résultat... J'ai deux onglets, il me consomme 300Mio de mémoire vive). En C et C++, si on veut ne pas se fatiguer et devoir tout recoder car la concurrence gère mieux la mémoire (cas de firefox et webkit), c'est notre problème. En java, chaque grosse application ressemble à eclipse.
J'ai du mal à croire que tu aies déjà programmé un véritable système d'informations et que tu puisses dire ça.
La gestion manuelle de la mémoire est un bordel au niveau de la maintenance et de tout ce qui est partage de mémoire. Ton attribution du footprint de firefox au garbage collector est encore une fois un argument fallacieux. Essaie Firefox 3.5 (Shireteko) qui a toujours un garbage collector et un footprint moindre !
Même en C++, n'importe quelle application de taille raisonnable va utiliser une forme de gestion automatique de la mémoire, que ce soit les pointeurs managed en boost ou un garbage collector posé en ad-hock. La gestion manuelle de la mémoire, c'est la cause principale des leaks qui posent beaucoup plus de problème qu'un footprint plus important. En plus, le garbage collector d'HotSpot est super efficace.
Je dis pas qu'on peut pas écrire un logiciel complexe sans garbage collection, je dis que n'importe quel langage de haut niveau en a un pour de bonnes raisons. Ocaml n'est pas réputé pour sa lenteur, au contraire, et il utilise un garbage collector. Pareil pour Python, Ruby, etc.
Le problème d'Eclipse n'a rien à voir avec le garbage collector, c'est uniquement le fait qu'il est extensible et que tous les composants / plug-ins ne sont pas de même qualité.
Alors, tu avances la facilité de coder. C'est vrai que c'est plus facile de faire une fenêtre en java qu'une fenêtre en C et gtk.
Mais prenons les utilisations courantes du java:
IHM: C'est plus que moche si on utilise swing, et awt est plus vraiment utilisé. Ça me fait byzarre d'avoir une application toute moche en bleu clair que ce soit sur n'importe qu'elle système. Surtout avec un thème sombre...
Web: C'est comment s'embêter pour pas grand chose. Quand on a goûté à Ruby on rails (qui est très lent), ou même à un framework php, on voit pas trop l'intérêt d'utiliser java qui est une énorme usine à gaz.
Les applets: À la limite, je préfère un flash proprio qu'un applet java qui me fasse ramer.
IHM: N'importe quoi pour les IHM. J'aime pas Swing non plus (qui s'est beaucoup amélioré en perf et graphiquement), mais il est autant possible d'utiliser SWT qui fait l'abstraction sur la bibliothèque graphique native, GTK sous GNU/Linux ou Solaris. Et (comme je l'avais dit, mais clairement tu ne m'as pas véritablement lu), il existe des bindings GTK/Gnome et même Qt (Jambi). Encore une fois, t'es resté sur des constatations d'il y a dix ans.
Web: Il y a des dizaines de frameworks en Java ou pour la JVM. Il y a aussi énormément d'intérets pour ces frameworks. Pourquoi Apache fait à 90% du Java selon toi?
RoR tourne plus rapidement sous JRuby.
Et il y a encore mieux, il y a Lift en Scala qui fournit la même avancée par rapport à RoR, que RoR fournissait par rapport au reste il y a quelques années.
Encore une fois ton rejet simple et direct du monde Java te fait passer à la trappe des alternatives plus intéressantes.
Enfin, les applets, personne ne les utilise plus, alors je vois même pas ce que ça vient faire ici.
Pour la rapidité de coder, je pense que tu veut parler des librairies, car «System.out.println» c'est sympa deux heures. C++ et Qt n'a rien de plus lent à coder que java. En plus la doc est mieux faite.
Clairement, tu n'as jamais utilisé un framework Java style OSGi ou Spring, car les équivalents n'existent pas en C++ (pour de bonnes raisons, vu que la réflexivité avec le RTTI est limitée en C++).
Et tu as encore moins utilisé Scala ou Clojure.
Tu bases tous tes arguments sur Java, le langage, alors que je parlais explicitement de Java, la plateforme.
Donc non, les développeurs kikoo lols qui veulent coder vite et mal en passant sur la conception, moi je veut bien qu'ils s'abandonnent à mono. Les vrais professionnels qui font des applications lourdes et utilisées, je préférerais qu'ils oublient les machines virtuelles.
Tout ce que je vois ici c'est que tu n'as aucune idée du monde de l'informatique professionnelle et des réalités des systèmes complexes. On a besoin de langages plus expressifs qui offrent des garanties sur l'exécution, la maintenabilité, etc.
On a des ordinateurs plus puissants, et même si c'est pas une raison d'oublier la performance, on ne va pas faire de l'assembleur parce que c'est "plus performant". Le C/C++ sont utiles pour la programmation système. Pour tout le reste, il y a... la JVM Mastercard.
Car les machines virtuelles pour des applications de bureau, c'est quoi l'intérêt ? Ne pas devoir compiler pour chaque architecture ? C'est tout ? C'est trop compliqué de fournir du x86, du x86_64 bits et les sources (ça suffit maintenant que apple ne vends plus des ordinateurs de qualité) ? Quand je pense aux nombreux problèmes que j'ai eu entre la jvm de sun et celle qui est libre...
L'intérêt c'est que le développeur qui fait une appli pour Windows, tu utilises son appli sous Linux. L'intérêt c'est qu'il n'utilise pas une lib specific Cocoa ou Win32.
L'intérêt c'est que ton application elle fait partie d'un écosystème et utilise des bibliothèques qui ont d'autres cas d'utilisation, par exemple elles peuvent être utilisées en cluster avec Terracotta... sans modifier leur code.
Enfin bon, voila quoi. Java c'est bien pour coder rapidement une petite application. Mais c'est un peu le chaînon inutile entre les langages interprétés pour les scripts et petites applications (quoique les GUI en python ça me gonfle), et les langages compilés.
Java est compilé 'just in time'. Tu demandes quoi de plus ?
Il existe des langages de scripts pour la JVM très performant, pourquoi ne pas utiliser la JVM comme VM générique plutôt que des interpréteurs inefficaces ?
Mon troll java n'est pas près de mourir pour moi :-)
Je vois ça ; je pense que tu devrais baser tes opinions sur des faits et sur l'expérience de l'industrie. Car à t'entendre, tout le monde doit être très con, aussi bien dans l'industrie que dans la recherche, d'utiliser des langages sur des VMs avec garbage collector. D'utiliser des langages fonctionnels plutôt que C ou C++...
[^] # Re: Ça passe très bien :)
Posté par smc . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 10.
C'est une fonction qui s'appelle récursivement 5000 fois (je voulais faire plus, mais java part très vite en stackoverflow). Pour bien voir la différence (et gommer le lancement de la jvm que tu dis négligeable mais qui fait que c'est 80 fois plus lent dans l'état), c'est appelé 655536 (oui il y a un 5 de trop) dans une boucle for.
En c, je trouve avec la magnifique et aléatoire commande time un temps de 25 secondes.
En java je trouve 1 minute 46. Et je pense que des boucles for et des appels de fonction, c'est un peu la base.
Donc là je vois que sur mon pc java est plus de 4 fois plus lent que du bon vieux C. Et encore, j'ai un x86, je sais pas si t'as déjà touché du java sur les macs power pc, mais c'est vraiment l'horreur (on dirait un facteur 10).
Ton test n'a aucune valeur. Tu testes quelque chose qui va contre le paradigme de Java. La JVM n'a pas la TCO (Tail-Call Optimisation) et c'est bien connu. La seule chose que ton test montre, c'est ta propre incompétence en Java et la démonstration que tu es plus que mal placé pour faire ce test.
Ensuite, tu crois vraiment que faire un appel N fois va changer quelque chose à l'ordre de grandeur qu'il existe entre l'appel d'une fonction et le lancement d'une VM ? Et la compilation JIT si jamais tu n'as lancé ton test qu'une fois ?
Pour faire le test de manière propre, il faudrait avoir déjà lancé la JVM en mode serveur, et il faudrait utiliser l'IDIOME du langage que tu utilises.
Enfin, comparer C et Java ça n'a aucun sens. Pourquoi ne compares-tu pas C à Python ou C à Ruby pour qu'on rie ?
Va voir http://kano.net/javabench/ pour une véritable comparaison de C++ et de Java par quelqu'un qui connaît les deux langages.
Je passe ensuite sur le ramasse miettes imposé qui je pense est une abbération totale pour des grosses applications (firefox en utilise un, bonjour le résultat... J'ai deux onglets, il me consomme 300Mio de mémoire vive). En C et C++, si on veut ne pas se fatiguer et devoir tout recoder car la concurrence gère mieux la mémoire (cas de firefox et webkit), c'est notre problème. En java, chaque grosse application ressemble à eclipse.
J'ai du mal à croire que tu aies déjà programmé un véritable système d'informations et que tu puisses dire ça.
La gestion manuelle de la mémoire est un bordel au niveau de la maintenance et de tout ce qui est partage de mémoire. Ton attribution du footprint de firefox au garbage collector est encore une fois un argument fallacieux. Essaie Firefox 3.5 (Shireteko) qui a toujours un garbage collector et un footprint moindre !
Même en C++, n'importe quelle application de taille raisonnable va utiliser une forme de gestion automatique de la mémoire, que ce soit les pointeurs managed en boost ou un garbage collector posé en ad-hock. La gestion manuelle de la mémoire, c'est la cause principale des leaks qui posent beaucoup plus de problème qu'un footprint plus important. En plus, le garbage collector d'HotSpot est super efficace.
Je dis pas qu'on peut pas écrire un logiciel complexe sans garbage collection, je dis que n'importe quel langage de haut niveau en a un pour de bonnes raisons. Ocaml n'est pas réputé pour sa lenteur, au contraire, et il utilise un garbage collector. Pareil pour Python, Ruby, etc.
Le problème d'Eclipse n'a rien à voir avec le garbage collector, c'est uniquement le fait qu'il est extensible et que tous les composants / plug-ins ne sont pas de même qualité.
Alors, tu avances la facilité de coder. C'est vrai que c'est plus facile de faire une fenêtre en java qu'une fenêtre en C et gtk.
Mais prenons les utilisations courantes du java:
IHM: C'est plus que moche si on utilise swing, et awt est plus vraiment utilisé. Ça me fait byzarre d'avoir une application toute moche en bleu clair que ce soit sur n'importe qu'elle système. Surtout avec un thème sombre...
Web: C'est comment s'embêter pour pas grand chose. Quand on a goûté à Ruby on rails (qui est très lent), ou même à un framework php, on voit pas trop l'intérêt d'utiliser java qui est une énorme usine à gaz.
Les applets: À la limite, je préfère un flash proprio qu'un applet java qui me fasse ramer.
IHM: N'importe quoi pour les IHM. J'aime pas Swing non plus (qui s'est beaucoup amélioré en perf et graphiquement), mais il est autant possible d'utiliser SWT qui fait l'abstraction sur la bibliothèque graphique native, GTK sous GNU/Linux ou Solaris. Et (comme je l'avais dit, mais clairement tu ne m'as pas véritablement lu), il existe des bindings GTK/Gnome et même Qt (Jambi). Encore une fois, t'es resté sur des constatations d'il y a dix ans.
Web: Il y a des dizaines de frameworks en Java ou pour la JVM. Il y a aussi énormément d'intérets pour ces frameworks. Pourquoi Apache fait à 90% du Java selon toi?
RoR tourne plus rapidement sous JRuby.
Et il y a encore mieux, il y a Lift en Scala qui fournit la même avancée par rapport à RoR, que RoR fournissait par rapport au reste il y a quelques années.
Encore une fois ton rejet simple et direct du monde Java te fait passer à la trappe des alternatives plus intéressantes.
Enfin, les applets, personne ne les utilise plus, alors je vois même pas ce que ça vient faire ici.
Pour la rapidité de coder, je pense que tu veut parler des librairies, car «System.out.println» c'est sympa deux heures. C++ et Qt n'a rien de plus lent à coder que java. En plus la doc est mieux faite.
Clairement, tu n'as jamais utilisé un framework Java style OSGi ou Spring, car les équivalents n'existent pas en C++ (pour de bonnes raisons, vu que la réflexivité avec le RTTI est limitée en C++).
Et tu as encore moins utilisé Scala ou Clojure.
Tu bases tous tes arguments sur Java, le langage, alors que je parlais explicitement de Java, la plateforme.
Donc non, les développeurs kikoo lols qui veulent coder vite et mal en passant sur la conception, moi je veut bien qu'ils s'abandonnent à mono. Les vrais professionnels qui font des applications lourdes et utilisées, je préférerais qu'ils oublient les machines virtuelles.
Tout ce que je vois ici c'est que tu n'as aucune idée du monde de l'informatique professionnelle et des réalités des systèmes complexes. On a besoin de langages plus expressifs qui offrent des garanties sur l'exécution, la maintenabilité, etc.
On a des ordinateurs plus puissants, et même si c'est pas une raison d'oublier la performance, on ne va pas faire de l'assembleur parce que c'est "plus performant". Le C/C++ sont utiles pour la programmation système. Pour tout le reste, il y a... la JVM Mastercard.
Car les machines virtuelles pour des applications de bureau, c'est quoi l'intérêt ? Ne pas devoir compiler pour chaque architecture ? C'est tout ? C'est trop compliqué de fournir du x86, du x86_64 bits et les sources (ça suffit maintenant que apple ne vends plus des ordinateurs de qualité) ? Quand je pense aux nombreux problèmes que j'ai eu entre la jvm de sun et celle qui est libre...
L'intérêt c'est que le développeur qui fait une appli pour Windows, tu utilises son appli sous Linux. L'intérêt c'est qu'il n'utilise pas une lib specific Cocoa ou Win32.
L'intérêt c'est que ton application elle fait partie d'un écosystème et utilise des bibliothèques qui ont d'autres cas d'utilisation, par exemple elles peuvent être utilisées en cluster avec Terracotta... sans modifier leur code.
Enfin bon, voila quoi. Java c'est bien pour coder rapidement une petite application. Mais c'est un peu le chaînon inutile entre les langages interprétés pour les scripts et petites applications (quoique les GUI en python ça me gonfle), et les langages compilés.
Java est compilé 'just in time'. Tu demandes quoi de plus ?
Il existe des langages de scripts pour la JVM très performant, pourquoi ne pas utiliser la JVM comme VM générique plutôt que des interpréteurs inefficaces ?
Mon troll java n'est pas près de mourir pour moi :-)
Je vois ça ; je pense que tu devrais baser tes opinions sur des faits et sur l'expérience de l'industrie. Car à t'entendre, tout le monde doit être très con, aussi bien dans l'industrie que dans la recherche, d'utiliser des langages sur des VMs avec garbage collector. D'utiliser des langages fonctionnels plutôt que C ou C++...