Discussion :

[Elendhil]

Mon teste affiche quelques cubes en rotation , dans une fenetre Swing qui contient un GLJPanel. Quand je regarde le gestionnaire de tâche je constate que l'utilisation du processeur est constament entre 50 et 60%. Comme j'utilise JOGL donc openGL , les calculs sont envoyés au GPU et non au CPU.

Alors pourquoi es que j'ai un telle taux d'occupation de mon cpu ? es que cela est dû au systeme de fenetrage ?

[Mat.M]

Mon teste affiche quelques cubes en rotation , dans une fenetre Swing qui contient un GLJPanel. Quand je regarde le gestionnaire de tâche je constate que l'utilisation du processeur est constament entre 50 et 60%. Comme j'utilise JOGL donc openGL , les calculs sont envoyés au GPU et non au CPU.

1-Sans vouloir troller et faire un débat Java/autres langages, c'est pas du code natif qui appelle directement les couches logicielles.
La JVM est obligée de déléguer les taches à des routines toutes faites de JOGL.
Faut pas oublier qu'à chaque instruction la JVM regarde si une exception est levée..
2-l'utilisation CPU ? voir remarque précédente ; étant donné que c'est pas entièrement du code natif l'OS est obligé de commuter entre le programme parent en Java et le rendu délégué à la couche logicielle de JOGL.
Cette commutation continuelle toutes les x millisecondes entraine une certaine sollicitation du CPU de la mémoire voire du disque dur..

>>les calculs sont envoyés au GPU et non au CPU.
si la carte graphique sur ta machine n'a pas de Device Drivers spécifiques pour Open GL c'est peanuts...
En théorie il ya des drivers pour Open GL mais sont-ils réellement optimisés ?

[Kujara]

Pour info, de toute façon tout rendu en 3D bouffe du proc.

Le gpu fait effectivement les calculs, mais il faut quand même lui dire quoi tracer, et c'est cette partie qui peut etre très couteuse selon ce que tu utilise.

Donc tout dépends de ce que tu affiche a l'ecran, de tes drivers, de ce que fait réellement la jvm derrière, etc ...

[Mat007]

Salut,

Un moyen simple de savoir exactement ce qui prend du temps c'est d'utiliser un profiler.
Je ne sais pas quel est ton environnement de développement mais pour Eclipse il y a par exemple EclipseColorer.

MAT.

[Mat007]

Moui sauf qu'en fait là le code java est vraiment minimal, c'est ça ?
Ca ne va sans doute pas aider des masses du coup...

MAT.

[screetch]

1-Sans vouloir troller et faire un débat Java/autres langages, c'est pas du code natif qui appelle directement les couches logicielles.
La JVM est obligée de déléguer les taches à des routines toutes faites de JOGL.
Faut pas oublier qu'à chaque instruction la JVM regarde si une exception est levée..

ca reste un beau troll de premiere. Meme en C++ si tu fais juste une boucle de rendu ton CPU risque de monter en fleche. avant d'accuser l'implementation Java, il faut verifier deux trois trucs...

Essaye d'activer le VSync pour bloquer le programme en attendant la prochaine frame, si ce n'est pas deja fait. Quel est le framerate de l'application ?

[r1-1024]

C un peu tard mais si ça sert à qq'1
GLJPanel fait un rendu offscreen (GPU) puis copie le contenu (CPU) dans un JPanel (qui est un composant léger). la copie se fait while(true) donc à fond. Tu peux remarquer qu'en augmentant la taille du GLJPanel, le frame rate chute. C'est parceque la taille du buffer à copier est plus importante et donc le CPU rame.

Si tu veux une occupation CPU de qq% utilise un GLCanvas, le rendu est direct mais c un composant lourd (perso ya pas de différence avec du code natif dans ce cas).

Cependant j'aimerai relever qq irrégularités.

Sans vouloir troller et faire un débat Java/autres langages, c'est pas du code natif qui appelle directement les couches logicielles

Même si la jvm (SUN) utilise du bytecode, le but est qd même de faire du code natif, le JIT est la pour ça. Donc si c bien du code natif.

Faut pas oublier qu'à chaque instruction la JVM regarde si une exception est levée

Là encore, il me semble que c le CPU qui s'occupe de ça et pas la jvm directement, tout comme en C++ ou en C ou en assembleur... Déléguer cette tache à la jvm aurait pour conséquence de doubler les instructions CPU. Donc à la louche deux fois plus lent, ce qui n'est pas le cas. En java (jvm SUN) on tourne à 5% de moins qu'un code C.