Nouvelles machines Java IBM pour Linux

Posté par  . Modéré par Benoît Sibaud.
Étiquettes : aucune
0
22
avr.
2002
Java
IBM vient (en fait je sais pas trop quand, mais je n'ai pas vu d'autres dépêches) de diffuser de nouvelles machines java pour Linux avec les SDK associés. Il ne s'agit pas de SDK et de machines pour java 1.4. C'est bien dommage.

Au sommaire, on a donc un JVM 1.3.1 pour linux sur X86 ET (oui il y a un et cette fois-ci) une JVM 1.3.0 avec du JIT (just in time) pour linux PPC. Beaucoup plus rapide que la jvm blackdown sur cette même plateforme car cette dernière n'a pas de JIT.

Je rapelle que le JIT est la technique qui consiste à recompiler à la volée le bytecode de la JVM en du code natif. Ca nécessite donc un peu d'overhead au démarrage de l'appli, mais l'exécution est bien plus rapide.

Il y a aussi des JVM pour Linux sur zSeries, mais ca intéresse moins de monde.

Aller plus loin

  • # Blackdown ?

    Posté par  . Évalué à 10.

    Dites quelqu'un sait où ils en sont de j2sdk 1.4 ?
    Depuis les déclarations de sun sur l'open source (cf les discussions entre apache et sun) je pensais que blackdown pourrait enfin sortir en licence libre, et donc être intégrée à Debian,Redhat et les autres par défaut...

    • [^] # Re: Blackdown ?

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

      Franchement, la JVM blackdown en open source, j'y crois pas trop. Sauf erreur de ma part, les modifications de portage effectuée par blackdown sont déjà en GPL (avec des clauses d'exception, étant donné que la GPL n'est pas compatible avec la licence "open source" de Sun). Mais comme l'essentiel de la JVM vient de Sun, il faudrait que Sun passe son code sous une licence open-source. A mon avis, ce n'est pas pour demain (sauf peut être si IBM rachète Sun, sait-on jamais).

      La discussion apache/sun ne porte pas sur le code de Sun, mais plutôt sur ce qui sort du community process, c'est-à-dire les spécifications (cf http://jakarta.apache.org/site/jspa-agreement.html(...) ). En gros, Sun est d'accord pour que Java (en tant que plateforme, c'est-à-dire la JVM et surtout les apis) soit implantable en open source et donnera gratuitement les programmes permettant les tests de compatibilité d'une implantation avec le standard (ce don n'est prévu que pour les implantations open-source). De plus, une implantation open source compatible pourra être qualifiée et donc obtenir le droit de se revendiquer Java officiellement (exit les problèmes actuels d'implantation en open source de J2EE). Enfin, Sun aidera les groupes open source (lire apache, à mon avis) à passer les tests (aide financière et humaine, a priori).

      C'est sûr qu'on est loin des brevets puants de MPEG 4, mais bon, ce n'est pas encore de l'Open source.

  • # Intêret d'upgrader la JVM

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

    Perso, j'ai une JVM Blackdown 1.3.1 sur ma workstation @Home qui marche très bien (que ce soit en plugin Web ou en console).

    Est-ce que cette JVM d'IBM est vraiment plus performante ?

    • [^] # Re: Intêret d'upgrader la JVM

      Posté par  . Évalué à 10.

      Oui. Bien plus performante.
      Les performance sur X86 sont bien meilleurs. EN ce qui concerne le powerPC c'est encore plus flagrant car blackdown n'a pas de JIT sur cette plateforme.

      Voilà un lien vers les bench volcano. Il font référence (oui ? non ? je me trompe ??)

      http://www.volano.com/benchmarks.html.(...)

      Now si tu veux tester ta JVM sur ta machine
      http://serge.rossi.free.fr/javabench.html(...)

      • [^] # Re: Intêret d'upgrader la JVM

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

        Volano (attention au point à la fin de ton url http://www.volano.com/benchmarks.html(...) ), c'est très intéressant comme bench, mais c'est fondamentalement merdique. En effet, le serveur utilise un très grand nombre de threads afin d'obtenir des entrées/sorties non bloquantes. C'est effectivement une technique (obligatoire en java 1.x avec x<4), mais c'est très coûteux en terme de performance pour le système.

        En fait, un programme blindé de threads fait ramer une machine, qu'il soit programmé en java, en C, en C++, etc. C'est la multiplication des threads qui pose problème. De ce fait, Volano donne une mesure de qualité d'une JVM, mais pour une application très particulière, ce qui n'est pas vraiment généralisable. Il existe d'autres benchs qui testent d'autres aspects, comme par exemple ceux inclus dans la bibliothèque de calcul matriciel colt (cf http://tilde-hoschek.home.cern.ch/~hoschek/colt/(...) ). Cependant, de façon assez générale, les machines IBM restent les plus rapides.

        Une note au passage, un des intérêts (entre autres !) du jdk 1.4 est de proposer des entrées/sorties non bloquantes basées sur le principe de l'appel system select (en général, c'est beaucoup plus efficace qu'avec plein de thread).

        • [^] # Re: Intêret d'upgrader la JVM

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

          De ce fait, Volano donne une mesure de qualité d'une JVM, mais pour une application très particulière, ce qui n'est pas vraiment généralisable.

          C'est vrai que le bench Volano mesure sur des taches "particulières". Mais IHMO, il donne une bonne échelle des perfs des JVM dans une utilisation "serveur" (moteur Servlet par ex.). C'est une utilisation assez courante de Java maintenant (si ce n'est la principale).

          Justement, j'avais remarqué que la JVM Blackdown s'en sortait bien au Volano Bench : assez lente mais possibilité de montée en charge bonne.

          • [^] # Re: Intêret d'upgrader la JVM

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

            Je suis plus mitigé. Je pense que le modèle Volano n'est pas le bon pour les applications serveurs, parce qu'il correspond à un cas vraiment très particulier. Dans un serveur normal, on ne démarre pas 1000 threads, on utilise un pool de threads par exemple. De plus, la version 1.4 du jdk permet l'utilisation de construction à la select et donc rend obsolete une partie de la solution volano (à mon avis).

            Je suis bien d'accord avec toi sur l'importance pour Java du côté serveur. Il y a justement tout un travail en ce moment sur l'évaluation des performances des moteurs de servlet, d'EJB, etc. On trouve un article très intéressant à ce sujet sur http://www.cs.rice.edu/CS/Systems/DynaServer/index.html(...) On y découvre que l'essentiel du temps de calcul est perdu dans les communications entre les couches de l'application multi-tier proposée. Sauf erreur de ma part, ce genre de chose n'est pas du tout testé par Volano (il s'agit de communication RMI, pas socket).

            Bref, tout ça pour dire que l'évaluation de performances, c'est un domaine de recherche à part entière et que c'est bien délicat.

            • [^] # Re: Intêret d'upgrader la JVM

              Posté par  . Évalué à 1.

              De plus, la version 1.4 du jdk permet l'utilisation de construction à la select Et c'est là qu'on se demande comment les developpeurs ont oser faire des serveurs en Java avant Java 1.4 ...

              • [^] # Re: Intêret d'upgrader la JVM

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

                En général, avec un pool de thread et une approche déconnectée, on arrive à faire des choses très bien en Java. En gros, tu alloues disons 50 threads (au pif) à ton appli. Quand un client arrive tu lui attribues un thread au hasard dans les threads libres et tu exécutes sa requête. Si le protocole est déconnecté, c'est-à-dire si le client se déconnecte après la réponse à sa requête, tout se passe bien. Si j'ai bien compris, Volano a une approche connectée et ils sont donc relativement obligés en Java 1.3 et avant d'avoir un thread par client, afin de garder la connexion ouverte tout en étant toujours capable de répondre aux nouveaux clients. Ce genre d'architecture ne monte pas trop en charge. Bien entendu, les io non bloquantes sont en grand pas en avant pour résoudre certains problèmes, mais ce n'était pas un problème pour certaines formes de client serveur, en particulier pour tout ce qui est basé sur HTTP qui est un protocole déconnecté. La plupart des applications Java sont justement orientées servlet, ejb et compagnie, c'est-à-dire HTTP à la base. Voilà, je suppose que ça répond à ta question (ou à ton sarcasme, mais bon...).

                • [^] # Re: Intêret d'upgrader la JVM

                  Posté par  . Évalué à -5.

                  bah comme tu l'as dit plus haut , plus de thread == plus de charge ... donc avant le 1.4 , java c'etait forcement plus lourd qu'autre chose ... donc meme pour un serveur HTTP , en cas de forte charge , c'est ( etait ) pourri . ... m'enfin c'est juste un sarcasme ;)

                  • [^] # Re: Intêret d'upgrader la JVM

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

                    C'est surtout une connerie. Avec des raisonnements aussi foireux, on abandonne unix parce que la plupart des serveurs sont basés sur des process et non pas des threads et que le surcoût par rapport aux threads est non négligeable. Le truc, c'est que les performances, c'est assez compliqué. J'ai écris la version multi-thread (enfin 2 threads...) de freecraft, un clone de warcraft. Avant, la gestion du son était basée sur select, maintenant, c'est avec un thread. Il n'y aucun doute sur le fait que la solution par thread est meilleure, en particulier en cas de forte charge (l'idée est que tout rame, pas seulement le son, ce qui rend le jeu lent mais jouable). Le problème principal, c'est trop de threads. En cas de forte charge sur un serveur HTTP, il vaut mieux 50 threads (apache 2.0) que 50 process (apache 1.x). Mais bon, arrêtons de nourrir ce mini-troll.

Suivre le flux des commentaires

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