Jython supporte maintenant Python 2.5

Posté par  (site web personnel) . Modéré par Mouns.
Étiquettes :
14
19
juin
2009
Python
Le 8 juin dernier, la version 2.5.0 de Jython a été publiée. Pour rappel, c'est un interprète Python écrit en Java. Cette nouvelle version supporte désormais les fonctionnalités de Python 2.5 (version de Python sortie en 2006, voir les nouveautés de Python 2.5).

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

  • # Ah ah ! Trop gros ça ne passera pas !

    Posté par  (site web personnel) . Évalué à -2.

    Pour la news du vendredi c'est un troll de qualité qu'on nous offre : python et java réuni ensemble c'est du lourd !

    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  . Évalué à 1.

      Le support du multithreading ?
      • [^] # Re: Ah ah ! Trop gros ça ne passera pas !

        Posté par  . Évalué à 1.

        • [^] # Re: Ah ah ! Trop gros ça ne passera pas !

          Posté par  . Évalué à 1.

          Je n'y connais pas grand chose mais le soucis n'est pas sensé avoir été au moins partiellement résolu depuis Python 2.6 - et même avant - via le module multiprocessing ?
          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  . Évalué à 4.

            Le multiprocessing c'est différent du multithreading.

            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  . Évalué à 2.

              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.


              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  . Évalué à 2.

                Tu as tout à fait raison. Mais passer par un segment de mémoire partagé, ou un fichier mappé demande à la fois de le créer explicitement ET de faire attention à ce qu'on en fait ... Quelque part, je trouve que c'est le pire des deux mondes (multiprocessus Vs multithread). :-)

                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  . Évalué à 2.

          Dommage qu'il n'y ait pas eu une introduction sur ce que doit apporter Jython et son positionnement par rapport aux autres solutions dans la dépêche, comme par exemple la possibilité d'utiliser des class java, un lien vers ton pdf (ou mieux un résumé).

          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  (site web personnel) . Évalué à 4.

            Bah certe j'ai été un peu agressif mais l'avantage de ce genre de commentaire et de permettre a tout ceux qui connaissent le logiciel de le défendre en donnant des arguments pour t'aider a mieux comprendre l'intérêt d'un tel logiciel.

            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  (site web personnel) . Évalué à 6.

      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 ?

      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  . Évalué à -3.

        Donc faire tourner python sur un interpréteur libre qui tourne sur un interpréteur propriétaire. Debian va devoir créer une nouvelle branche en plus de contrib :)

        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  . Évalué à -3.

          Pourquoi je me fait moiniser ? On a pas le droit de parler de licence ?
          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  . Évalué à 1.

            Je ne vois pas où est le problème. A l'exception éventuelle d'écueuils juridiques particuliers, la licence GPL n'impose pas que la machine (virtuelle ou physique) qui execute le programme soit placée elle-même sous licence GPL.

            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  . Évalué à 3.

              A l'exception éventuelle d'écueuils juridiques particuliers, la licence GPL n'impose pas que la machine (virtuelle ou physique) qui execute le programme soit placée elle-même sous licence GPL.

              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  . Évalué à 8.

            Tu te fais moinsser par ce que ton commentaire ne sert à rien.

            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  . Évalué à 3.

          Ta tentative de trolls multiples est caduque : jython fonctionne sur les implémentations libres de java.
      • [^] # Re: Ah ah ! Trop gros ça ne passera pas !

        Posté par  . Évalué à 2.

        La notion de vitesse est relative. C'est clair que par rapport à python, c'est plus performant, mais après…

        Envoyé depuis mon lapin.

        • [^] # Ça passe très bien :)

          Posté par  . Évalué à 10.

          Oui, faut quand même dire que c'est plus performant que la majorité des interpréteurs Python...

          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  . Évalué à -6.

            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).

            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  . Évalué à 9.

              Il est tout pourri ton benchmark.

              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  . Évalué à 10.

              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  . Évalué à 3.

                Génial, la CSS par défaut de LinuxFr connaît plus les blockquotes.
              • [^] # Re: Ça passe très bien :)

                Posté par  . É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  . É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  . Évalué à 4.

                Je tiens à dire que je trouve les remarques de bonne qualité et je suis content d'avoir une discussion dans ce domaine. Ça m'a fait apprendre des choses.

                Envoyé depuis mon lapin.

            • [^] # Re: Ça passe très bien :)

              Posté par  (site web personnel) . Évalué à 5.

              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.


              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  . Évalué à 3.

                Je viens de copier coller ton code. Entre temps j'ai changé d'ordinateur.

                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  . Évalué à 1.

                  Ta JVM est en mode client, mode avec lequel la JVM démarre légèrement plus rapidement mais optimise moins le code.
                  Tu peux déjà essayer en mode server (rajouter -server) à la ligne de commande.
                  • [^] # Re: Ça passe très bien :)

                    Posté par  . Évalué à 2.

                    ...mais attend beaucoup plus avant de faire passer le JIT (1000 contre 10000 passages IIRC). Le mode client ou serveur ne change pas énormément le temps de démarrage, par contre le compilateur JIT fait des choses beaucoup plus complexes: http://java.sun.com/products/hotspot/whitepaper.html#client. Sur un bench tout con avec juste un main, tu passes très peu de temps dans le JIT (-XX:+PrintCompilation) donc le temps de chargement est très court quelque soit le mode (~0.2s chez moi). Par contre sur une vraie appli le warmup sera plus lent le temps de profiler/compiler/profiler/recompiler/etc. tout ce qu'il faut.

                    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  . Évalué à 2.

                      Le code, là c'est celui du dessus.

                      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  . Évalué à 9.

                        > La seule chose qui change avec le miens

                        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  . Évalué à 2.

                          Et bin heureusement que j'ai écris avant mon bench que «Juste pour rigoler, je viens de m'amuser à faire un tout petit test de mauvaise qualité.».

                          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  . Évalué à 5.

                            > Je te dit pas si j'avais fait le truc présenté sérieusement…

                            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  . Évalué à -1.

                              Si tu lisais mes messages, ce serait mieux pour faire avancer le débat.

                              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  . Évalué à 7.

                                > Si critiquer le travail, c'est insulter, je te souhaite bien du bonheur.

                                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  . É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  . Évalué à 1.

                    Effectivement, en mode serveur, le meilleur résultat que j'ai obtenu donne:
                    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  . Évalué à 1.

                  Sous Mac, c'est Apple qui développe la JMV, et non plus Sun... Y aurait-il là une explication ?
                  • [^] # Re: Ça passe très bien :)

                    Posté par  . Évalué à 3.

                    Faux ils ne la développe pas il la distribue, intègrent, (laissant au passages des failles critiques béantes pendant des mois) comme MS avant qu'ils se fassent retirer ce droit.
                    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  . Évalué à 2.

                      Notre ami fait tourner son truc sur un powerpc G4. Hotspot n'a jamais eu de backend pour powerpc supporté ou pblié par Sun.

                      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  . Évalué à 2.

                      Ah oki... Autant au temps OTAN pour moi, dans ce cas !
            • [^] # Re: Ça passe très bien :)

              Posté par  . Évalué à 5.

              T'as pas trouvé un bench plus mauvais et plus pathologique ? Tu cumules:
              - 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  . Évalué à 1.

                Non mais c'est une boucle…

                Ç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  . Évalué à 8.

                  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 ? 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.

                  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  . Évalué à 3.

                    J'aime bien ton explication. C'est vrai que gcc doit optimiser l'appel de la fonction, mais dans ce cas, pourquoi java ne le ferais pas ?

                    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  . Évalué à 4.

              Je me suis amusé à coder le problème des parcours de chevaux aux échecs qui doivent remplir une grille, en utilisant un code le plus semblable possible (sans utiliser les librairies spécifiques des différentes langages).

              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  . Évalué à 2.

                Le prog python des petits chevaux lancé avec ce nouveau jython me donne 531s
                • [^] # Re: Ça passe très bien :)t

                  Posté par  . Évalué à 4.

                  Avec l'option -server ça descend à 150s, je ne savais pas qu'il y avait tant de différence entre le mode server et client...
                  • [^] # Re: Ça passe très bien :)t

                    Posté par  . Évalué à 3.

                    Oui en fait j'ai dit une connerie plus tôt car j'étais resté sur des benchs d'il y a plusieurs années, mais Jython a beaucoup de retard côté perf. C'est con qu'ils n'aient pas mutualisé avec JRuby qui lui est plutôt performant (plus que Groovy, mais moins que Clojure ou Scala).
                    • [^] # Re: Ça passe très bien :)t

                      Posté par  . Évalué à 2.

                      Un blog intéressant sur l'évolution de JRuby est le suivant:
                      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  . Évalué à 2.

            Le problème, c'est qu'il n'y a rien en face

            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  . Évalué à 0.

              Je connais D, mais il s'inscrit encore une fois dans une logique de fragmentation des langages. D'ailleurs, il y a eu une discussion sur Slashdot il y a quelques mois, où l'auteur à participé, et le consensus général était "oui mais non".
              • [^] # Re: Ça passe très bien :)

                Posté par  . Évalué à 2.

                et ? sans ta "fragmentation des langages" on en serait encore à tcl ou pire on serait resté scotché à uniquement sed/awk dans un shell bien primitif. merci du cadeau.

                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  . Évalué à 2.

                  Il y a une différence entre écrire un nouveau langage qui s'inscrit dans une logique de réutilisabilité dans le cadre d'une tâche spécifique, et écrire un nouveau langage à part qui répond à un besoin inexistant.

                  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  . Évalué à 2.

                    tu ne connais visiblement pas D qui répond à un besoin existant (étendre C sans sombrer dans la complexité de C++), apporte des concepts nouveaux par rapport à C et même C++ ou Objective C, et qui a connu son heure de gloire grace à quelques jeux à la con écrit par des japonais (en particulier Torus Trooper)

                    voili voilou.
                    • [^] # Re: Ça passe très bien :)

                      Posté par  . Évalué à 2.

                      Je connais D et les seuls concepts qu'il apporte existent déjà dans de nombreux langages industriels next-gen (et depuis des décennies dans les langages de recherche). Oui D c'est C++ sans les horreurs de C++ (donc mieux que C++, avec beaucoup moins de compatibilité et de visibilité avec l'existant), mais à mon avis c'est peine perdue de se lancer dans un autre langage sur le modèle de C++/Objective-C qui est sont perte de vitesse. Tu me diras sans doute qu'Objective-C marche grâce à Apple et à l'iPhone, mais ce qui marche c'est le lock-in, si les développeurs avaient le choix à mon avis peu utiliseraient Objective-C.

                      Pourquoi se faire chier avec encore un autre langage impératif...
                      • [^] # Re: Ça passe très bien :)

                        Posté par  . Évalué à 4.

                        je note surtout ici des travers gros comme une maison : une intolérance crasse envers les langages dit impératifs, la peur classique de la fragmentation d'un domaine que tu connais pour l'instant assez bien, et pourtant l'émerveillement face au foisonnement de nouveaux langages pour un zigouigoui donné, ici la JVM...
                        • [^] # Re: Ça passe très bien :)

                          Posté par  . Évalué à 3.

                          C'est pourtant simple, je pense à moi ! Si un nouveau langage (comme D) commence à être utilisé mais n'apporte aucun confort de programmation ou n'est que la redite d'un truc fait 50x, je vais pas avoir envie de l'utiliser. D, c'est ce qu'aurait pu être Java sans VM, avec quelques trucs mieux faits (fort heureusement). J'aime pas Java, j'ai aimé C++ pour tout ce qui n'est pas dans D (tous les petits détails de merde que j'abhorre désormais parce que j'ai plus que ça à foutre me faisaient triper comme un malade)... Alors vraiment il n'y a aucune raison que j'aime D (pour être honnête, j'aime le design par contrat mais ça a déjà été fait dans Eiffel, et ça peut être fait avec des annotations Java). Comme d'ailleurs tout le monde, parce que malgré les efforts acharnés (et presque pathétiques) de son auteur, il n'a percé nulle part.

                          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  . Évalué à 2.

                            donc toi ça te ferait chier de bosser sur disons D qu'un autre toto aurait choisi, mais ça te ferait plaisir de choisir disons Clojure ou Scala, juste suivant ton humeur ? sans passer pour un toto pour avoir choisi un langage à la con dans ton coin malgré le coté "grosse entreprise" donc très sérieux toussa ?

                            *gratte* *gratte*
                            • [^] # Re: Ça passe très bien :)

                              Posté par  . Évalué à 2.

                              Euh, mais tu as suivi ou pas ? :)

                              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  . Évalué à 2.

                                Ça doit être sympa à maintenir une application d'entreprise codée en Java, Scala, Clojure, Ruby, Python, et Javacript en même temps (bon d'accord, peut-être pas tous en même temps).

                                Envoyé depuis mon lapin.

                                • [^] # Re: Ça passe très bien :)

                                  Posté par  . Évalué à 2.

                                  C'est toujours plus facile que de maintenir une distribution GNU/Linux avec 20 langages facile avec des versions parfois différentes.

                                  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  . Évalué à 1.

                                    Tu es en train de comparer la maintenance d'une application d'entreprise avec la maintenance d'une distribution linux quand même.

                                    J'aimerais pas être chef de projet pour une application en jvm.

                                    Envoyé depuis mon lapin.

                              • [^] # Re: Ça passe très bien :)

                                Posté par  . Évalué à 2.

                                alors donc euh tu programmes pour la JVM qui comme son nom l'indique est une machine virtuelle et tu dis que les autres n'ont qu'à coder pour la JVM eux aussi, ils choisissent le langage qu'ils veulent, et que si c'est bien fait si tout est modulaire tout ira bien.

                                *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  . Évalué à 2.

                                  La différence c'est que la JVM c'est pas un langage, c'est une plateforme, et que ça rend les langages qui la ciblent compatibles de façon transparente et automatique. Je peux créer un paquet sous forme de JAR et le déposer dans un conteneur et le langage que j'aurai utilisé n'imposera aucun choix sur le reste des applications qu'elles utilisent mon propre code ou non, excepté d'utiliser la dite plateforme. Maintenant, si tu veux pas comprendre l'intérêt, je vais pas te forcer.
                                  • [^] # Re: Ça passe très bien :)

                                    Posté par  . Évalué à 4.

                                    tu éludes gentiment le fait que si tu codes en Jakouski, un de tes langages fétiches qui visent la JVM, la personne qui passera derrière toi pour maintenir, réparer ton code devra apprendre le Jakouski.

                                    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  . Évalué à 2.

                                      Non, je ne l'élude pas.

                                      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  . Évalué à 1.

            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é.

            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  . Évalué à 2.

              Effectivement, les comparaisons de performance dépendent de beaucoup de facteurs. Si une fonctionnalité est appelée plus souvent dans un programme particulier qu'une autre, l'optimisation sur cette fonctionnalité est plus importante. La façon dont Jython va traduire le code Python importe donc, et les optimisations de Jython en plus de celles de la JVM.

              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  . Évalué à 1.

                Justement, Waf utilise pas mal de facteurs différents: lancement de processus, lecture de fichiers, analyse syntaxique (préprocesseur), programmation concurrente.

                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  . Évalué à 4.

              Je me risquerais pas sur jython mais pour JRuby c'est une pratique courante de déployer du RoR dans un container J2EE via JRuby: http://jxh.bingodisk.com/bingo/public/presentations/JHoffman(...) (vers les pages 110)

              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  . Évalué à 4.

            faut quand même dire que c'est plus performant que la majorité des interpréteurs Python...

            Des références concrètes ?
            • [^] # Re: Ça passe très bien :)

              Posté par  . Évalué à 1.

              Tu as lu le PDF que j'ai joint plus haut ?

              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  . Évalué à 3.

                C'est pas assez concret ?

                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  . Évalué à 2.

                  A l'heure où le multi coeur s'impose, juste pour les midinettes pas parce qu'on atteint des limites techniques en terme de miniaturisation, Python, degrade encore plus les performances que sur un mono-coeur.

                  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  . Évalué à 2.

                    A l'heure où le multi coeur s'impose, juste pour les midinettes pas parce qu'on atteint des limites techniques en terme de miniaturisation, Python, degrade encore plus les performances que sur un mono-coeur.

                    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  . É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  . Évalué à 3.

                        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.


                        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  . Évalué à 3.

    est-ce que jython permet d'utiliser des libs telles que PIL ou wxPython ou numpy ?
    • [^] # Re: et les bibliotheques python ?

      Posté par  . Évalué à 1.

      Non, non et non.

      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  (site web personnel) . Évalué à 3.

        il y a Fortress qui est basé sur les concepts de Fortran

        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  . Évalué à 1.

          Et si t'allais voir le site et la tronche du code au lieu de troller :).

          Depuis quand la syntaxe fait-elle partie des concepts ?
          • [^] # Re: et les bibliotheques python ?

            Posté par  . Évalué à 2.

            Comment veux tu empêcher Ned de troller sur Fortran ?

            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  (site web personnel) . Évalué à 3.

          De très nombreuses bibliothèques de calculs reposent sur BLAS et LAPACK dont les implémentations de références sont écrites en Fortran. C'est du code éprouvé depuis une treinte d'années, alors pourquoi y retoucher ? Il suffit d'écrire un petit surcouche pour les utiliser dans Python / Java / ...

          Si je me trompe pas, numpy utilise par exemple BLAS et LAPACK.
          • [^] # Re: et les bibliotheques python ?

            Posté par  (site web personnel) . Évalué à 2.

            > Si je me trompe pas, numpy utilise par exemple BLAS et LAPACK.

            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  . Évalué à 2.

              En pratique, des bibliothèques numériques non-libres, telles celles d'Intel, proposent deux version des BLAS : celles qui sont un front-end aux BLAS Fortran, et celles qui sont des « C-BLAS » (càd : tout réimplémenté en C et assembleur). Ça a deux avantages :

              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  . Évalué à 2.

        Notamment pour le calcul scientifique, il y a Fortress qui est basé sur les concepts de Fortran et qui tourne sur la JVM.

        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  . Évalué à 2.

          on est en 2009 quand même, je pense qu'il existe quelques outils depuis le temps pour s'abstraire de ce genre de conneries...
          • [^] # Re: et les bibliotheques python ?

            Posté par  . Évalué à 2.

            Pour 99.99% des projets c'est futile comme problème. Le HPC est un monde à part où écrire un compilo dédié ou du code jetable avec la machine peut encore avoir un sens :-)

            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  . Évalué à 3.

              D'ailleurs pas plus tard qu'il y a deux semaines, j'ai eu un code à modifier. Le programmeur avait implémenté son algorithme, en prenant soin d'optimiser le mieux possible, mais n'avait pas vu que le parcourt des tableaux 2D et 3D dans les boucles les plus internes provoquaient énormément de défaut de cache, ce qui ralentissait énormément la fonction (et comme cette dernière prend 60% du temps d'exécution global, ça ralentissait aussi beaucoup l'application au final). En effectuant une transformation de code totalement pas « intuitive » (car on « casse » la logique de l'algorithme, même si au final le résultat reste correct), j'ai réussi à accélérer la fonction de 80% environ. Bon. Ben le compilateur était incapable de faire ce que j'ai fait à la main, tout simplement parce que le code était trop compliqué pour lui (trop de tableaux, d'accès à ceux-ci avec plusieurs itérateurs, de calculs d'indirections en sus, etc.).
  • # Performance de Jython

    Posté par  . Évalué à 2.

    Pour l'instant, le code python non modifié est plus lent sur Jython:

    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é :-/

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.