station__bis Voir le profil de station__bis
Posté le 24 mai 2011 à 16:09:57 Avertir un administrateur

Deuxième point : Java transformé en bytecode puis interprété par la JVM. Or le processus d'interprétation est lent. Beaucoup plus lent que le processus de lecture de code binaire

Ca c'est assez inexact...

Le bytecode java est pas interprété il est "jitté", c'est à dire compilé en code machine juste avant son exécution. Un programme java ne souffre donc que d'une pénalité réduite en vitesse d'exécution face à un programme compilé AOT, du moins une fois la première passe effectuée.

""Alors qu'en Java, on s'en fiche un peu de la vitesse... ""

La suite logique serait de dire "puis en java en s'en fout de la mémoire", on se sert de java dans des domaines suffisamment variés et exigeants pour mettre un gros trait sur cette affirmation je pense. La JVM a titre d'exemple, c'est sûrement l'une des pièces de code la plus optimisée au monde, preuve qu'on s'en fout pas tant que ça.

En effet, le code java est jitte. Cependant j'ai l'impression que le compilateur qui est utilise est assez peu efficace. J'avais lu des tests qui indiquaient que la JVM n'utilisait pas les instructions de calcul vectoriel du processeur.

Deplus, la couche de compilation rend l'utilisation efficace des caches par l'utilisateur difficile. Je ne pense pas que tu puisse exprime que tu souhaite que telle donnne et telle donnee soient proche en memoire. Dans mon experience, c'est le type d'optimisation en C ou C++ qui amene des enormes gain en terme de temps de calcul. Cependant, java pourrait analyser les access memoires des differents objets et les stocker proches en memoire. Mais je n'ai pas l'impression qu'il fasse ca.

Cependant, on peut toujours ecrire du code java et descendre dans les interfaces natives quand on a besoin...

Proche en mémoire dans quel sens? Tu n'as pas de contrôle fin de l'endroit exact ou un objet est alloué, mais il y a une idée reçue fausse qui prétend qu'un "new" en java est l'équivalent d'un "new" en C++ (càd plus ou moins un appel à malloc en C), si c'est de ça que tu parles.

En C, si j'ai differentes structures de donnees qui sont petite et utilise souvent. Il est preferable d'allouer un bout de memoire pour les stocker tous. Ainsi, ils sont physiquement proche en memoire.
Hier encore, j'ai alloue un premier tableau de double entre alloc et alloc+sizeof(double)*lengthArrayDouble et un tableau de structure complexe entre alloc+sizeof(double)*lengthArrayDouble+1 et alloc+sizeof(double)*lengthArrayDouble+1 +sizeof(structcomplexe)*lengthArraystrcomplexe.

J'ai physiquement place mes deux tableaux consecutivement en memoire. Les deux structures sont utilise tout le temps et font moins qu'une ligne de cache L2. Du fait, j'ameliore l'utilisation du cache et reduit les temps de calcul.

Je ne pense pas qu'en java, tu puisse exprimer ca. Il faut faire confiance a la machine virtuelle pour construire le graphe d'access sequentiel et decider qu'est ce qu'il faut mettre a cote. La JVM pourrait faire ca, mais ca a l'air d'etre une operation super couteuse.

J'avais aussi different tableau de structures complexe C1, C2, et C3. Et je sais que les tableaux sont basiquement utiliser de facon synchroniser: si j'utilise C1[14] probablement, je vais utiliser C2[13] ou C2[11]. Du coup, c'est interessant d'entrecaller tes allocations memoire du genre pour que la memoire soit:
C1[0], C2[0], C3[0], C1[1], C2[1], C3[1], ...

et ca, ca se fait facilement en allouant un tableau de struct Aggregate {struct C1 c1; struct C2 c2; struct C3 c3;}; Avec un coup de template, tu abstrait le probleme du placement memoire.

En java, tu ne peux pas vraiment faire ca facilement a ce que j'ai vu. si tu utilise un type complexe dans une classe, tu alloue des references et probablement une fois compile tu te tape une indirection de plus et tu te repose sur la JVM pour faire tes allocations proprement. Ou alors, tu applatis la structure en copiant les champs de C1 dans aggregate. Mais c'est un peu plus moche.

C'est de ce genre de truc dont je parles. Dans plein d'appli c'est difficile a mettre en oeuvre. Mais quand tu as des applis regulieres, tu gagnes quelques pourcent de temps d'execution avec ce genre de hack.

pour les langages serveur on tend de plus en plus a utiliser du JAVA a la place du C.
étant un fervent défenseur des langages bas niveau, je doit avouer que niveau perf JAVA s'est beaucoup amélioré, on l'utilise sur nos serveur de production qui sont a ~ 60000 requêtes par secondes.

On a eu pal mal de soucis d'optim avec le GC mais dans l'ensemble ça fonctionne bien.

Par contre je trouve que ça devient rapidement le bordel en Java, quand on utilise plein de librairie.
Tu te retrouve facilement a avoir un type d'objet qui est dans 5-6 librairies différentes.

@Godrik
Non tu as effectivement pas de contrôle fin là dessus. Si ce n'est que la JVM alloue la mémoire à la demande par blocs entiers et recycle en interne cette mémoire. Je pense que si tu alloues des tableaux d'objets dont la création effective n'est pas trop dispersées, tu as de bonnes chances qu'ils soient contigus. Mais j'avoue que c'est pas mon domaine de prédilection, je sais juste que les allocations en java ont été vachement optimisées au fil du temps, mais sans bien sûr laisser tout le contrôle au développeur.

tomtomclancy Voir le profil de tomtomclancy
Posté le 25 mai 2011 à 16:16:11 Avertir un administrateur
Tu te retrouve facilement a avoir un type d'objet qui est dans 5-6 librairies différentes.

Comment ça?