trollons gaiment sur le java - Page 1

Kevin Kofler (./6429) :
Bah, les plus grands problèmes:
[ul][li](...)[/li][li]Interpréter du bytecode est forcément plus lent que du code natif bien optimisé (critique que j'ai aussi envers le Java).[/li][/ul]

bon, juste pour dire que franchement c'est idiot de dire que le java est lent, parce depuis assez longtemps il existe un jouet qui s'appelle un JIT qui est un just in time compiler et qui évite que le code java et .net soit interprété.

bordel quelle mauvaise foi quand même de pas vouloir regarder ça!

et le python alors? et le perl alors?

les dernières recherches montrent que les JIT peuvent produire du code MEILLEUR que l'asm ou le C.

Va falloir dire à Jack Dongarra, qui continue à coder ses petits outils directement en asm

squalyl (./1) :
les dernières recherches montrent que les JIT peuvent produire du code MEILLEUR que l'asm

gni ? ils exécutent des instructions dans une 4ème dimension cosmique pour aller plus vite que le proc ?

Quand tu fais du JIT, tu as des informations supplémentaires que n'a pas le compilo.

Exemple con : dans ton code, tu as
for(i = 0; i < k; i++) { [...] }

Si k < 10, alors vaut mieux dérouler la boucle,
si 10 <= k < 10000, il faut la laisser telle quelle
si 10000 <= k, alors il est plus intéressant de faire plusieurs threads quand tu as plusieurs cœurs.

Le JIT va connaître la valeur de k et pourra utiliser la bonne méthode directement, contrairement au compilo.

squalyl (./1) :

Kevin Kofler (./6429) :
Bah, les plus grands problèmes:
[ul][li](...)[/li][li]Interpréter du bytecode est forcément plus lent que du code natif bien optimisé (critique que j'ai aussi envers le Java).[/li][/ul]

bon, juste pour dire que franchement c'est idiot de dire que le java est lent, parce depuis assez longtemps il existe un jouet qui s'appelle un JIT qui est un just in time compiler et qui évite que le code java et .net soit interprété.

Bah je ne sais pas comment ils se démerdent chez Sun mais les applications Java que j’utilise ou que je développe sont souvent moins réactives que leurs équivalentes natives.

A cause de la mémoire nécessaire et du GC. Mais pas à cause du bytecode interprété.

et puis y'en a qui codent du java comme des porcs, c'est tout.

Suffit de voir Eclipse, le rapport usine à gaz/réactivité est pas mal.
Azureus, la dernière fois que j'ai testé, c'était d'une lourdeur incroyable

Pareil au boulot ici: Java est une infamie (côté client en tout cas), jamais la bonne version de la machine virtuelle, compatibilité non-ascendante, des éditeurs de JVM différentes (Sun, mais aussi IBM...)
C'est lent c'est lent. Et moche et utilisant très mal les fenêtres/contrôles etc.

Ok c'est peut-être des applis mal codées.

=>Nouveau postulat: les développeurs codent plus mal en Java.
(l'idée du ramasse-miettes, typiquement, s'il est très humain-compatible, est une catastrophe au niveau "non-gestion" de la mémoire, puisqu'une machine ne réagit pas aussi intelligemment qu'un développeur en amont qui a tout prévu.

La remarque de Flanker sur les JIT, par contre, est super intéressante, merci!

./1 C'est de la mauvaise foi dans ce sens, mais Java reste lent. Les opérations simples (bytecode pur) sont très rapides, mais dès que tu touches extensivement à l'objet ça devient vite très très lourd. Et y a pas besoin d'avoir fait des études pour ça, il suffit de faire un prog Java (en respectant ses paradigmes hein, pas du pseudo C) pour s'en rendre compte.

Flanker (./4) :
Quand tu fais du JIT, tu as des informations supplémentaires que n'a pas le compilo.

Exemple con : dans ton code, tu as
for(i = 0; i < k; i++) { [...] }

Si k < 10, alors vaut mieux dérouler la boucle,
si 10 <= k < 10000, il faut la laisser telle quelle
si 10000 <= k, alors il est plus intéressant de faire plusieurs threads quand tu as plusieurs cœurs.

Le JIT va connaître la valeur de k et pourra utiliser la bonne méthode directement, contrairement au compilo.

Tu oublies un truc fondamental là: le code est généré une seule fois par le JIT. Donc si k est variable, le JIT va pas regénérer le code à chaque fois (CA, ce serait inefficace... ), du coup on n'y gagne rien Et si k est constant et que c'est toi qui codes en ASM tu peux faire exactement la même optimisation. Pareil pour un compilo C, mais eux le feront statiquement, donc ce sera plus performant.

Brunni (./8) :
Tu oublies un truc fondamental là: le code est généré une seule fois par le JIT. Donc si k est variable, le JIT va pas regénérer le code, du coup il ne sera pas plus efficace Et si k est constant et que c'est toi qui codes en ASM tu peux faire exactement la même optimisation. Pareil pour un compilo C, mais eux le feront statiquement, donc ce sera plus performant.

C'est juste des souvenirs que j'ai d'un article de recherche que j'ai lu il y a quelques années sur le sujet, et c'est bien possible qu'il vérifie que la solution est bien toujours la meilleure.
Ils présentaient également d'autres cas où leur JIT était meilleur que la compilation statique. Mais de mémoire, ils faisaient du JIT sur du C, pas du Java : c'est bien possible que ça soit les concepts du Java qui le forcent à être lent par rapport à du C, par exemple

redangel (./8) :
=>Nouveau postulat: les développeurs codent plus mal en Java.

ça c'est très possible (lié au "donnez moi un serveur plus puissant celui là il rame", etc )

Flanker (./4) :

Si k < 10, alors vaut mieux dérouler la boucle, [...]

Ok, merci, en effet c'est pas con.

squalyl (./6) :
Azureus, la dernière fois que j'ai testé, c'était d'une lourdeur incroyable

#full-yon#

Large sur ./4 et ./6.
Eclipse charge énormément de classes au bootstrap, et la JVM "normale" (HotSpot) n'est (actuellement, du moins - vous pouvez jeter un coup d'oeil à la présentation publique d'un des devs des VMs à http://france.osgiusers.org/Meeting/200910 , même s'il n'est pas garanti que Sun-Oracle en fasse un produit) pas très optimisée pour le cold start et le multi-tâches...

La performance de la JVM "temps réel" de Sun, qui est un vrai produit, est différente. En particulier, le GC est différent.

Tu oublies un truc fondamental là: le code est généré une seule fois par le JIT.

Ca dépend des implémentations du JIT, pour autant que je sache.

Pour la performance, il ne faut pas utiliser une machine virtuelle compatible Java (ce terme désignant toute implémentation autre que celle de Sun, la seule qui puisse s'appeler JVM). Je pense en particulier à GNU Interpreter for Java (j'ai testé - juste deux fois plus lente pour une bête invocation de Maven qui durait ~15s avec la JVM).


Pour finir... remarquons que le codage comme des porcs n'est pas limité au Java (ou C#)

Non, mais le fait est que plus un langage est mainstream plus il est utilisé par des gens nuls en prog — bah oui n'y connaissant rien ils vont aller vers ce dont tout le monde parle —, donc il y a quand même une corrélation

Bon je réutilise ce topic pour répondre à Kevin (ici), puisque c'est dans le sujet et que faire 300 forks n'est pas forcément indispensable :

Kevin Kofler (./6429) :
Bah, les plus grands problèmes:[ul][li]Certaines APIs (genre W.Forms) ne sont par définition pas portables.[/li][li]Interpréter du bytecode est forcément plus lent que du code natif bien optimisé (critique que j'ai aussi envers le Java).[/li][/ul]

Le premier point est vrai, mais sauf erreur de ma part .NET a été conçu pour être une API Windows, donc par nature c'est un framework qui embarque des concepts propres à ce système. C'est vrai que c'est un aspect qui est reprochable, mais on ne peut pas non plus parler de problème de *conception*.

Pour le bytecode, tu ne confonds pas .NET et C# ? On peut tout à fait utiliser le framework .NET en C++, il n'est pas limité aux langages bytecodés.

L'exemple donné du JIT n'est pas le plus probant. Je crois avoir lu que la lenteur du code natif vient du polymorphisme, la virtualtable ne peut pas faire un truc efficace pour tout execution alors qu'un JIT peut restructurer pour adapter aux besoin a l'execution et optimiser a court terme.

Mais je rejoins tout le monde car de toute facon pour arriver du java plus rapide que du natif, je pense qu'il faut deja etre un roxor en C/asm, comprendre le fonctionnement du JVM & co et c'est clairement pas le cas des programmeurs java en general.

onur (./15) :
Mais je rejoins tout le monde car de toute facon pour arriver du java plus rapide que du natif, je pense qu'il faut deja etre un roxor en C/asm, comprendre le fonctionnement du JVM & co et c'est clairement pas le cas des programmeurs java en general.

C'est juste pas possible, le langage veut qu'il y ait une abstraction par rapport à la façon de faire des processeurs usuels, du coup même si tu t'y connais et que tu sais ce qui serait rapide, Java ne te permettra juste pas de le faire (par exemple passer des paramètres in/out via la pile).

y'a pas de in/out en java, tout est in.

et la virtual table, ça n'a rien a faire dans une conversation qui parle de "JIT". ce sont des concepts totalement disjoints.

squalyl (./1) :
bon, juste pour dire que franchement c'est idiot de dire que le java est lent, parce depuis assez longtemps il existe un jouet qui s'appelle un JIT qui est un just in time compiler et qui évite que le code java et .net soit interprété.

C'est quand-même moins efficace que du code déjà compilé. Ça coûte du temps, de compiler.

et le python alors? et le perl alors?

Ils rament aussi, C/C++ FTW!

les dernières recherches montrent que les JIT peuvent produire du code MEILLEUR que l'asm ou le C.

Ce n'est pas ce que montrent les résultats pratiques.

Et les compilateurs font des progrès sur l'analyse statique, l'optimisation interprocédurale etc., donc on pourra retrouver pas mal de ces optimisations aussi dans les compilateurs AOT, même si c'est plus compliqué (et pas possible dans 100% des cas, cf. halting problem, mais heureusement le code utilisé en pratique n'est pas totalement imperméable à l'analyse statique). Il y a aussi le profile feedback qui peut aider.

Zephyr (./14) :
Pour le bytecode, tu ne confonds pas .NET et C# ? On peut tout à fait utiliser le framework .NET en C++, il n'est pas limité aux langages bytecodés.

Le CIL (le bytecode .NET) est quand-même un composant essentiel de .NET.

squalyl (./17) :
y'a pas de in/out en java, tout est in.

Il y a du in/out, mais il faut allouer un tableau d'un élément.

Kevin Kofler (./18) :

et le python alors? et le perl alors?

Ils rament aussi, C/C++ FTW!

Bah on s'en fout, 10 fps suffisent pour un jeu

Flanker (./4) :
Quand tu fais du JIT, tu as des informations supplémentaires que n'a pas le compilo.

Exemple con : dans ton code, tu as
for(i = 0; i < k; i++) { [...] }

Si k < 10, alors vaut mieux dérouler la boucle,
si 10 <= k < 10000, il faut la laisser telle quelle
si 10000 <= k, alors il est plus intéressant de faire plusieurs threads quand tu as plusieurs cœurs.

Le JIT va connaître la valeur de k et pourra utiliser la bonne méthode directement, contrairement au compilo.

J'ai un doute sur la dernière remarque (que j'ai mise en gras). J'aimerais bien savoir comment fait le JIT pour décomposer la boucle en plusieurs threads et gérer les accès mémoire concurrent et la cohérance.
Parce que pour moi parallèliser ce genre de boucle directement même avec x milliards d'itérations, c'est impossible:

for (i = 1; i <= k; i++){
  A[i] =A[i-1]+B[i];
  B[i+1]= C[i] + D[i];
}

A moins que JIT ne transforme le code en:

A[1] = A[0] + B[0];
for (i = 1; i <= k - 1; i++) {
  B[i+1] = C[i] + D[i];
  A[i+1] = A[i] + B[i+1];
}
B[k+1] = C[k]+D[k];

Si oui, comment fait-il ?

geogeo (./21) :
Si oui, comment fait-il ?

Nan mais je suis prêt à parier qu'ils ne font rien de tout ça. C'est du troll, comme ceux qui disent que l'exécution avec un Garbage Collector est plus rapide qu'avec des malloc/free, en s'appuyant sur le fait qu'il existe des cas où la primitive "new" s'exécute plus rapidement dans cet environnement puisqu'il n'a pas à trouver un bloc vide...

Avant de lire ce topic, je pensais que le JIT consistait "simplement" en une compilation des blocs de codes les plus fréquemment exécutés. Même si ça me semble a priori logique qu'on dispose au runtime de plus d'informations qu'en temps de compilation, vous êtes sûr que certaines sont utilisées, et savez lesquelles ? Parceque moi non plus, l'exemple de Flanker ne me semble pas crédible (j'ai du mal à croire qu'on puisse envisager une compilation en plein milieu de l'exécution d'un programme, sauf peut-être si on s'apprête à lancer une boucle vraiment monstrueusement grosse ?)

Zephyr (./23) :
vous sûr que certaines sont utilisées, et savez lesquelles ?

Tu as encore , hein ?

roh, j'ai juste oublié un mot

(édité, merci ^^)

Kevin Kofler (./19) :

squalyl (./17) :
y'a pas de in/out en java, tout est in.

Il y a du in/out, mais il faut allouer un tableau d'un élément.

Ouais d'accord c'est sûr que si tu codes du java comme ça...

squalyl (./26) :

Kevin Kofler (./19) :
Il y a du in/out, mais il faut allouer un tableau d'un élément.

Ouais d'accord c'est sûr que si tu codes du java comme ça...

Ben quoi? Souvent tu n'as pas le choix, si tu veux "retourner un résultat composé" tu vas soit faire une classe anonyme soit retourner un objet comme résultat. Dans tous les cas ça revient au moins au même qu'allouer un tableau d'un élément question complexité...

Zephyr (./23) :
Avant de lire ce topic, je pensais que le JIT consistait "simplement" en une compilation des blocs de codes les plus fréquemment exécutés. Même si ça me semble a priori logique qu'on dispose au runtime de plus d'informations qu'en temps de compilation, vous êtes sûr que certaines sont utilisées, et savez lesquelles ? Parceque moi non plus, l'exemple de Flanker ne me semble pas crédible (j'ai du mal à croire qu'on puisse envisager une compilation en plein milieu de l'exécution d'un programme, sauf peut-être si on s'apprête à lancer une boucle vraiment monstrueusement grosse ?)

En fait ce n'est même pas par blocs, c'est une granularité moins fine, du genre par classe ou par méthode (enfin dans les VM objet courantes).

Et heu en effet, je ne connais pas de VM objet qui recompile aussi finement que le décrit flanker. D'autant que compiler une version ou les trois ne coûte pas beaucoup plus cher et un test à l'exécution sur un registre ça ne coûte plus rien sur les procs modernes...
D'ailleurs, la plupart des optims dont on a parlé dans ce topic existent déja dans les compilos. Les compilos C++ corrects font de la monomorphisation (une version pour les int une pour les pointeurs et une pour les flottants pour faire simple), donc il n'y a plus le coût du polymorphisme, mais ça coûte en espace disque/ram du binaire et ça multiplie le temps de compilation (ou en recherche des trucs comme MLton le font carrément au link pour tout le programme, c'est très long mais produit du code très efficace). La plupart des compilos et JIT évitent de trop monomorphiser pour rester raisonnable en espace et temps de compilation.

D'autre part, un JIT ça se base quand même sur une VM, avec un jeu d'instructions spécifiquement adapté à un type d'exécution, et donc beaucoup d'optims ne sont pas possibles à cause de ce langage intermédiaire parfois trop restrictif pour produire du code efficace pour certains styles de programmation (pas de récursion terminale facile en Java, pas d'exceptions rapides, politique de boxing (encapsulation des valeurs immédiates dans des wrappers objets), etc.).

En bref, les JIT c'est bien mais c'est pas le rêve et ça ne permet pas de faire beaucoup mieux qu'un compilo classique (dans certains cas oui, dans d'autres c'est l'inverse).

Java, c'est pas plutot sexe accordéon et alcool ?

Brunni (./22) :

geogeo (./21) :
Si oui, comment fait-il ?

Nan mais je suis prêt à parier qu'ils ne font rien de tout ça. C'est du troll, comme ceux qui disent que l'exécution avec un Garbage Collector est plus rapide qu'avec des malloc/free, en s'appuyant sur le fait qu'il existe des cas où la primitive "new" s'exécute plus rapidement dans cet environnement puisqu'il n'a pas à trouver un bloc vide...

Pour avoir fait des benchs dessus, quand tu travailles avec des classes métier (genre une classe "personne") c'est souvent plus efficace parce qu'en plus de ne pas réallouer la mémoire quand tu réaccèdes à un objet, tu économises souvent un accès base avec...