Forum général.général Debat langage pour implementation de systèmes répartie

Posté par  .
Étiquettes : aucune
0
4
jan.
2008
Salut à tous...

Je réfléchie à l'écriture d'un système répartie pour des échanges de messages avec naturellement la persistance et les logs qui va avec.

Déjà la première question, c'est savoir quel langage utiliser (en gros C ou JAVA).

Cette question n'est pas anodine. Voila ce que l'on peut lire dans le livre blanc de GNUnet écris en 2002 - ce qui par conséquent est maintenant relativement vieux :

"Freenet is still under development. Recent versions had problems with excessive CPU usage and failed to acknowledge disk quotas set by the users (if not enforced by the operating system). One problem is that the Freenet server is implemented in Java. This requires every node to run a Java Virtual Machine (JVM) all the time. The memory requirements of a JVM are often not tolerable for many potential nodes."

Je n'ai malheureusement pas trouvé d'autre documentation que je qualifierais comme sérieuse (je vois trop de bench pro Java et cela m'irrisse un peu le poil et cela contredis mes benchs à moi) et donc je tente ici de monter un petit débat ouvert à tous.

Je serais très curieuse de voir les avis de chacun.

Pour moi, il me semble qu' un serveur d'échange de message écrit en JAVA équivaudrait à une perte de performance par rapport à un serveur en C... alors quand je pense à un système répartie je me dis qu'on va multiplier énormément cette perte de performance...

Merci à tous les futurs participants !!!

  • # freenet

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

    Je suis dévelopeur freenet et je confirme que c'est *vieux* :)

    Viens sur #freenet (irc.freenode.net) pour en discuter si tu veux...

    Tout dépend de la taille des messages à echanger, leur nombre, ...
    Et non, java n'est pas fondalementalement plus lent que le C, surtout pour faire ce genre de choses. La JVM met un temps certain à se charger... mais si ton programme est bien écrit elle n'est chargée qu'une seule fois.

    Je recommande la lecture de http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-jw22JavaUrbanLegends

    • [^] # Re: freenet

      Posté par  . Évalué à 1.

      "Tout dépend de la taille des messages à echanger, leur nombre, ..."

      c'est justement là la question. :) En terme d'experience MOM, je ne connais actuellement pas de serveur d'echange de messages écrit en Java et qui aient pu détroner MQSeries en terme de perf...

      "java n'est pas fondalementalement plus lent que le que le C"

      pour moi fondamentalement il l'est. Le C est compilé (qui plus peut l'etre avec des options de compil specialement étudiée) et le java non. Mais dans la pratique tu as raison: cela dépend des développeurs :)

      "mais si ton programme est bien écrit elle n'est chargée qu'une seule fois."

      En fait pour le chargement de la JVM, ce n'est pas tellement ca qui me pose problème.

      Ce qui me pose problème par exemple c'est la gestion cpu et mémoire - des developpeurs on reussit a faire utiliser 500 mo de mémoire à leur jvm pour l'affichage du suivi de 40000 transferts par exemple - peut etre n'utilisent ils pas correctement le GC ?

      De plus je trouve l'acces fichier en java lourd en terme de code par rapport a ce qui se fait en C et donc en terme de perf je me dis que ca peut avoir un impact sur les perf ?

      D' autres questions que je me posent c'est :

      1) l'exploitation des ipc en java... d'apres mes connaissance actuelle elles ne sont tous simplement pas exploitable ?
      2) l'exploitation des memoire flash... j'ai vu ici ou la des developpement java à ce propos, mais malheuresement aucun tutorial d'implementation par exemple....

      • [^] # Re: freenet

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

        >>java n'est pas fondalementalement plus lent que le que le C"

        >pour moi fondamentalement il l'est. Le C est compilé (qui plus peut l'etre avec des options de compil specialement étudiée) et le java non. Mais dans la pratique tu as raison: cela dépend des développeurs :)

        heuh... Le java est pre-compilé (transformé en bytecode) et ensuite "optimisé" à l'exécution (JIT & co)... Toutes les optimisations que tu peux avoir lors d'une compilation sont transposables au bytecode... Sauf qu'en C tu peux plus optimiser à la volée après vu qu'il n'y a pas de machine virtuelle.
        Tu n'as certainement pas lu le lien que j'ai mis dans mon message...
        Il est clair que toute machine virtuelle introduit un "overhead"... et que comparé a du code natif parfait il sera plus lent...

        La question c'est combien de temps peux-tu consacrer à optimiser/debugger ton code ? Si la réponse est "pas beaucoup" alors il n'est pas évident que ce soit plus rapide sans machine vituelle... Pour te donner un exemple, on a des parties de freenet écrit en assembleur (pour la crypto)... on a "vraiment" optimisé une section critique du code... pas le reste.

        >Ce qui me pose problème par exemple c'est la gestion cpu et mémoire - des developpeurs on reussit a faire utiliser 500 mo de mémoire à leur jvm pour l'affichage du suivi de 40000 transferts par exemple - peut etre n'utilisent ils pas correctement le GC ?

        Des gens qui savent pas coder codent dans tous les languages... dont le java, oui.

        >De plus je trouve l'acces fichier en java lourd en terme de code par rapport a ce qui se fait en C et donc en terme de perf je me dis que ca peut avoir un impact sur les perf ?

        Gnih??? parse-error.
        En quoi la "lourdeur du code" (j'interprète: de la syntaxe) peut-elle avoir un impact quelconque sur les perfs ?

        >1) l'exploitation des ipc en java... d'apres mes connaissance actuelle elles ne sont tous simplement pas exploitable ?

        Heuh, si tu connais le C et pas le java .... oui t'iras plus vite à coder en C.
        Java c'est un language de haut niveau, tu ne manipules pas les IPCs directement... prenont un exemple : la synchronisation: c'est fait à base de moniteurs (java <=1.4) et uniquement de moniteurs.

        >2) l'exploitation des memoire flash... j'ai vu ici ou la des developpement java à ce propos, mais malheuresement aucun tutorial d'implementation par exemple....

        C'est pas propre au language ça.

        • [^] # Re: freenet

          Posté par  . Évalué à 1.

          Tu n'as certainement pas lu le lien que j'ai mis dans mon message...

          non pas encore... mais je l'ai dans mes liens :)

          Le java est pre-compilé (transformé en bytecode) et ensuite "optimisé" à l'exécution (JIT & co)... Toutes les optimisations que tu peux avoir lors d'une compilation sont transposables au bytecode...

          oui c'est tout a fait ca... l'optimisation du bytecode dans ce cas ce fait au niveau de la JVM. Tu n'es donc plus responsable des optimisations systèmes en terme de compilation mais à l'execution...

          Sauf qu'en C tu peux plus optimiser à la volée après vu qu'il n'y a pas de machine virtuelle.

          evidamment il est optimisé avant (code & compil)...

          Pour te donner un exemple, on a des parties de freenet écrit en assembleur (pour la crypto)... on a "vraiment" optimisé une section critique du code... pas le reste.

          Voila une methode interessante que je serais retenir... Donc en gros la méthode Freenet ,en terme de méthodologie de développement, c'est tout faire en java et puis ensuite choper les partie de code qui ont des mauvaises perf pour les refaires en assembleurs. C'est bien ca ? L'integration de l'assembleurs avec une exec java ne pose pas trops de difficultés ? Pour la portabilités vous avez du galérer, non ? Pourquoi ne pas avoir choisi le C pour la crypto ?

          Des gens qui savent pas coder codent dans tous les languages... dont le java, oui.

          oui c'est clair. L'inconvenient du java c'est qu'il est beaucoup plus accessible et donc - de mon humble point de vue - la proportion des gens qui savent coder en java est plus faible que celle en C, d'abord parceque justement ils ne sont pas confrontés à toute les problématique pourri du C :)

          Bon maintenant, pour ce qui est des développeurs qui ont fait bouffer 500Mo à la JVM, la question n'est pas tant qu'ils ne savent pas coder, la question est aussi le temps qu'on leur a donné pour faire leur bouzin. Une autre problématique du java, c'est que comme y'a plus besoin de réfléchir sur des probleme de portabilité les commandeur reduisent drastiquement les temps de développement... et parfois un peu trops :)

          En quoi la "lourdeur du code" peut-elle avoir un impact quelconque sur les perfs ?

          Et bien plus un code est lourd à l'utilisation plus j'estime que les développeur se sont compliqués la vie et plus on se complique la vie plus les perfs sont pourries (c'est l'une de mes regles).

          Pour en revenir a l'exemple des fichiers - qui n'est qu'un exemple, si je me souviens bien en java y'a des objets input stream/ output stream alors quand C on parle juste de file descriptor. C'est cette utilisation des streams par exemple que je trouve compliqué pour atteindre un malheureux fichier... Mais peut etre ne suis je plus a jours ?

          C'est pas propre au language ça.
          non mais en fonction des languages tu peux trouver des lib/jar bien pratiques :)

        • [^] # Re: freenet

          Posté par  . Évalué à 1.

          Java c'est un language de haut niveau, tu ne manipules pas les IPCs directement
          De mon point de vue les ipc pourrait etre utilisable de la JVM. Comment fait tu pour faire parler deux process java sur le meme host ensemble ? Par réseau... Mais pourquoi pas par les IPC si c'est sur la meme machine ?

      • [^] # Re: freenet

        Posté par  . Évalué à 1.

        c'est justement là la question. :) En terme d'experience MOM, je ne connais actuellement pas de serveur d'echange de messages écrit en Java et qui aient pu détroner MQSeries en terme de perf...

        Joram d'ObjectWeb ou ActiveMQ d'Apache ?

        Et de toute façon les performances de MQSeries se dégradent aussi en fonction de la taille des messages et de la profondeur de la queue que tu utilises.

Suivre le flux des commentaires

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