Connaître les optimisations faites par la JVM

Merci pour cette modification.
En fait je souhaitais faire quelque chose de ce genre, le problème c'est que parfois j'appelle ce type de code dans un thread : je divise l'image en plusieurs bandes de tailles égales et chaque thread gère une bande. Mon problème étant que la méthode de la classe Thread est "public void run()", donc je ne peux lui passer des paramètres.
Mon idée avait donc été de créer cette méthode setParameters(...) avant d'appeler run()
Aurais tu une idée pour améliorer cela afin que JIT sache comment optimiser ?

Salut,

Citation:

---

Envoyé par ToTo13

Ce sont des petites méthodes static aussi simples qu'utiles, ne comportant qu'une seule bouche avec un seul test. C'est donc la parfaite candidate pour devenir final.

---

Le mot-clef final sur une méthode static n'aura aucun impact sur les performances : il n'y a pas de résolution de méthode à l'exécution !

De toute manière de manière globale la JVM sait très bien inliner des méthodes non-final si besoin, en particulier si elles sont "implicitement final" (si aucune des classes filles du classloader n'a redéfini la-dite méthode).

Citation:

---

Envoyé par ToTo13

Mon idée avait donc été de créer cette méthode setParameters(...) avant d'appeler run()
Aurais tu une idée pour améliorer cela afin que JIT sache comment optimiser ?

---

Il t'as donné un exemple : il faut recopier les attributs d'instances dans des variables locales, et utiliser ces dernières.






Sinon tu pourrais montrer un code complet et executable que l'on puisse lancer, et qui monterais les différences de temps d'exécution.
Je crains que tu te focalises trop sur la JVM et que le problème pourrait venir d'ailleurs...

a++

Citation:

---

Envoyé par adiGuba

Il t'as donné un exemple : il faut recopier les attributs d'instances dans des variables locales, et utiliser ces dernières.

---

Je ne comprends pas ce que tu souhaites dire là.
Dans la cas d'un thread, j'appelle d'abord la méthode setParameters afin de copier les informations nécessaires au traitement dans le tread, puis j'appelle run().
Comment faire autrement ?

Ben comme l'indique tchize_ dans ta méthode tu recopies les attributs dans des variables locales :

Code:

---

1 2 3 4 5

int param1 = this.param1; int param2 = this.param2; int sewidth = this.sewidth; int width = this.width; int height = this.height ;

---

Mais encore une fois je doute que cela viennent de là...


a++

Dans ce cas c'est exactement ce que je fais dans ma méthode setParameters(), tout est mis dans des variables private.
Comme ça lorsque j'appelle mon thread, tout les paramètres sont des variables private locales.

Citation:

---

Envoyé par ToTo13

Dans ce cas c'est exactement ce que je fais dans ma méthode setParameters(), tout est mis dans des variables private.
Comme ça lorsque j'appelle mon thread, tout les paramètres sont des variables private locales.

---

"private locale" ca ne veut rien dire. Il parlait de les recopier dans des variables locales, c'est à dire visible uniquement dans la méthode.

Mais de toute manière comme je l'ai dit je doute que ton problème viennent de cela, ni d'un détail du langage...


a++

Citation:

---

Envoyé par adiGuba

visible uniquement dans la méthode.

---

Oui mais comment faire dans le cas d'un thread, puisque la méthode appelée est run() et qu'elle ne contient aucun paramètre ?


[QUOTE=adiGuba;8335375Mais de toute manière comme je l'ai dit je doute que ton problème viennent de cela, ni d'un détail du langage...[/QUOTE]
Un problème à la fois :-)
Mais je regarde aussi d'autres possibilités.

Citation:

---

Envoyé par ToTo13

Oui mais comment faire dans le cas d'un thread, puisque la méthode appelée est run() et qu'elle ne contient aucun paramètre ?

---

Ben :

Code:

---

1 2 3 4 5 6 7 8 9

public void run() { int param1 = this.param1; int param2 = this.param2; int sewidth = this.sewidth; int width = this.width; int height = this.height ;   // ton code qui utilise les variables locales }

---

Remarque : se contenter de déclarer les attributs en final serait tout aussi efficace...

Citation:

---

Envoyé par ToTo13

Un problème à la fois :-)
Mais je regarde aussi d'autres possibilités.

---

A mon avis là tu te perds dans des détails...


a++

Citation:

---

Envoyé par adiGuba

A mon avis là tu te perds dans des détails...

---

Je sais... mais j'adore ça :-)

Citation:

---

Envoyé par adiGuba

Code:

---

1 2 3 4 5 6 7 8

public void run() { int param1 = this.param1; int param2 = this.param2; int sewidth = this.sewidth; int width = this.width; int height = this.height ; // ton code qui utilise les variables locales }

---

---

Ok merci.
J'aurai pensé que cela était équivalent à

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

private class maclass extends Threads {   private int param1, param2, sewidth, width, height ;   public void setParameters(BufferedImage image, int sewidth, int param1, int param2) { this.param1 =param1; this.param2 = param2; this.sewidth = sewidth; this.width = image.getWidth(); this.height = this.getHeight() ; }   public void run() { // Utilisation des variables private }

---

puisque le thread est private et que les variables ne sont modifiées que dans setParameters et utilisées que dans run().
Je vais modifier en conséquence est voir s'il y a un quelconque gain de performances (même si tu doutes, j'aime être sûr :p )

Citation:

---

Envoyé par ToTo13

J'aurai pensé que cela était équivalent à

---

C'est équivalent si tu définis les attributs en final.
Si ce n'est pas le cas il est toujours possible que les valeurs soient modifiées par un autre thread qui aurait une référence vers l'instance de "maclass".


Maintenant en fait je doute qu'il y aura une différence.
En général c'est plutôt l'inverse dans ce cas là : le thread optimise l'accès aux attributs et ne voit pas les modifications extérieures...


a++

Citation:

---

Envoyé par adiGuba

C'est équivalent si tu définis les attributs en final.
Si ce n'est pas le cas il est toujours possible que les valeurs soient modifiées par un autre thread qui aurait une référence vers l'instance de "maclass".

---

Une solution serait aussi de définir "private final class maclass extends Threads".

Bon alors j'ai fait quelques tests :
- mettre "final" les classes et arguments des méthodes que j'utilise dans ce code ne change rien aux performances.
- récupérer les paramètres de traitement dans la méthode "run" afin qu'ils soient locaux, ne change rien non plus.
Du coup je ne sais pas comment optimiser :-(

Lorsque j'utilise l'option -Xcomp, je perds sérieusement en performances et là... c'est un mystère :aie:
Le code reste aussi simple que court (calcul de minima/maxima sur des tableaux dont on connait les limites/bornes de calcul au préalable), alors pourquoi perdre en performances lorsque c'est préalablement compilé ?

XComp précompile, ça veux dire qu'il n'a aucune idée de comment la méthode est réellement utilisée car aucune info de profilage disponible, ce qui nuit aux performances.

Citation:

---

-Xcomp
Forces compilation of methods on first invocation. By default, the Client VM (-client) performs 1,000 interpreted method invocations and the Server VM (-server) performs 10,000 interpreted method invocations to gather information for efficient compilation. Specifying the -Xcomp option disables interpreted method invocations to increase compilation performance at the expense of efficiency.

You can also change the number of interpreted method invocations before compilation using the -XX:CompileThreshold option.

---

https://docs.oracle.com/javase/8/doc...unix/java.html

Je crois qu'il faut arrêter là les chipottage à l'aveugle, et sortir un profiler pour savoir ce qui se passe réellement dans ton code et où les perfs sont perdues.

Citation:

---

Envoyé par tchize_

sortir un profiler pour savoir ce qui se passe réellement dans ton code et où les perfs sont perdues.

---

Est ce qu'il y en a un efficace et simple ?

J'ai utilisé le profiler de Netbeans et je suis surpris par la deuxième ligne :
[IMG]www.thibault.biz/Developpez/Profiler01.png[/IMG]
Je travaille avec/sur des BufferedImage ou des DV (classe perso pour le stockage de volume, mais qui ressemble à un BufferedImage 3D) avec un DataBuffer de type Byte.
Je n'utilise JAMAIS dans mon programme des char[].
Du coup je ne comprends absolument pas la présence de la deuxième ligne :-(

Salut,

Les char[] peuvent provenir simplement d'instances de String (utilisés en interne pour stocker les caractères). Avec le profiler tu peux inspecter le contenu des tableaux de char[], ou déterminer quelle instance englobe le tableau.

Citation:

---

Envoyé par joel.drigo

Avec le profiler tu peux inspecter le contenu des tableaux de char[], ou déterminer quelle instance englobe le tableau.

---

Merci, mais comment ?

Rien qu'en profilant ce programme :

Code:

---

1 2 3 4 5 6 7

public class Exemple {   public static void main(String[] args) { JOptionPane.showMessageDialog(null, "Message"); }   }

---

J'obtiens :

Pièce jointe 185096

Là, en double-cliquant sur la ligne avec char[], on obtient :

Pièce jointe 185097

A gauche, les instances, avec leur valeur (en gris clair).
A droite, en bas, tu as l'arbre inverse des références (à chaque fois que tu ouvres un niveau, tu obtiens l'instance qui contient l'instance du nœud au-dessus.

Mais, tu verras, il y a beaucoup d'instances de String dans les classes de Java.

Quel profiler as tu utilisé ?

Pour en revenir au problème de performances à l'origine de ce post, j'ai "peut être" l'explication.

J'ai finalement isolé le code qui a des grosses différences performances en fonction du sens où l'on travaille (verticalement ou profondeur car je traite des volumes).

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

for (z=start ; z < end ; z+=inc) { aux = buffer[z] ; Hist[aux]++ ; if ( aux > maxi) maxi = aux ; }   for (z=start ; z < end ; z+=inc) { aux = buffer[z+inc2] ; Hist[aux]++ ; if ( aux > maxi ) maxi = aux ; bufferout[z] = maxi ; }

---

La différences entre la classe qui travaille verticalement et celle qui travaille en profondeur va être uniquement la taille des additions.
Par exemple sur un volume 512 x 512 x 512 :
- Verticalement => start=0, end=512x512, inc=512, inc2=512
- Profondeur => start=0, end=512x512x512, inc=512x512, inc2=512x512
La taille des additions est la seule différence entre les algorithmes.

Est ce que cela peut expliquer qu'un code soit plus rapide que l'autre ?