Le développement de Jython s'était essoufflé fin 2004 avec le départ du développeur le plus actif, Samuele Pedroni, qui s'est consacré à PyPy (implémentation de Python, écrite en Python). Jython était alors figé sur Python 2.2. En mars 2008, le projet est relancé par SUN (éditeur du langage Java) qui embauche Ted Leung et Frank Wierzbicki pour développer Jython. Jython 2.5 est le fruit de ce travail.
La 2e partie de cette dépêche contient d'autres brèves Python : vidéos de Pycon FR, Python 3.1, compilateur à la volée PyPy et EuroPython. Autres brèves du monde Python :
Les diaporamas des conférences de Pycon FR 2009 sont maintenant disponibles en ligne, et les vidéos des conférences arrivent au compte goutte.
La version finale de Python 3.1 est prévue pour le 27 juin prochain, et Python 3.1 RC2 est sorti le 13 juin dernier. Voir les nouveautés de Python 3.1. Cette version est le signe de la maturation de la branche 3.x. Elle corrige les défauts de jeunesse de Python 3.0 et retrouve la vitalité (performances) de Python 2.x, grâce à une réécriture de la bibliothèque d'entrée/sortie (io) en C et des optimisations sur les codecs texte les plus courants (ISO-8859-1, UTF-8 et UTF-16).
Pendant ce temps, le compilateur à la volée (JIT) de PyPy progresse doucement mais sûrement. Vous pouvez en suivre les évolutions sur le blog de PyPy.
Pour rappel, la semaine prochaine débutera à Birmingham en Angleterre, EuroPython 2009. Le programme des conférences est déjà consultable en ligne. Relire la dépêche LinuxFr sur EuroPython 2009.
Aller plus loin
- Site officiel de Jython (67 clics)
- Wiki de Jython (23 clics)
- Nouveautés de Jython 2.5 (Roadmap Jython) (14 clics)
- Article Wikipédia anglophone sur Jython (5 clics)
- Site de Python (4 clics)
- PyPy (11 clics)
# Ah ah ! Trop gros ça ne passera pas !
Posté par Mr Kapouik (site web personnel) . Évalué à -2.
Bon sinon à part faire un interpréteur qui a besoin de 4Go de ram pour fonctionner et qui rendent python encore plus lent : ça apporte quoi ?
Question subsidiaire : si je l'utilise pour faire tourner plone : il faudra combien de machine en cluster pour afficher une page ?
[^] # Re: Ah ah ! Trop gros ça ne passera pas !
Posté par ckyl . Évalué à 1.
[^] # Re: Ah ah ! Trop gros ça ne passera pas !
Posté par Bozo_le_clown . Évalué à 1.
[^] # Re: Ah ah ! Trop gros ça ne passera pas !
Posté par Yakulu . Évalué à 1.
http://docs.python.org/library/multiprocessing.html
http://www.ibm.com/developerworks/aix/library/au-multiproces(...)
Sinon, je crois qu'il faudra garder un œil sur le projet Unladen Swallow, ce compilateur JIT , qui vise, entre autres, à s'affranchir du fameux GIL ( https://linuxfr.org//2009/03/31/25246.html ).
[^] # Re: Ah ah ! Trop gros ça ne passera pas !
Posté par lasher . Évalué à 4.
Dans le cas d'une application multiprocessus, l'intégralité du processus est dupliqué (pile, tas, variables statiques et globales, etc.). La mémoire est compartimentée pour chaque processus (cf. man fork(2) sous Unix). Cela implique que pour communiquer entre les différents processus ainsi créés, il va falloir utiliser des appels explicites pour envoyer/recevoir des données : Socket BSD, pipe SysV, etc.
Dans le cas du multithreading, on a un même processus qui exécute plusieurs threads à la fois, la mémoire est implicitement partagée. Il faut donc faire attention à ne pas écraser la donnée du voisin. En contrepartie, la création d'un thread est bien moins lourde que celle d'un processus, l'empreinte mémoire est bien moins élevée si jamais mon application doit allouer de gros blocs, etc.
[^] # Re: Ah ah ! Trop gros ça ne passera pas !
Posté par Étienne . Évalué à 2.
Ce n'est pas tout à fait aussi tranché que cela. Tu peux très bien avoir 2 processus qui partagent une partie de leur espace mémoire (par exemple avec un fichier mappé en mémoire ou un segment de mémoire partagé) et on peut y placer des mutex, des sémaphores, des barrières, ... et donc l'utiliser pour communiquer comme on le ferait avec des threads.
Étienne
[^] # Re: Ah ah ! Trop gros ça ne passera pas !
Posté par lasher . Évalué à 2.
Cela dit, c'est ce qui est fait dans tout un tas d'applications, notamment celles qui ne sont pas (encore ?) thread-safe et qui ont besoin de communiquer.
[^] # Re: Ah ah ! Trop gros ça ne passera pas !
Posté par Kangs . Évalué à 2.
N'étant pas dans le monde des développeurs Java/Python j'ai vraiment cru que c'était plus ou moins une blague (bêtement j'ai pensé un interpréteur pour interprété un interpréteur : ca fait bizarre).
Sans la réaction de Philou Kapouik qui a permise des réponses permettant d'éclaircir l'intérêt je me demande combien auraient trouvés ce projet bizarres, la dépêche part du principe que tout le monde sait ce qu'est ce projet qui ne faisait plus parlé de lui depuis 2004.
[^] # Re: Ah ah ! Trop gros ça ne passera pas !
Posté par Mr Kapouik (site web personnel) . Évalué à 4.
Maintenant on a enfin en commentaire tout ce qu'il manque dans cette dépêche plus que vide.
[^] # Re: Ah ah ! Trop gros ça ne passera pas !
Posté par Kangs . Évalué à 1.
[^] # Re: Ah ah ! Trop gros ça ne passera pas !
Posté par Victor STINNER (site web personnel) . Évalué à 6.
Jython permet d'utiliser des modules et classes Java en Python, et inversement. Disons qu'en entreprise, on a pas toujours le choix des outils. Parfois la JVM est imposée. Et là ça permet de quand même faire du Python :-)
Quand aux performances ou à la gestion mémoire, je ne sais pas trop. Mais j'aurai tendance à penser que vu la qualité de la JVM Sun, ça doit aller vite (compilateur JIT) et utiliser correctement la mémoire. On peut configurer finement comment JVM utilise la mémoire.
[^] # Re: Ah ah ! Trop gros ça ne passera pas !
Posté par barmic . Évalué à -3.
OpenJDK n'est pas bien ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ah ah ! Trop gros ça ne passera pas !
Posté par barmic . Évalué à -3.
Faut prendre un peu de recul pour essayer de voir ce que donne au final les solution que l'on propose et là il est bien question de faire tourner des scripts (libres ou non) sur un interpréteur libre qui lui même tournerais sur une machine virtuelle propriétaire.
Pour ce qui est de la question par rapport à OpenJDK, elle est réelle y a t'il des différences de performances entre les deux ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ah ah ! Trop gros ça ne passera pas !
Posté par PuRPLeHaZe . Évalué à 1.
En ce qui concerne les performances de jython en général, on trouve des comparatifs sur internet, et notamment dans la faq du site jython. En ce qui concerne les performances de openjdk, je ne crois pas qu'il y ait de problème particulier, mais le cas échéant tu peux faire un journal complet + illustrations sur le sujet.
[^] # Re: Ah ah ! Trop gros ça ne passera pas !
Posté par Antoine . Évalué à 3.
Sans compter que Python n'est pas sous GPL, de toute façon... (mais sous une licence non-copyleft)
[^] # Re: Ah ah ! Trop gros ça ne passera pas !
Posté par ckyl . Évalué à 8.
Tout d'abord chacun est libre d'utiliser la JVM qu'il veut qu'elle soit libre ou non. Le fait que quelqu'un utilise une VM proprio pour faire tourner du code n'a aucune incidence sur le reste du monde.
Mais surtout par ce que ce dédain (ou ignorance mais ce n'est pas mieux quand on fait un commentaire de ce type) envers la VM de Sun est déplacé. OpenJDK c'est la VM de Sun et ca le restera pour un moment. >95% du codebase est le même et a été donné par Sun (OpenJDK 7 à été forké depuis le JDK 7b10, OpenJDK 6 depuis OpenJDK 7b20). Tu devrais aussi aller regarder du côté des commiters ou du côté de la governance board par interim qui vient d'être reconduite. Bref sans SUN OpenJDK n'existerait pas et aurait beaucoup de mal à survivre.
Dans le langage courant la VM de SUN ca désigne autant leur build proprio qu'OpenJDK surtout quand le commentaire au dessus fait référence à HotSpot.
[^] # Re: Ah ah ! Trop gros ça ne passera pas !d
Posté par PuRPLeHaZe . Évalué à 3.
[^] # Re: Ah ah ! Trop gros ça ne passera pas !
Posté par yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
[^] # Ça passe très bien :)
Posté par smc . Évalué à 10.
De même, JRuby est notablement plus performant que les interpréteurs habituels Ruby MRI ou même YARV.
Les JVMs, et notamment HotSpot, sont très performantes, même si un certain nombre d'amateurs en informatique sont restés sur l'idée que Java n'a pas changé depuis 98 et est toujours aussi lent. Il y a eu une série d'optimisations hallucinantes qui en font sans aucun doute la VM *ouverte* et dont il existe une implémentation *libre* la plus performante.
Ce qui est lent avant tout, c'est le lancement de la JVM (toujours moins lent que le lancement de Ruby MRI ou PyPy), et il est négligeable car sur n'importe quelle machine qui utilise du Java de nos jours, on la lance au démarrage du système et elle se pose en mode serveur.
Le rejet par une grande part de la communauté libre du monde Java c'est un tir dans son propre pied. Je comprends les raisons : Sun a fait l'erreur de ne pas libérer son implémentation avant ce qui a complètement tué l'engouement pour la VM. Et le langage Java n'est pas sexy du tout, donc ça ne motive pas les libristes qui codent en bonne partie pour le fun. D'un autre côté,certaines communautés n'ont pas de problème avec le monde Java (notamment Apache).
Le problème, c'est qu'il n'y a rien en face :
Le C ? Oui, il est toujours là, il est performant mais le temps de développement est décuplé comparé à un langage de haut niveau (je parle pas particulièrement de Java). Alors il y aura bien un très bon développeur C qui me lira et qui pensera qu'il peut programmer ce qu'il veut super vite, je lui affirme qu'il développerait encore plus vite dans un langage next-gen.
Le C++ ? Un monstre à 18 têtes, toujours là aussi, mais les programmeurs C++ se rendent compte de la perte de vitesse du langage : moins de libs maintenues, la nécessité d'utiliser des libs C et soit de les appeler "low-level" soit de faire leurs wrappers. Et (consultez Google si vous ne me croyez pas), C++ compilé avec gcc n'est que modérément plus rapide que du Java HotSpot. Parfois, Java est plus rapide. Mais c'est normal, avec la compilation JIT, votre code Java aussi tourne nativement.... (ceci n'est pas vrai si vous codez en C++ comme en C, avec des optimisations en assembleur, etc. Aussi, les templates sont moins couteuses en C++, mais aussi moins bien conçues).
Le Python ? Le langage est sympa, et il y a une véritable communauté de développeurs Python dans le monde libre. C pour la perf, Python pour l'UI / le développement rapide. Malheureusement, il faut écrire des bindings explicites pour lier les deux -- même si c'est fait automatiquement avec de nombreux outils qui marchent plutôt bien je dois l'avouer, mais c'est pas *pratique*. En plus l'interpréteur Python est vraiment lent. Si on fait son Python dans Jython (qui a un peu de retard malheureusement), on accède immédiatement à une immense bibliothèque standard supplémentaire, celle de Java, et des milliers de bibliothèques alternatives, notamment tout ce qui est Apache, Eclipse, Spring...
Le Ruby ? Même chose que Python, en plus lent et plus haut-niveau. Il existe JRuby.
Le problème principal, c'est que les langages haut niveau permettent d'écrire des bibliothèques/frameworks de façon plus maintenable (par exemple Plone) et plus intéressante qu'en C, mais que dans ce cas, les développeurs ne veulent pas faire des bindings high-level -> C pour ne pas avoir de dépendance sur un interpréteur (compréhensible mais pète-couille). On se retrouve donc bloqué sur un langage pour un framework.
Chez la concurrence, il y a .NET. C'est Managed C++, C# (Java, le langage, en mieux), ASP.NET (PHP en mieux), VB.NET (la première dose est gratuite), IronPython, F#.NET (OCaml)... Et l'avantage de ces environnements, immense en pratique, c'est l'intérop complète et automatique de tout ce qui est défini dans un langage, dans tous les autres. Il n'est besoin de définir une fonctionnalité qu'une fois. Il n'existe qu'une seule bibliothèque standard. Le langage utilisé dépend des goûts du développeur et de la tâche à effectuer, pas de l'existence de bindings, de la performance de la VM (même si les différents langages ont différentes performances), etc. Evidemment il existe toujours des wrappers pour rendre le style de programmation plus cohérent avec le langage host, mais c'est un problème moindre. À ça, on ajoute des environnements de développement rapide bien plus complets puisqu'ils gèrent un ensemble uniforme et compatible.
Le libriste anti-Java créée un rift entre le confort de développement GNU/Linux (multi-plateforme en fait) et Windows. Et pour faire venir de nouveaux développeurs, pour avoir des jeux par exemple, il faut un environnement de développement sexy.
À vrai dire, les distributions GNU sont plutôt sexy niveau environnement de développement, on a beaucoup d'outils libres et faciles à obtenir. Le toolchain est intéressant pour beaucoup de choses. Mais l'esprit trollesque anti-Java qui reste présent (pas que dans les communautés francophones) dessert la communauté.
Que faire ?
* Continuer comme aujourd'hui, avec des langages indépendants qui ont chacun leur ABI et qui ont besoin de bindings lourds à mettre en place ; avec des solutions pas toutes performantes et surtout, le lockin : un framework = un langage
* Passer sur un runtime/VM générique....
** Utiliser la JVM (projet JCR Da Vinci pour rendre la JVM plus générique) et profiter de nouveaux frameworks, langages, améliorer l'intégration avec les utilitaires usuels sous GNU/Linux (meilleurs bindings GNOME / GTK, etc)
** Passer à .NET avec Mono et être à la botte d'un environnement créé par une société qui, à travers ses actions passées, a montré qu'elle ne veut pas partager et qu'elle ne désire que Windows comme système, que ce soit sur les bureaux ou dans les racks.
Dans la pratique, .NET a des avantages sur Java, car il a été prévu directement pour être un environnement générique. Java essaie de rattraper le retard, et la stratégie d'Oracle/Sun est incertaine. D'un autre côté on a pas de doutes sur l'objectif final de Microsoft :)
Programmer sur la JVM, ça ne veut pas dire programmer en Java tout pourri.
Il y a Scala, un langage fonctionnel objet fortement typé très novateur qui rencontre un succès phénoménal. Il a les mêmes performances que Java (si vous suivez, ça veut dire qu'il est performant), et le feeling de Ruby !
Il y a Clojure, un autre langage fonctionnel dyamiquement typé, un Lisp-1, conçu directement pour la JVM qui rencontre aussi beaucoup de succès parmi les fans de Lisp, et les autres. Très performant pour un langage dynamique.
Il y a Groovy, plutôt lent, un langage objet dynamiquement typé, inspiré de Ruby mais directement conçu pour la JVM.
Et enfin il y a Jython et JRuby, les ports, plus performants que les originaux de Python et Ruby. Pas de risque d'être dépaysé.
Il est temps d'euthanasier le troll Java qui sommeille en vous.
[^] # Re: Ça passe très bien :)
Posté par yellowiscool . Évalué à -6.
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).
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.
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.
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.
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.
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…
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.
Mon troll java n'est pas près de mourir pour moi :-)
Envoyé depuis mon lapin.
[^] # Re: Ça passe très bien :)
Posté par Thomas Douillard . Évalué à 9.
T'as un site dédié pour faire ce genre de tests, avec des tas de benchmarks avec des implémentations de structures de données et tout dont on donne le code, dans pleins de langages.
Le résultat aggrégé est là, sans rentrer dans les détails de comment ils obtiennent ça, je te renvoie au site.
Et là java a beau être un peu plus lent que C, ils est loin d'être ridicule, surtout sur certains benchs ou il va plus vite que C, carrément.
[^] # Re: Ça passe très bien :)
Posté par smc . É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++...
[^] # Re: Ça passe très bien :)
Posté par smc . Évalué à 3.
[^] # Re: Ça passe très bien :)
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
[^] # Re: Ça passe très bien :)
Posté par smc . Évalué à 1.
[^] # Re: Ça passe très bien :)
Posté par yellowiscool . Évalué à -5.
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.C'est rigolo, je croyais que le java était un langage facile est efficace.
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 ?C'est lancé plusieurs fois pour pas que les valeurs soient trop aléatoires.
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.Quand en rajoutant la boucle, ça passe de 250 ms à 25 secondes, je néglige le chargement de la jvm. Désolé mon bench n'est pas à la miniseconde près ;-)
Enfin, comparer C et Java ça n'a aucun sens. Pourquoi ne compares-tu pas C à Python ou C à Ruby pour qu'on rie ?Java est présent dans des applications où il devrait à avoir du C (ou équivalent). Python et ruby non.
J'ai du mal à croire que tu aies déjà programmé un véritable système d'informations et que tu puisses dire ça.Non, j'avoue, je n'ai rien codé d'aussi complexe. Et tant mieux, je n'ai pas la prétention de pouvoir le faire.
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é.Uniquement ? Par certain ça… J'essayerais bien de tout virer (et de comparer avec la vitesse de lancement de nano, pour faire du comparatif de qualité).
Encore une fois, t'es resté sur des constatations d'il y a dix ans.Il y a dix ans, pour l'informatique, je jouais à Adibou ;-)
Pourquoi Apache fait à 90% du Java selon toi?Car ils ont plus de contributeurs qui aiment le java ?
RoR tourne plus rapidement sous JRuby.Boarf, on est plus à quelques armoires de serveurs près.
Encore une fois ton rejet simple et direct du monde Java te fait passer à la trappe des alternatives plus intéressantes.C'est le problème quand on troll. Mais si java devient correcte un jour, je l'utiliserais. Dans l'état actuel, cette alternative ne me semble pas intéressante.
Clairement, tu n'as jamais utilisé un framework Java style OSGi ou Spring, car les équivalents n'existent pas en C++ .Ouais, j'ai du faire autre chose en cours et en TP de java.
Tu bases tous tes arguments sur Java, le langage, alors que je parlais explicitement de Java, la plateforme.Oui, c'est la java que j'aime pas. Je n'ai rien contre les multiples librairies java à part leur lenteur due au langage.
Car à t'entendre, tout le monde doit être très con.Bah un garbage collector a une utilité pour les applications d'entreprise mal codées, une machine virtuelle pour maintenir une stabilité au détriment des performances, et les langages interéprétés sont mieux fait que le java.
Après tu dit que ces langages interprétés sont plus performants avec la jvm. Tant mieux, au moins elle sert à quelque chose cette machine virtuelle.
Envoyé depuis mon lapin.
[^] # Re: Ça passe très bien :)
Posté par smc . Évalué à 7.
C'est rigolo, je croyais que le java était un langage facile est efficace.
Je pense qu'aucun langage de programmation n'est "facile". Java est conçu pour être simple (et pas facile), ça n'empêche pas que chaque langage a ses propres idiomes et qu'il est insensé de transcrire naïvement le code sans tenir compte des propriétés du système (en l'occurrence la JVM).
Il faudrait que tu montres le code pour qu'on puisse te dire ce que tu fais mal, car c'est clair qu'il y a un problème vu les différences que tu trouves entre Java et C. Mais en réalité, c'est pas très important, comme il a été dit plusieurs fois, il y a plein de benchmarks bien faits sur le Web qui montrent que Java n'a pas à rougir niveau perfs.
C'est une question de compromis entre le niveau d'abstraction et la performance du code. Dans le monde réel, le compromis proposé par la JVM est intéressant et c'est pour ça que tout le monde, en dehors de Microsoft, utilise Java.
Java est présent dans des applications où il devrait à avoir du C (ou équivalent). Python et ruby non.
Non. Java a remplacé C++ qui est un enfer à maintenir et à programmer, et je dis ça en tant qu'ancien fan de C++ qui a vu la lumière et qui s'est reconverti. C++ c'est un jouet fun mais ça fait plus de mal que de bien.
Non, j'avoue, je n'ai rien codé d'aussi complexe. Et tant mieux, je n'ai pas la prétention de pouvoir le faire.
Donc, si je suis bien ton discours, tu dis "les applications complexes devraient être programmées sans GC", à quoi je réponds "ça va pas, c'est justement là qu'il est le plus utile" et tu me dis qu'en fait tu ne sais pas de quoi tu parles ;). Et bien je te dis, prenons par exemple le cas d'Eclipse vu que tu l'as utilisé comme IDE. Eclipse c'est des millions de ligne de code si tu prends que les projets de l'Eclipse Foundation (sur eclipse.org), sans compter les très nombreux projets extérieurs. Et dans un langage bien plus expressif que C.
Dans un tel système, s'assurer qu'il n'y a pas de memory leak, c'est difficile. Le garbage collector aide énormément.
Mais pas seulement pour ça. Au niveau des propriétés même du langage, c'est pratique d'avoir un garbage collector car ça te permet de savoir que si tu as une référence sur un objet, il existe. Dans un contexte de mémoire partagée (en multithread), et même si c'est bien d'éviter ça en général parfois on n'a pas le choix, c'est hyper pratique.
En C ou en C++, tu peux te retrouver avec la main sur un pointeur qui pointe dans le vide. T'es donc obligé, dès que t'as un pool de mémoire partagée, de créer toi même une abstraction sur tes pointeurs (en l'occurence, on utilise boost). Le garbage collector simplifie la vie de tous les programmeurs et l'overhead est minime comparé aux avantages. Encore une fois, c'est un compromis qu'on fait parce qu'il est impossible d'avoir uniquement des développeurs qui maîtrisent non seulement le langage, mais aussi la façon précise dont fonctionne l'application : en C/C++, une bonne partie du code, c'est pas du métier, c'est juste comment tu vas utiliser ton application. Heureusement y'a des frameworks / libs mais ils vont moins loin que ce qui existe en Java ou en .NET.
Uniquement ? Par certain ça… J'essayerais bien de tout virer (et de comparer avec la vitesse de lancement de nano, pour faire du comparatif de qualité).
Donc cette fois, tu veux comparer la durée de lancement d'un programme ncurse avec le lancement d'un programme graphique ?
Encore une fois, et j'ai l'impression que tu refuses d'entendre ça... je ne dis pas que Java ou la JVM est plus rapide ou aussi rapide qu'une application C/C++. Je dis qu'elle est *suffisamment* rapide (et à vrai dire, pas loin de C++), et que si tu as un PC antique c'est le PC qu'il faut changer, pas la JVM !
Car ils ont plus de contributeurs qui aiment le java ?
Personne n'aime Java. J'aime pas Java. Il y juste des gens pragmatiques qui reconnaissent une solution efficace ou pas. Apache utilise Java parce qu'il s'agit du langage d'entreprise ouvert.
C'est le problème quand on troll. Mais si java devient correcte un jour, je l'utiliserais. Dans l'état actuel, cette alternative ne me semble pas intéressante.
Il me semble que tu n'as pas regardé d'assez prêt ce qu'est "Java" aujourd'hui.
Clairement, tu n'as jamais utilisé un framework Java style OSGi ou Spring, car les équivalents n'existent pas en C++ .
Ouais, j'ai du faire autre chose en cours et en TP de java.
C'est pas avec quelques cours et TP de Java dans un IUT que tu risques de réaliser des avantages du langage. C'est probablement le langage avec le plus de bibliothèques, de frameworks, etc pour tout et n'importe quoi aujourd'hui. C'est le langage qui tourne sur le plus d'ordinateurs (je compte les téléphones portables).
Tu bases tous tes arguments sur Java, le langage, alors que je parlais explicitement de Java, la plateforme.
Oui, c'est la java que j'aime pas. Je n'ai rien contre les multiples librairies java à part leur lenteur due au langage.
Je ne parle pas particulièrement des bibliothèques mais surtout de la JVM et des langages alternatifs comme Scala ou Clojure, qui offrent clairement un confort à des années lumières de C ou de C++.
Bah un garbage collector a une utilité pour les applications d'entreprise mal codées, une machine virtuelle pour maintenir une stabilité au détriment des performances, et les langages interéprétés sont mieux fait que le java.
Après tu dit que ces langages interprétés sont plus performants avec la jvm. Tant mieux, au moins elle sert à quelque chose cette machine virtuelle.
Le garbage collector n'a rien à voir avec coder mal ! Ca fait partie du paradigme, comme les exceptions ! Une application complexe, il y a plein de développeurs qui vont travailler dessus, et pendant des années, voire dizaines d'années ! Il faut que quelqu'un qui se ramène dessus puisse la maintenir, la modifier sans tout casser. Les applications C ou C++ ont souvent leur pseudo framework maison bordélique qui change tous les ans qui rend la maintenance compliquée. En Java, tout ça, c'est standardisé ! Même la façon de nommer les classes, méthodes, tout est standardisé. On obtient un code bien plus uniforme mais surtout plus facile à maintenir.
Enfin, trouves-tu vraiment inutile qu'un développeur qui crée une application sous Windows sans penser à Linux ou à Mac produise du code compatible ? Trouves-tu que la situation d'avoir trois systèmes avec des frameworks qui se limitent à chaque système (et même parfois plusieurs frameworks comme GNOME et KDE sous Linux) est acceptable ?
[^] # Re: Ça passe très bien :)
Posté par zerkman (site web personnel) . Évalué à 1.
en es-tu bien sûr ?
[^] # Re: Ça passe très bien :)
Posté par yellowiscool . Évalué à 4.
Envoyé depuis mon lapin.
[^] # Re: Ça passe très bien :)
Posté par bad sheep (site web personnel) . Évalué à 5.
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.
Comme tu dis, de mauvaise qualité... sans aucune optimisation, un code qui répond à tes spécifications tourne chez moi en 8 secondes (compilé en debug, tout ça)... je sais pas comment tu fais ton truc, mais chez moi :
public class TestRec {
public static void rec(final int val) {
if (val == 0)
return;
rec(val - 1);
}
public static void main(String args[]) {
final long start = System.currentTimeMillis();
for (int i = 0; i < 655536; i++) {
rec(5000);
}
System.out.println("Time: " + (System.currentTimeMillis() - start) + "ms");
}
}
Time: 8045ms ... sur un portable hein ...
Bon, en rajoutant un peut calcul sur un entier, je vais à 10s... laisse les pros faire les benchs, et il y en a pas mal qui ne pensent pas comme toi.
Je ne parle même pas des cas comme le multithreading dans lequel il y a plein de fonctionnalités utiles en java (java.util.concurrent) qui permettent facilement en java de rendre des algo en // tandis qu'en C, c'est la plaie.
Quant aux interfaces graphiques, j'ai eu récemment le cas d'un prog en C++/Qt qui s'en sortait bcp moins bien qu'une interface Java à fonctionnalités équivalentes (et Dieu sait que j'aime bien Qt)
Sinon, juste pour info, le StackOverfow, il y a un paramètre de la JVM pour le paramétrer, c'est -Xss sur les JVMs de Sun si mes souvenirs sont exacts.
[^] # Re: Ça passe très bien :)
Posté par yellowiscool . Évalué à 3.
Donc sur un iMac G4 à 1,25 Ghz, qui au passage affiche le web avec webkit 10 fois plus rapidement que gecko ne pourra jamais le faire sur mon core 2 duo à 2 Ghz, j'ai…
Time: 214911ms
Soit 8 secondes contre près de 4 minutes.
La jvm de mac os X me donne ça:
java version "1.5.0_16"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b06-284)
Java HotSpot(TM) Client VM (build 1.5.0_16-133, mixed mode, sharing)
Je te laisses à tes propres conclusions.
Envoyé depuis mon lapin.
[^] # Re: Ça passe très bien :)
Posté par ndesmoul . Évalué à 1.
Tu peux déjà essayer en mode server (rajouter -server) à la ligne de commande.
[^] # Re: Ça passe très bien :)
Posté par ckyl . Évalué à 2.
Ca sert a rien de chercher ce qui va pas ou des options magiques, si il veut comprendre il donnera son code... Tout le monde semble d'accord pour dire que c'est un résultat très inhabituel.
[^] # Re: Ça passe très bien :)
Posté par yellowiscool . Évalué à 2.
La seule chose qui change avec le miens, c'est que je renvois à la fin 42, et que le type de retour de la fonction est un int.
Envoyé depuis mon lapin.
[^] # Re: Ça passe très bien :)
Posté par ckyl . Évalué à 9.
Mais dans ce genre de bench TOUT rentre en compte, de la moindre valeur de retour, à la version du compilateur et des options de compile. Ca vaut deja que dalle ces benchs en temps normal mais là...
Le code ci dessus, et on va s'y tenir, en C ca donne ca:
void rec(int val) {
if (val == 0)
return;
rec(val - 1);
}
int main(void) {
for (int i = 0; i < 655536; i++) {
rec(5000);
}
return 0;
}
une fois compilé en -O1 par gcc ca donne ca:
000000000040047c :
40047c: 48 83 ec 08 sub $0x8,%rsp
400480: 85 ff test %edi,%edi
400482: 74 08 je 40048c <rec+0x10>
400484: 83 ef 01 sub $0x1,%edi
400487: e8 f0 ff ff ff callq 40047c
40048c: 48 83 c4 08 add $0x8,%rsp
400490: c3 retq
0000000000400491 :
400491: 53 push %rbx
400492: bb 00 00 00 00 mov $0x0,%ebx
400497: bf 88 13 00 00 mov $0x1388,%edi
40049c: e8 db ff ff ff callq 40047c
4004a1: 83 c3 01 add $0x1,%ebx
4004a4: 81 fb b0 00 0a 00 cmp $0xa00b0,%ebx
4004aa: 75 eb jne 400497 <main+0x6>
4004ac: b8 00 00 00 00 mov $0x0,%eax
4004b1: 5b pop %rbx
4004b2: c3 retq
Tu passes en -O2, et la magie du data flow analysis:
0000000000400480 :
400480: f3 c3 repz retq
400482: 66 66 66 66 66 2e 0f nopw %cs:0x0(%rax,%rax,1)
400489: 1f 84 00 00 00 00 00
0000000000400490 :
400490: 31 c0 xor %eax,%eax
400492: c3 retq
Super le bench... Tu as tellement peu d'instructions dans un microbench que n'importe quelle modif peut vraiment tout changer.
Bon maintenant si tu compares une exécution du code donné par bad sheep en C (cf plus haut) et en Java (cf poste précédant), gcc 4.3.2 en -01 et un OpenJDK 1.6.0_0-b14 sur un C2D P9400, :
$ time java -server -cp Dev/workspace/Test/bin/ TestRec
real 0m7.983s
user 0m7.882s
sys 0m0.029s
$ time ./O1
real 0m7.206s
user 0m7.156s
sys 0m0.008s
Si tu veux la sortie assembleur d'Hotspot je te la file. C'est la même chose que gcc modulo quelques optims sur la gestion des boucles.
Plus tu réponds plus tu montre que tu ne comprend absolument pas ce que tu fais et que tu n'as aucune rigueur. Tu peux continuer à cracher sur les mecs de mozilla ou d'eclipse, mais moi à ta place je me retiendrais...
[^] # Re: Ça passe très bien :)
Posté par yellowiscool . Évalué à 2.
Je te dit pas si j'avais fait le truc présenté sérieusement…
Les gars, c'est juste un petit test pour illustrer mon point de vue. Et d'ailleurs il l'a fait. Le score sur mon power pc est assez parlant.
Jamais au grand jamais je n'oserais en faire un journal, présenter ça en entreprise, ou même en faire en article de blog. Pour des benchs de meilleur qualité (quoique, je pense que l'on aurais encore des raleurs ), faut y passer du temps.
La prochaine fois, je foutrais un lien si facile comme http://shootout.alioth.debian.org/
Pas de critique, pas de recherche, juste du troll.
Envoyé depuis mon lapin.
[^] # Re: Ça passe très bien :)
Posté par ckyl . Évalué à 5.
Pourquoi parler si ce n'est pas sérieux (et que ce n'est pas un truc marrant) ? Tu généralises et te permets d'insulter des devs a partir d'un test reprśentatif de rien du tout, que tu n'as toujours pas présenté, qu'on ne sais comment il a tourné et sur une archi exotique. Ça t'étonne qu'on le fasse remarquer ?
> Le score sur mon power pc est assez parlant.
Ce n'est pas du tout "parlant". Tu aurais voulu que ca le soit tu aurais posté ton code et on aurait pu valider en moins de 5 minutes le problème...
>La prochaine fois, je foutrais un lien si facile comme http://shootout.alioth.debian.org/
Étant donné que les conclusions de ton "test" et du shootout sont totalement opposés la prochaine fois il vaudrait mieux en effet...
[^] # Re: Ça passe très bien :)
Posté par yellowiscool . Évalué à -1.
Je n'ai jamais insulté un développeur. Juste critiqué le travail de certaines personnes. Si critiquer le travail, c'est insulter, je te souhaite bien du bonheur.
Si t'avais lu le passage du code sur mon power pc, tu serais que c'est le code posté par un autre gars juste au dessus de mon message.
Envoyé depuis mon lapin.
[^] # Re: Ça passe très bien :)
Posté par ckyl . Évalué à 7.
Il y a critique objective, et critique bête, méchante et non justifiée. Quand tu dis qu'un GC est une abbération; t'as pas l'impression de dire à quelques milliers de mecs qu'ils sont vraiment incompétents ? Idem avec ta remarque sur Eclipse. Tu as peut être une comparaison objective et factuelle à proposer ? Ou une vraie expérience à partager ?
> Si t'avais lu le passage du code sur mon power pc, tu serais que c'est le code posté par un autre gars juste au dessus de mon message.
Donc par chance le gars il a écrit exactement le même code que toi. C'est un coup de bol quand même !
Puisque c'est le même tu peux regarder mon bench plus haut ou tout les paramètres sont fixés et connus de tous. Tu peux le reproduire chez toi. J'ai refait tourner en natif et en Java x86 et x86_64 (même code, config, proc que plus haut):
$ file x86*
x86: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
x86_64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
$ time ./x86
user 0m15.097s
sys 0m0.012s
$ time ./x86_64
user 0m7.143s
sys 0m0.012s
$ time ~/java/x86/sun/jre1.6.0_14/bin/java -server -cp Dev/workspace/Test/bin/ TestRec
user 0m4.272s
sys 0m0.028s
$ time ~/java/x86_64/sun/jre1.6.0_14/bin/java -server -cp Dev/workspace/Test/bin/ TestRec
user 0m7.802s
sys 0m0.035s
C'est reproductible, tout est fixé. De ce test je retire:
- Que tu as des résultats extravagants et que tu ne cherches pas à savoir pourquoi.
- Que le test est vraiment merdique pour prouver quoi que ce soit. Pourquoi l'avoir écrit ?
- Que chez moi le temps d'exécution en x86 de la version C est 4x plus lente qu'avec un JRE x86. Je peux donc dire que le devs de linux sont vraiment trop cons de coder en C...
- Que les mecs d'apple qui ont fait le JIT ont pu faire nawak (ou les sous traitants)
- Que les powerpc peuvent ne pas aimer du tout la récursion, faudrait regarder la tête du code machine généré par gcc. Un coup d'objdump c'est vite fait...
- Que ne pas avoir à pusher ebp à chaque appel de méthode en x86_64 fait doubler les perfs par rapport à de l'x86, sont pas bête chez AMD.
- Qu'il faudra que je trouve une explication à la perf du JRE x86
Sur ce j'arrête là.
Toi qui donnais des leçons aux mecs de mozilla et d'eclipse. Tu devrais soit montrer que tu fais bien mieux, soit chercher à comprendre ce qu'il ce passe. Après tu utilises ce que tu veux je m'en fou, mais ne crache pas sur les autres quand tu n'as rien pour te justifier.
[^] # Re: Ça passe très bien :)
Posté par yellowiscool . Évalué à 1.
Donc par chance le gars il a écrit exactement le même code que toi. C'est un coup de bol quand même !J'ai écris «Je viens de copier coller ton code.». Tu serais plus crédible si tu lisais mes messages.
Après tu utilises ce que tu veux je m'en fou, mais ne crache pas sur les autres quand tu n'as rien pour te justifier.Justement, j'ai apporté la justification, en plus du bench je détail longuement pourquoi je n'aime pas le java et les garbage collector. Cette explication ne te convient pas, je pense que tout le monde l'a compris, mais évite de vouloir me décrédibiliser à tout prix, mon bench le fait sans toi ;-)
Envoyé depuis mon lapin.
[^] # Re: Ça passe très bien :)
Posté par yellowiscool . Évalué à 1.
Time: 196777ms
C'est une différence appréciable, mais ça reste énormément long.
Envoyé depuis mon lapin.
[^] # Re: Ça passe très bien :)
Posté par windu.2b . Évalué à 1.
[^] # Re: Ça passe très bien :)
Posté par Jean B . Évalué à 3.
Enfin bref rien qui puisse justifier de tels écarts.
Je pense simplement que la version PowerPC est bien moins optimisée que les versions x86 et Sparc. Mais peut-être que je me trompe.
[^] # Re: Ça passe très bien :)
Posté par ckyl . Évalué à 2.
Je ne sais pas qui a développé le backend utilisé avec OS X sur g4/g5 mais je pencherais pour Apple, au moins en parti, puisque le code ne s'est pas retrouvé dans OpenJDK...
[^] # Re: Ça passe très bien :)
Posté par windu.2b . Évalué à 2.
[^] # Re: Ça passe très bien :)
Posté par ckyl . Évalué à 5.
- un microbench représentatif de rien du tout
- une méthodologie non documentée (sources, outils, procédure de test etc)
- une boucle qui est certainement dans la main. Comment tu fais du JIT sur le main ? Question bonus est ce que hotspot sait le faire ?
- un bench un mode interprété et non en JIT. Aux dernières nouvelles le CompileThreshold c'est 10000 en mode serveur
- un bench sur une tail call récursion qui n'est pas optimisé par Hotspot ce qui explique les stack overflow et la lenteur
Bref ca vaut pas beaucoup plus que du papier WC ton truc. Si tu veux microbencher un truc inutile compare au moins le code machine produit par gcc et par HotSpot (-XX:+PrintOptoAssembly -XX:CompileThreshold=1). Cela dit je pense que ton temps serait mieux investi à apprendre 2 ou 3 trucs.
Pour les perfs de Java sur des trucs bas niveau type calcul numérique tu peux regarder là: http://hal.inria.fr/inria-00312039/en paragraphe 5.2.3. Faut pas généraliser dans un sens comme dans l'autre. Comme toute techno il faut savoir comment ca marche en dessous pour pondre du code rapide, que tu tournes sur une VM ou pas.
[^] # Re: Ça passe très bien :)
Posté par yellowiscool . Évalué à 1.
Ça représente la lenteur pour des choses simples, à savoir les appels de fonctions.
La méthodologie est expliquée, c'est une boucle et une récursivité.
Oui la boucle est dans le main, et je vois pas pourquoi je devrais la mettre ailleurs, les optimisations rigolotes, j'en ai rien à faire, on est censé coder efficacement. En C ton programme est rapide même si tu ne places pas exactement l'instruction à l'endroit idéal.
J'ai rien compris, j'ai une petite formation java, je ne suis pas un expert.
Tu veut dire qu'en java il faut s'embêter à chercher LE truc qui optimise dans UN cas précis ? Sans moi.
Mon bench était là pour illustrer un sentiment, pas pour mettre en source sur wikipedia.
Là je suis d'accord avec toi pour le dernier paragraphe.
Envoyé depuis mon lapin.
[^] # Re: Ça passe très bien :)
Posté par ckyl . Évalué à 8.
Revenons à nos moutons, tu ne comprends pas que le code que tu as pondu (et qu'on a toujours pas vu) doit cumuler les cas pathologiques qui ne se retrouvent pas dans une vraie appli ? Tu ne comprends pas pourquoi ton test est mauvais ? Il n'y a que des imbéciles qui disent que Java est facile. Il faut apprendre comment ca marche. Certains concepts sont propres à l'OOP, d'autres à a spécification de la JVM, du langage Java ou à une implémentation particulière. Il faut les maitriser, et c'est parreil avec toutes les technos. Par contre java n'est pas piégieur (l'API de la libc est ultra casse gueule par exemple).
Tu parles tu temps d'appel d'une fonction ok, mais c'est quoi un appel de fonction ? Quelle est la sémantique en C et en Java ? A ton avis tout les appels de méthodes suivants sont ils équivalents ?
private void a() {}
public void b() {}
public final void c() {}
public static void d() {}
La réponse est bien évidement non. X.b() est un appel de méthode virtuel alors que tout les autres seront des appels finaux. Dans le cas d'un appel virtuel tu as des opérations supplémentaires pour déterminer le type réel de l'objet et appeler la bonne méthode:
010 B2: # B6 B3 <- B1 Freq: 0.999999
010 movq R11, precise klass Virt: 0x0000000000d5b7d8:Constant:exact * # ptr
01a cmpq R10, R11 # ptr
01d je,us B6 P=0.500000 C=-1.000000
01d
01f B3: # B11 B4 <- B2 Freq: 0.499999
01f movq R11, precise klass Virt2: 0x0000000000d5b9e8:Constant:exact * # ptr
029 cmpq R10, R11 # ptr
02c jne,us B11 P=0.000001 C=-1.000000
02c
02e B4: # B12 B5 <- B3 Freq: 0.499999
02e movq RBP, RSI # spill
031 # checkcastPP of RBP
031 movq RSI, RBP # spill
034 nop # 3 bytes pad for loops and calls
037 call,static Virt2::b
# Main::doit @ bci:1 L[0]=RBP
# OopMap{rbp=Oop off=60}
03c
03c B5: # B8 <- B4 Freq: 0.499989
# Block is sole successor of call
03c movq RSI, RBP # spill
03f jmp,s B8
03f
041 B6: # B13 B7 <- B2 Freq: 0.499999
041 movq RBP, RSI # spill
044 # checkcastPP of RBP
044 movq RSI, RBP # spill
047 call,static Virt::b
# Main::doit @ bci:1 L[0]=RBP
# OopMap{rbp=Oop off=76}
04c
Ce n'est pas si couteux que ca mais sur un microbench tu peux le sentir. Contrairement au C++, en Java les méthodes sont virtuelles sauf si private/static/final. La JVM est tout de même assez intelligente, ici elle se passe d'un call,dynamic et préfere deux call,static conditionnels. De plus si une classe n'est pas sous classée ca devient un appel non virtuel:
014 B2: # B7 B3 <- B1 Freq: 0.999999
014 nop # 3 bytes pad for loops and calls
017 call,static Virt::b
# Main::doit @ bci:1 L[0]=RBP
# OopMap{rbp=Oop off=28}
Et comme Java supporte le dynamic code loading ça peut changer au cours de l'exécution, une autre beauté d'Hotspot...
Ce n'est qu'un exemple de pourquoi ce genre de microbench peut être très trompeur si tu ne maitrise pas parfaitement ton sujet tu peux mesurer deux choses très différentes sans t'en rendre compte.
Maintenant qu'on a vu l'"appel de méthode". Passons à ton bench. Supposons que tu a écris une fonction tail recursive, comme factoriel. Compilé par gcc ça donne ça (-O2):
0000000000400480 <fact>:
400480: 85 ff test %edi,%edi
400482: b8 01 00 00 00 mov $0x1,%eax
400487: 74 0f je 400498 <fact+0x18>
400489: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
400490: 0f af c7 imul %edi,%eax
400493: 83 ef 01 sub $0x1,%edi
400496: 75 f8 jne 400490 <fact+0x10>
400498: f3 c3 repz retq
40049a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
C'est dommage tu voulais bencher les appels de méthode mais y'en a pas ! L'opti qui est possible en C n'est pas possible en Java. Donc ton bench il sert à quoi ? Tu enfonces une porte ouverte, un jump est plus rapide qu'un callq et toutes les opérations associées. Écrire un tel code en Java c'est une faute, il faut utiliser la version impérative tu auras exactement les mêmes perfs qu'en C ou assembleur.
Je passe sur le fait que ton bench a peu de chances d'être compilé par le JIT étant donné la structure de ton test.
Mais au final tout ca on s'en fou. Hormis si tu bosses dans quelques secteurs bien précis, du code CPU bound t'en écriras pas des masses... Et c'est pas ca qui est important ou qui fera ramer un projet, ça serait trop simple.
[^] # Re: Ça passe très bien :)
Posté par yellowiscool . Évalué à 3.
Les petites fonctions d'une ligne, c'est quand même une grande partie d'un programme.
Ici tu as des mecs qui ont codé un peu plus que des TP d'IUT; qui sont certainement capable d'écrire du C bien mieux que toi et qui en plus sont compétents en Java. Tu penses pas que tu devrais réfléchir un peu ?C'est ce que je fais, j'expose mon point de vue, on me réponds de façon constructive, et je réfléchis encore. Après, désolé si je trouve les arguments pas assez convaincants («oui, mais gcc optimise plus que la jvm», je dirais que c'est pas trop mon problème de futur développeur bac + 2 (pour l'instant).).
De plus tu découvriras aussi le compromis plus tard. Si je peux faire 30% plus rapide mais que ca demande 50% de budget en plus est ce que j'y gagne ? La rapidité n'est qu'un critère il y en a de nombreux autres, techniques ou pas.Je préfère faire du Qt que de l'awt. Et en plus, c'est plus rapide.
Envoyé depuis mon lapin.
[^] # Re: Ça passe très bien :)
Posté par wilk . Évalué à 4.
c 5s
gcj 7s
java 7s
python2.5 + psyco 18s
python2.5 303s
java est extrêmement performant s'il est utilisé comme du C. On retrouve ces résultats sur http://shootout.alioth.debian.org/
Par contre, en pratique, d'une part c'est rare que ce genre de code soit déterminant, les perfs se jouent beaucoup plus sur le choix des librairies utilisées, l'algo choisit etc. C'est là que va jouer la "facilité" du langage, le support de la communauté etc. Le résultat peut même s'inverser.
[^] # Re: Ça passe très bien :)
Posté par wilk . Évalué à 2.
[^] # Re: Ça passe très bien :)t
Posté par wilk . Évalué à 4.
[^] # Re: Ça passe très bien :)t
Posté par smc . Évalué à 3.
[^] # Re: Ça passe très bien :)t
Posté par ndesmoul . Évalué à 2.
http://blog.headius.com/
D'après l'auteur d'ailleurs, la priorité pour JRuby a toujours été la compatibilité. Ce n'est que relativement récemment qu'ils ont commencé à travailler sur les performances (déjà meilleures que l'original) et on peut s'attendre encore à des améliorations.
[^] # Re: Ça passe très bien :)
Posté par Adrien . Évalué à 2.
Il me semble qu'il existe des alternatives peu utilisées, comme le langage D par exemple… Après je n'ai jamais utilisé ce langage, mais il a l'air très intéressant.
http://www.digitalmars.com/d/
[^] # Re: Ça passe très bien :)
Posté par smc . Évalué à 0.
[^] # Re: Ça passe très bien :)
Posté par Gniarf . Évalué à 2.
on n'aurait pas perl, python, ruby, php, lua et tous les autres, en fait, on en serait peut-être encore à COBOL et FORTRAN avec des horreurs poilues comme JCL à coté.
on améliorerait indéfiniment une grosse merde bloated totalement sclérosée comme SQL-C++**^^!!//--%%##\_o<\_o< au lieu de s'apercevoir que c'est son usage, son environnement qui compte, comme RoR l'a encore rappelé, malgré les performances merdiques de Ruby lui-même
[^] # Re: Ça passe très bien :)
Posté par smc . Évalué à 2.
C'est compréhensible quand il s'agit d'un langage de recherche qui apporte des concepts nouveaux, ou quand il s'agit d'un langage industriel qui fait ces apports ; dans le cas d'un langage comme D ça n'a aucun sens car il est déjà dépassé avant même d'avoir connu la moindre heure de gloire.
Mais je suppose qu'il était plus facile pour toi de ne pas faire le moindre effort de compréhension du point que je soulevais et d'attaquer mon message inutilement.
[^] # Re: Ça passe très bien :)
Posté par Gniarf . Évalué à 2.
voili voilou.
[^] # Re: Ça passe très bien :)
Posté par smc . Évalué à 2.
Pourquoi se faire chier avec encore un autre langage impératif...
[^] # Re: Ça passe très bien :)
Posté par Gniarf . Évalué à 4.
[^] # Re: Ça passe très bien :)
Posté par smc . Évalué à 3.
J'aime pas les langages strictement impératifs, même si des traits impératifs sont toujours pratiques, tout simplement parce qu'ils imposent un design trop simple et j'ai l'impression d'avoir des menottes quand je les utilise. Dans le panier "fonctionnel" on met tout et n'importe quoi, mais au moins avec les fonctions comme citoyens de première classe et donc pouvoir faire des designs de second ordre, c'est le minimum ! En pratique pour faire des applications solides et parallèles, les données immutables et l'absence d'effets de bord non explicites sont aussi super pratiques. Après, des fois ça va loin et c'est pas non plus pratique ou ça impose une gymnastique mentale qui n'est pas à la portée de tous, et en tant que feignasse (je suis pas informaticien pour rien), je suis bien content que des singes se tapent le boulot qui m'intéresse pas dans un langage débile (par exemple : Java). Evidemment j'hyperbolise, mais il y a beaucoup de professionnels qui ne s'intéressent pas à l'informatique et qui codent néanmoins ; il faut des langages simples pour eux.
Le problème avec cette fragmentation des langages, c'est qu'elle me retombe dessus. Imagine une grosse entreprise où un hurluberlu décide d'utiliser D ou je ne sais quel langage qui sort de nulle part, qui ne fait que réinventer la roue avec des avantages minimes, et n'est pas compatible de façon transparente avec une plateforme existante. Imagine que je travaille ou sous-traite pour cette entreprise et je me retrouve à bosser sur ce projet.
Et bien non seulement je suis forcé d'apprendre ce langage (pas très gênant), mais surtout je suis forcé de *bosser* dans ce langage limitatif qui emprisonne mes belles idées (et en plus je dois apprendre à utiliser le tooling, c'est pas le cas de D qui se branche sur le frontend gcc si je me souviens bien, mais certains langages vont jusqu'à utiliser leur compilo avec des options débiles, leur chaine de build autiste qu'ils ont refait dans leur langage alors qu'il en existe 5000, etc).
En revanche, un langage qui ne fragmente pas, et qui fait que, sans émerveillement pour la plateforme JVM, je la reconnais comme un choix logique et intéressant, il ne va pas me poser de problème. Imagine la grosse boite, le gars fait son projet en Groovy ou pire, en Fan. J'aime ni Groovy, ni Fan, mais c'est la vie.
Quand j'arrive sur ce projet, si c'est pour des contributions notables et que ça va me prendre du temps, je vais pouvoir utiliser des langages qui me bottent pour bosser ! Clojure si je suis d'humeur à faire du Lisp, et Scala si je suis d'humeur... à faire du Scala (pour moi, c'est OCaml avec un coding style Java et plein de features très funky qui me plaisent et qui pour le coup innovent pas mal dans la manière de faire même s'il reste du travail à faire).
Je suis pour la création de langages ! On peut difficilement l'être plus que moi, je suis fan de DSLs, de langages, etc. Mais réinventer un n-ième langage généraliste qui n'apporte rien, et qui en plus nécessite de tout refaire ? Non merci.
J'aime les langages de programmation, et il y a plein d'idées dans le monde des langages, dont certaines qui ne sont pas intéressantes à intégrer à une plateforme style VM (en Haskell on va pas coder chaque appel de méthode Java avec une monade quand même, ça n'a pas de sens de l'intégrer à la JVM dans l'état actuel de la JVM). Mais dans ce cas, il faut le justifier avec de bonnes raisons : des concepts non compatibles, le ciblage à l'embarqué dans des conditions particulières, etc. Pour moi D n'a rien de tout ça. Je sais même pas pourquoi on en parle.
Pour moi, les VMs c'est super pratique. Et D a du réaliser ça, puisque maintenant ils ont D.NET ! Et si je suis pragmatique j'ai le choix entre .NET et la JVM. J'ai fait mon choix.
[^] # Re: Ça passe très bien :)
Posté par Gniarf . Évalué à 2.
*gratte* *gratte*
[^] # Re: Ça passe très bien :)
Posté par smc . Évalué à 2.
Clojure et Scala tournent sur la JVM. Le langage que j'utilise nécessite que les autres développeurs qui veulent ajouter des fonctionnalités (si c'est conçu de façon modulaire comme il faut) doivent programmer pour la JVM. Parmi les choix sérieux bien sur y'a Java, Scala, Clojure, Ruby (JRuby), Python (Jython) et JavaScript (Rhino).
Alors que le toto qui m'impose D, bien j'ai pas le choix, je dois faire du D.
[^] # Re: Ça passe très bien :)
Posté par yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
[^] # Re: Ça passe très bien :)
Posté par smc . Évalué à 2.
Encore une fois, je ne parle pas d'une petite application. Les grosses applications d'entreprise (du moins depuis Java) sont gérés par des frameworks qui s'assurent du découplage des parts. Chaque partie constitue un projet différent (et donc susceptible d'avoir un langage différent).
[^] # Re: Ça passe très bien :)
Posté par yellowiscool . Évalué à 1.
J'aimerais pas être chef de projet pour une application en jvm.
Envoyé depuis mon lapin.
[^] # Re: Ça passe très bien :)
Posté par Gniarf . Évalué à 2.
*gratte* *gratte*
je ne vois pas la différence avec une machine non virtuelle, si on doit reprendre ton code il faut qu'on se tape ton langage.
[^] # Re: Ça passe très bien :)
Posté par smc . Évalué à 2.
[^] # Re: Ça passe très bien :)
Posté par Gniarf . Évalué à 4.
je ne vois aucune différence avec le gus qui code en D et toi qui te plaint que pour maintenir son code tu doives apprendre le langage D.
car tu changes juste de plateforme. et ces notions d'interopérabilité entre langages sur la plateforme Java, ben ça existe sur toutes les plateformes décentes, sous de multiples formes
[^] # Re: Ça passe très bien :)
Posté par smc . Évalué à 2.
Le gars devra coder en Jakouski s'il veut *modifier* la partie spécifique écrite en Jakouski, mais avec de la programmation par composants qui se fait de nos jours (pour la JVM, c'est OSGi), quelqu'un qui voudra utiliser les fonctionnalités de Jakouski dans son programme ou même l'étendre pourra le faire en Java ou un autre langage de la JVM.
Je n'ai jamais prétendu que la VM résolvait tous les problèmes et la fin de de la guerre dans le monde, si c'est ce que tu as tiré de mes commentaires je suis désolé :).
Ces capacités d'interopérabilité entre langages n'existent que dans les VMs récentes (et en pratique, dans le monde logiciel industriel, que .NET et JVM)... Comme je l'ai déjà dit, l'avantage de cette interop est qu'elle est automatique, transparente et bi-directionnelle, à la différence de bindings C vers Python (qui va faire un programme écrit en C qui tourne sur Zope ?).
Bien évidemment, si quelqu'un veut modifier du code écrit dans un langage donné, il lui faut apprendre ce langage. Comme je l'ai déjà dit (ça aussi), mon problème c'est de passer trop de temps à écrire en Jakouski, pas de modifier légèrement le code. Pour des raisons de séparation des concerns, je ne vais pas faire faire au programme Jakouski des conneries qui dépassent le cadre de son activité ; pour ça j'écrirai une extension qui peut être dans un autre langage.
Il y a aussi le fait qu'en entreprise les langages doivent être validés, donc évidemment on va éviter de coder dans n'importe quel langage sous prétexte qu'il tourne sur la JVM, il faut de bonnes raisons (je me répète).
Enfin inutile de passer encore 3 semaines à discuter de ça, on a chacun nos points de vue issues d'expériences différentes et peut être que tu changeras d'avis, peut-être pas. Je partageais ton opinion donc c'est possible d'en changer... par contre je ne vais pas retourner en arrière. Y'a rien qu'à voir la merde qu'est le classloading avec des dépendances en C++ ou dlopen en C ; les bindings pour chaque langage c'est mieux que rien, mais des bindings on peut aussi en faire pour la JVM (et c'est tout aussi chiant).
[^] # Re: Ça passe très bien :)
Posté par grochon . Évalué à 1.
Je ne suis pas allé chercher les benchs pour vérifier que cette affirmation tombe du ciel ou non, en revanche je suis un peu le dev de Waf.
Il y a eu un patch pour qu'il puisse tourner justement sous Jython, et d'après leur outils de test, non Jython n'est certainement pas plus rapide :
http://code.google.com/p/waf/issues/detail?id=434&can=1&(...) .
D'aucuns me diront que c'était sous un Jython beta, mais c'est l'exemple concret que j'ai sous la main.
[^] # Re: Ça passe très bien :)
Posté par smc . Évalué à 2.
Pour Jython les cas plus rapides sont moins clairs qu'avec JRuby à cause de l'arrêt dans le développement de Jython pendant plusieurs années, alors que la performance de CPython s'est améliorée. J'ai été un peu vite donc, je parlais plus de JRuby niveau perf.
[^] # ça passe très mal
Posté par Tramo Piere . Évalué à 1.
Pour le moment les profiles obtenus montrent que tout est plus lent que cPython, et pas seulement pour Waf:
http://psycle.svn.sourceforge.net/viewvc/psycle/branches/boh(...)
Note: l'utilisation des threads java n'améliore pas les performances.
[^] # Re: Ça passe très bien :)
Posté par ckyl . Évalué à 4.
Extrait de wikipedia:
JIT mode is available since JRuby 1.1. In performance benchmarks, JRuby is consistently 200% to 300% faster than C Ruby 1.8.6 [27] but still 15%-25% slower than C Ruby 1.9. However, the JRuby 1.1.6 version outperforms C Ruby 1.9 in some cases [30][31].
Also in a real Mongrel web server application, JRuby performance is better than Ruby (after the Virtual Machine has instantiated)[32].
[^] # Re: Ça passe très bien :)
Posté par Antoine . Évalué à 4.
Des références concrètes ?
[^] # Re: Ça passe très bien :)
Posté par Bozo_le_clown . Évalué à 1.
C'est pas assez concret ?
Pourtant ca vient d'un monsieur qui n'est pas réputé pour être un détracteur de python.
http://www.dabeaz.com/
Mais comme Guido a dit que le multithreading ne servait à rien et que le multiprocess faisait bien l'affaire.
Je replace les conclusions pour montrer comme ca n'a qu'un impact mineur
Is it Worth It?
• If you could fix it, it would make thread
execution (even with the GIL) more
predictable and less resource intensive
• Might improve performance/responsiveness of
applications that have a mix of CPU and I/Obound
processing
• Probably good for libraries that use threads in
the background (e.g., multiprocessing)
• Might be able to do it without rewriting the
whole interpreter.
[^] # Re: Ça passe très bien :)
Posté par Antoine . Évalué à 3.
Non, c'est seulement un aspect parmi d'autres de la performance, et probablement pas le plus important pour ce à quoi est utilisé Python généralement. Certes, on peut jouer les midinettes du parallélisme comme c'est à la mode en ce moment et lever les yeux au ciel parce que Python n'autorise pas un multi-threading efficace...
D'autant que, comme mentionné par d'autres, il y a d'autres moyens de faire du parallélisme que de faire du multi-threading.
(par ailleurs, l'étude de David Beazley est très intéressante et les problèmes méritent d'être corrigés)
[^] # Re: Ça passe très bien :)
Posté par Bozo_le_clown . Évalué à 2.
Tu as raison c'est seulement un des aspects de la performance.
Et il vrai que le multiprocess est la panacée lorsque tu dois refactorer ton code.
Expliquez moi ce dont vous avez besoin, je vous expliquerai comment vous en passer.
probablement pas le plus important pour ce à quoi est utilisé Python généralement.
C'est pas les pythonista qui affirment que python n'est pas qu'un langage de script et qu'on peut tout faire avec.
[^] # Re: Ça passe très bien :)
Posté par Antoine . Évalué à 2.
C'est bien ce que j'appelle du discours de midinette, basé sur des lieux communs ingurgités ça et là sur le Web et régurgités sans réfléchir.
Ce n'est pas parce que nos ordinateurs sont parallèles que c'est forcément pour faire tourner une seule application à la fois (ou même une seule instance de cette application).
Même, ce n'est pas parce qu'une application est parallèle que cela doit être par le multi-threading.
(en passant, ton analyse des raisons du multi-coeur est un contresens amusant : si le multi-coeur « s'impose », c'est précisément grâce à la miniaturisation et non pas à cause de ses limites... Ben oui, il y a plus de place sur une puce bon marché que ne peut en faire raisonnablement usage un seul coeur, donc on rajoute des coeurs à côté. Note que cela n'empêche pas les coeurs individuels de devenir eux-mêmes plus puissants au fil du temps - compare un coeur d'Intel Nehalem et un coeur de Pentium 4 si tu n'es pas convaincu)
Et il vrai que le multiprocess est la panacée lorsque tu dois refactorer ton code.
Mais il n'y a pas de panacée, mon cher, en matière de parallélisme. Quelque soit la technique utilisée, c'est toujours beaucoup plus délicat de faire du code parallèle que du code strictement séquentiel, car il faut maîtriser tous les problèmes de synchronisation qui surgissent.
Ironiquement, quand on veut faire de la programmation multi-thread robuste, on en arrive souvent à utiliser les mêmes techniques que pour du multi-processing : par exemple du passage de messages.
C'est pas les pythonista qui affirment que python n'est pas qu'un langage de script et qu'on peut tout faire avec.
http://fr.wikipedia.org/wiki/Homme_de_paille_(rh%C3%A9toriqu(...)
[^] # Re: Ça passe très bien :)
Posté par Bozo_le_clown . Évalué à 3.
Mais il n'y a pas de panacée, mon cher, en matière de parallélisme. Quelque soit la technique utilisée, c'est toujours beaucoup plus délicat de faire du code parallèle que du code strictement séquentiel, car il faut maîtriser tous les problèmes de synchronisation qui surgissent.
Ironiquement, quand on veut faire de la programmation multi-thread robuste, on en arrive souvent à utiliser les mêmes techniques que pour du multi-processing : par exemple du passage de messages.
Marrant , je vois déjà un intérêt dans le multithreading: les IHMs.
Je trouve relativement naturel de lancer un ou plusieurs traitements long en tâche de fond sans bloquer l'utilisateur.
C'est relativement simple en lancant un thread par traitement.
Avec du multiprocess tu dois lancer un nouveau process avec tout la batterie d'artifices qui s'ensuit, si tu dois mettre en place des mécanismes de synchro. Mais tu as raison, on peut s'en sortir, au prix de quels sacrifices.
Et après, ca vient donner des leçon de simplicité aux utilisateurs de langages statiquement typés.
Ah oui mais python supporte le multithreading ...séquentiel, j'allais oublier.
Et en plus il tourne sur plein de vm qui supporte le multithread.
Bon, l'important c'est que tu admettes que l'étude de Dave est intéressante.
Ca permettra peut-être de convaincre le dictateur éclairé de revoir sa position.
[^] # Re: Ça passe très bien :)
Posté par Antoine . Évalué à 3.
Je trouve relativement naturel de lancer un ou plusieurs traitements long en tâche de fond sans bloquer l'utilisateur.
Oui, je suis d'accord.
Bon, l'important c'est que tu admettes que l'étude de Dave est intéressante.
Ca permettra peut-être de convaincre le dictateur éclairé de revoir sa position.
Il n'y a pas vraiment besoin de « convaincre le dictateur ». Je ne dis pas qu'on fera ça sans sa permission, mais je pense qu'il est convaincu qu'une hypothétique implémentation sans GIL, si elle ne dégrade pas les performances mono-threadées, remplacerait avantageusement l'implémentation actuelle.
Du reste, si l'on peut déjà optimiser le GIL pour le rendre moins coûteux en coût de switching et de contention, ce sera une bonne amélioration (c'est-à-dire pour éliminer les cas pathologiques détectés par Dave Beazley).
# et les bibliotheques python ?
Posté par norbs . Évalué à 3.
[^] # Re: et les bibliotheques python ?
Posté par smc . Évalué à 1.
PIL est une bibliothèque C bindée en Python, et wxPython est un bind pour wxWidgets (C++). Il faudrait porter les bindings avec JNI (Java Native Interface).
C'est le cas pour wxWidgets avec le projet jwx!. Tu peux donc l'appeler depuis Jython, mais l'API ne sera pas celle de wxPython à moins de faire un wrapper toi même. En revanche, le résultat sera strictement identique.
Pour ce qui est de NumPy, il y a eu un projet pour le faire marcher avec Jython, je ne sais pas où ça en est.
Néanmoins il existe des alternatives pour toutes ces bibliothèques dans le monde Java (ou la possibilité de les porter).
Notamment pour le calcul scientifique, il y a Fortress qui est basé sur les concepts de Fortran et qui tourne sur la JVM.
En gros, pour qu'un logiciel tourne aujourd'hui dans Jython, il faut que le code soit entièrement écrit en Python, et compatible 2.5. Tout ce qui est intense en calcul est habituellement écrit en C ou en C++ et bindé en Python.
[^] # Re: et les bibliotheques python ?
Posté par Troy McClure (site web personnel) . Évalué à 3.
waou ça fait rever ! les concepts en question c'est le goto , les fichiers sources tout en majuscules et les noms de fonction et de variable limités à 6 caractères avec typage implicite en fonction de la première lettre ?
(on notera que les concepteurs de fortran 77 avaient déjà résolu le problème des fuites de mémoire, et cela sans utiliser de gerbage collector -- ces gens là étaient vraiment des visionnaires)
[^] # Re: et les bibliotheques python ?
Posté par smc . Évalué à 1.
Depuis quand la syntaxe fait-elle partie des concepts ?
[^] # Re: et les bibliotheques python ?
Posté par Pierre Tramonson . Évalué à 2.
On devrait mettre un disclaimer sur linuxfr indiquant: "attention si vous poster quelque chose concernant Fortran, attendez vous à être sévérement trollés par Ned".
[^] # Re: et les bibliotheques python ?
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Si je me trompe pas, numpy utilise par exemple BLAS et LAPACK.
[^] # Re: et les bibliotheques python ?
Posté par Troy McClure (site web personnel) . Évalué à 2.
Et pourtant ils (les devs de numeric numarray numpy) ont eu l'idée tordue de choisir l'ordre "C" (row major) par défaut pour les matrices denses (qui n'a aucun interet puisque les tableaux multi-dimensionnels du C ne servent à rien) plutot que l'ordre "FORTRAN" (qui a l'interet justement d'etre celui utilisé par toutes ces libs et de nombreuses autres). J'ai jamais compris pourquoi.
[^] # Re: et les bibliotheques python ?
Posté par lasher . Évalué à 2.
1/ Si on a vraiment besoin de l'interface officielle, on l'a, même en C.
2/ Si on passe par une interface « C », on s'affranchit du besoin de tout passer par « référence » (càd par pointeur, vu que l'interface doit fonctionner depuis le C), ce qui, mine de rien, est plutôt une bonne chose, et permet de faire certaines optimisations quasi-impossible quand on doit gérer des cas potentiels d'aliasing à cause de gens qui se croient malins ...
Dernière chose : l'interface des BLAS prévoit un argument « row major » Vs « column major », donc je ne comprends pas où est le problème avec NumPy (que je ne connais pas). Au pire on doit spécifier l'argument et c'est tout non ?
Une dernière chose. Pourrais-tu expliciter ton les tableaux multi-dimensionnels du C ne servent à rien) ? Il n'y a pas de « vrai » tableau multidimensionnel en C, j'en conviens, mais la majorité des codes Fortran que je vois passer font une grosse allocation unidimensionnelle en début de programme, avant de les « transformer » en tableaux multidimensionnels en les passant à des fonctions/sous-routines qui justement pensent avoir à faire à des tableaux multi-D. Et ça marche très bien.
[^] # Re: et les bibliotheques python ?
Posté par lasher . Évalué à 2.
Oui enfin, devoir repasser par une syntaxe différente uniquement pour faire du calcul haute performance, c'est un peu dommage ... Par exemple en Fortran, les dimensions des tableaux sont stockées à partir de la dernière, puis en remontant (donc un tableau déclaré comme TAB(M,N,K) sera rangé suivant K, puis N, puis M), là où en C/C++/Java on stocke d'abord par rapport à la première dimension de tableau. Quand les codes sont « simples », le compilateur est capable de renverser l'ordre des boucles comme un grand, mais c'est tout à fait différent dès qu'on commence à faire des trucs un peu complexes dans des nids de boucle.
[^] # Re: et les bibliotheques python ?
Posté par Gniarf . Évalué à 2.
[^] # Re: et les bibliotheques python ?
Posté par ckyl . Évalué à 2.
Cela dit ça peut paraitre bête comme info, mais tu peux vite avoir des surprises. Itérer dans le mauvais sens sur un tableau multidimensionnel peut faire très mal aux perfs. De même savoir comment sont gérés les tableaux multidimensionnels en Java (types primitifs inclus) peut t'éviter de fâcheuses surprises plus tard.
[^] # Re: et les bibliotheques python ?
Posté par lasher . Évalué à 3.
# Performance de Jython
Posté par Tramo Piere . Évalué à 2.
http://psycle.svn.sourceforge.net/viewvc/psycle/branches/boh(...)
Il reste à voir avec l'utilisation des threads Java, par contre on y perd en portabilité :-/
[^] # Re: Performance de Jython
Posté par Antoine . Évalué à 2.
[^] # Re: Performance de Jython
Posté par Tramo Piere . Évalué à 2.
http://aspn.activestate.com/ASPN/Mail/Message/Jython-users/2(...)
http://blogs.sun.com/sundararajan/entry/java_integration_bea(...)
Malheureusement, l'utilisation des threads java n'améliore pas les perfomances de waf (testé avec un processeur dual core).
[^] # Re: Performance de Jython
Posté par Antoine . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.