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 str000mff . En réponse au message Debat langage pour implementation de systèmes répartie. Évalué à 1.
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 :)