Discussion :

[Furikawari]

Je n'en fait pas une affaire personnelle, le dernier paragraphe de mon précédent post était une vraie généralité sur les différents threads de ce forum java vs reste du monde.

T'as pas eu de chance, ce matin j'étais en avance et sur les 3 affirmations de ton post, une est clairement fausse (les virtual calls) et 2 sont au mieux ambigües et interprétables dans la mauvaise direction.

La gestion de la mémoire en java est (en général) plus rapide qu'en C++ et ce n'est pas dû à l'exploitation d'un deuxième core par le GC, même si un core de libre pour le GC est effectivement tout benef.

Quand a ta phrase sur l'occupation de l'espace mémoire était directement interprétable en "une classe java occupe beaucoup d'espace mémoire" (et c'est ainsi que je l'ai interprétée).

Bref t'as payé pour tous les posts faux et/ou approximatifs de ce genre de threads...

[shenron666]

Je n'en fait pas une affaire personnelle, le dernier paragraphe de mon précédent post était une vraie généralité sur les différents threads de ce forum java vs reste du monde.

en programmation il n'y a pas de généralités surtout quand il s'agit de comparer les performances et contre performances d'un langage

sur les 3 affirmations de ton post, une est clairement fausse (les virtual calls) et 2 sont au mieux ambigües et interprétables dans la mauvaise direction.

il y a interpréter et interpréter
d'une part chacun a sa vision des choses, ses expériences, ect
d'autre part, j'imagine que personne n'a codé de machine virtuelle, donc entre documentations parfois mal interprétés, conclusions hatives, bench atrophiés on tire des conclusions ambigues qui ne sont pas des vérités

La gestion de la mémoire en java est (en général) plus rapide qu'en C++ et ce n'est pas dû à l'exploitation d'un deuxième core par le GC, même si un core de libre pour le GC est effectivement tout benef.

deuxième core ou non, la gestion de la mémoire en java n'est pas plus rapide qu'en C++
-> en C++ tu as le choix entre
l'allocation de base que tout le monde fait : un new un delete
utiliser des pointeurs intelligents, un new et il s'auto delete
utiliser un pool de mémoire très efficace sur la gestion de nombreuses petites allocations
ou même tout à la fois afin de tirer le meilleur parti de chaque méthode (bonjour l'usine à gaz )
bien sûr avec de mauvais choix il est toujours possible d'être plus lent que java
-> en java tu n'as pas le choix, tu passes obligatoirement par le GC
si le GC est à la ramasse, saturé par les allocs / désallocs, il va te falloir configurer le GC afin d'améliorer les performances, faut garder l'espoir

Quand a ta phrase sur l'occupation de l'espace mémoire était directement interprétable en "une classe java occupe beaucoup d'espace mémoire" (et c'est ainsi que je l'ai interprétée).

moi je l'ai interprété en
"une classe java occupe plus d'espace mémoire qu'une classe c++"
ce qui n'est pas faux mais pas tout à fait vrai
en c++, avec l'allocation basique, new delete, une classe n'est qu'un pointeur
si on commence à utiliser des pointeurs intelligents ou des pools chaque allocation prend plus de place (il faut gérer les états d'allocation, les compteurs, ect) et on retombe au niveau du java voir même pire si c'est mal fait
si j'étais médisant on peut dire qu'on a une certaine marge vu la place occupée par la JVM

Bref t'as payé pour tous les posts faux et/ou approximatifs de ce genre de threads...

et ce n'est pas là son rôle, merci d'éviter à l'avenir et restons dans le convivial

[shenron666]

Il est cependant inadapté à certaines parties d'un jeu, et j'explique pourquoi, par exemple en commentant les bench.

je pense que java n'est pas inadapté en soi à certaines partie, c'est un choix comme un autre
les benchs sont très souvent très, trop synthétiques
un vrai bench qui illustrerai java dans le cadre d'un jeu vidéo serait un bench dans le pur style 3Dmark
mais encore une fois on retourne parler graphismes pour des jeux de premier ordre

au moins ce qui est bien en programmation, si on a besoin de performances brutes tirées au maximum on a toujours la liberté de coder une partie dans un autre langage

[HS]
Tiens ça me fait penser, le cinéma connait le terme "blockbuster"
Il n'y a pas d'équivalent dans le jeu vidéo ?
[/HS]

[screetch]

jeu AAA ?
sinon, au niveau du sujet lui même, je n'ai jamais vu de programme entièrement codé en java qui marchait plus vite que son equivalent en C++.
je ne souhaite pas commencer de troll hein, c'est juste que personne ni ici ni ailleurs n'a pu donner deux programmes sensiblement equivalents.

[Furikawari]

deuxième core ou non, la gestion de la mémoire en java n'est pas plus rapide qu'en C++
-> en C++ tu as le choix entre
l'allocation de base que tout le monde fait : un new un delete
utiliser des pointeurs intelligents, un new et il s'auto delete
utiliser un pool de mémoire très efficace sur la gestion de nombreuses petites allocations
ou même tout à la fois afin de tirer le meilleur parti de chaque méthode (bonjour l'usine à gaz )
bien sûr avec de mauvais choix il est toujours possible d'être plus lent que java
-> en java tu n'as pas le choix, tu passes obligatoirement par le GC
si le GC est à la ramasse, saturé par les allocs / désallocs, il va te falloir configurer le GC afin d'améliorer les performances, faut garder l'espoir

Je ne vois pas en quoi ces choix rendent la gestion de la mémoire en C++ plus rapide (mis à part le pool et encore il faudra que ce soit sacrément optimisé)... Que tu me dises plus fine ok. Il n'en reste pas moins qu'une allocation mémoire C++ correspond à un appel système. Et ça c'est "légèrement" plus coûteux qu'une allocation faite par GC.

Je ne réponds pas au reste du post qui n'argumente rien. Quoique, ta petite remarque sur la palce prise par la JVM en dise assez long (on en revient toujours à l'allocation mémoire et au fait que la JVM pré alloue, d'où "la place prise par la jvm" ).

[deadalnix]

Et bien non, une gestion par pool comme elle est faite dans le moteur de quake3 ne correspond pas un appel système. Cela a en fait un comportement très proche du GC de java.

Il est aussi possible de déférer les désallocs en C++ (ce que je fait, combiné a des pools). Mais j'ai un gestionnaire mémoire codé par mes soins dans mon soft du coup. C'est performants, sans doute plus que java, mais au combien plus long et complexe a coder.

Paramètre qui entre en compte dans bien des cas

A mon avis, tu peux toujours faire mieux dans un langage type C++ qu'en java, seulement faut s'en donner les moyens. La question est plutôt la. Et aussi dans quelle mesure est-ce utile.

A mon avis il y a certains points ou java ne fournis pas. Tout ce qui est calculs lourds sur CPU déjà, quand on voit ce qu'on peut faire avec des expressions templates sur la calcul matriciel . . . Sur un moteur physique ça change pas mal.

Une autre chose est la gestion calamiteuse du temps. On n'arrives pas a avoir des sleep de la bonne longueur (a moins qu'un méthode que je ne connaisse pas donne des merveilles).

EDIT: quand à la place prise par la JVM, je ne penses pas que ce soit un problème sur les PCs modernes. Sue de l'embarqué ou sur console par contre, cela peu poser soucis.

[screetch]

Le GC de java, de Objective-C(++), de D et de C# est ecrit en C pour son implémentation sous GCC.
La différence entre java et C++ c'est qu'en C++ on peut changer l'alocateur, quitte à le remplacer par...
un GC. Bah oui.

[shenron666]

Je ne vois pas en quoi ces choix rendent la gestion de la mémoire en C++ plus rapide (mis à part le pool et encore il faudra que ce soit sacrément optimisé)...

c'est désespérant, pourquoi tu ne pourrais pas avoir un pool mémoire aussi optimisé en C++ que la JVM ?

Je ne réponds pas au reste du post qui n'argumente rien.

l'hopital qui se fou de la charité

Quoique, ta petite remarque sur la palce prise par la JVM en dise assez long (on en revient toujours à l'allocation mémoire et au fait que la JVM pré alloue, d'où "la place prise par la jvm" ).

sans parler de la "préallocation" dûe au pool mémoire entre autres éléments qui serviront au programme java exécuté
la JVM prend de la place en mémoire pour le compilateur, l'interpréteur, ses états internes ect et ce n'est pas quelques Ko

même si c'est dérisoire sur un PC souvent équipé de plusieurs centaines de Mo et même plusieurs Go aujourd'hui, sur une console ou un système restreint c'est pénalisant

[Furikawari]

Faut arrêter de prendre les gens de haut et apprendre à lire. Je n'ai pas dit que c'était impossible à faire en C++, j'ai dit qu'il fallait le faire correctement pour que ce soit concurrentiel... A moins que vous ne considériez que les gens qui ont bossé sur les GC pendant plus de 20 ans aient fait de la m... ?

Enfin bref, une fois de plus ça tourne à la mauvaise foi.

Pour ce qui est de la jvm, effectivement elle prend de la place, mais comme cela a déjà été dit, ça ne l'empêche pas de tourner sur 99% des téléphones portables... Comme toujours c'est une question de tradeoff entre services disponibles et espace mémoire.

[shenron666]

les JVM de portable sont le pire exemple qui puisse exister de JVM
les JVM des téléphones portables sont rarement compatibles entre elles, elles ne respectent pas souvent correctement les standards Sun, elle sont incomplètes et plus optimisées pour la mémoire que pour les performances

là où le Java est sensé avoir un avantage c'est dans la portabilité, mais déjà qu'écrire une application Java pour un téléphone portable s'avère souvent être un parcours du combattant, écrire une application pour plusieurs portables nécessite plusieurs version du code
super la portabilité, on revient au même point que le C++ avec des bouts de code spécifiques à l'OS

edit :

A moins que vous ne considériez que les gens qui ont bossé sur les GC pendant plus de 20 ans aient fait de la m... ?

pour moi, le GC c'est de la m****, plus encore si on parle de jeux vidéo

[Furikawari]

edit :

pour moi, le GC c'est de la m****, plus encore si on parle de jeux vidéo

Au moins tout est dit et ton opinion est claire pour les gens qui liront ce thread...

[Invité]

jeu AAA ?
sinon, au niveau du sujet lui même, je n'ai jamais vu de programme entièrement codé en java qui marchait plus vite que son equivalent en C++.
je ne souhaite pas commencer de troll hein, c'est juste que personne ni ici ni ailleurs n'a pu donner deux programmes sensiblement equivalents.

Jake2 (écrit en 2004) tourne plus vite que le jeu qu'il clone, Quake 2. Je garde à l'esprit que ce n'est pas un jeu tout récent. Cesse de faire comme si cet exemple est une blague s'il te plait.

De toute manière, je rappelle que l'utilisation de Java dans les jeux vidéo commerciaux continue d'augmenter (certes timidement) et comme je l'ai dit précédemment, Ankama Games, Funcom et Sony Online Entertainment s'y intéressent sérieusement.

Enfin, quant aux benchmarks, je travaille rarement sur des machines avec des processeurs multi-noyaux et j'avais trouvé un autre benchmark réputé moins sérieux qui donnait des résultats complètement différents pour la comparaison entre Java et C/C++ GNU.

Au moins tout est dit et ton opinion est claire pour les gens qui liront ce thread...

Oui je trouve aussi. De plus, certains disent que le ramasse-miettes n'est pas adapté pour les jeux vidéo mais ça n'a pas l'air de gêner les programmeurs de jeux vidéo en Java concrètement et j'ai déjà donné auparavant quelques pistes pour celles et ceux qui voudraient par exemple limiter la durée maximale des pauses provoquées par ce dernier.

[screetch]

Jake2 (écrit en 2004) tourne plus vite que le jeu qu'il clone, Quake 2. Je garde à l'esprit que ce n'est pas un jeu tout récent. Cesse de faire comme si cet exemple est une blague s'il te plait.

C'est une enorme blague ce truc, Quake2 avait un renderer software ou un renderer openGL 1.0 avec une tripotée de glBegin() / glEnd()
Jake2 en 2004 a bénéficié d'openGL 1.4 avec des vertex arrays et autres. La technologie avait énormément évolué, il n'y a rien a comparer!

[screetch]

Enfin, quant aux benchmarks, je travaille rarement sur des machines avec des processeurs multi-noyaux et j'avais trouvé un autre benchmark réputé moins sérieux qui donnait des résultats complètement différents pour la comparaison entre Java et C/C++ GNU.

C'est juste la preuve qu'on peut toujours orienter les benchmarks d'un côté ou de l'autre, et que donc on ne peut rien en tirer, pas plus de benchmark "serieux" que de pas sérieux.

[yan]

Jake2 (écrit en 2004) tourne plus vite que le jeu qu'il clone, Quake 2. Je garde à l'esprit que ce n'est pas un jeu tout récent. Cesse de faire comme si cet exemple est une blague s'il te plait.

j'ai beau lire et relire la page de benchmark
http://bytonic.de/html/benchmarks.html
j'aimerais bien savoir où tu as vue que jake2 était plus rapide.
D'un côté vue le nombre de fps, on s'en fou un peu, mais je comprend pas pourquoi autant d'obstination avec cette exemple...

Enfin, quant aux benchmarks, je travaille rarement sur des machines avec des processeurs multi-noyaux et j'avais trouvé un autre benchmark réputé moins sérieux qui donnait des résultats complètement différents pour la comparaison entre Java et C/C++ GNU.

tu regarde des benchmark considéré comme non sérieux pour affirmer des choses???
Un benchmark c'est bancale, ont y montre ce que l'on as envie.


Tu ne veut voir que ce que tu as envie... c'est dommage et ça relance le troll à chaque fois...

Faut arrêté avec "JAVA c'est le meilleur langage du monde"

[plegat]

j'ai beau lire et relire la page de benchmark
http://bytonic.de/html/benchmarks.html
j'aimerais bien savoir où tu as vue que jake2 était plus rapide.

Tout à fait à droite, y'a 260/250 fps... tout à fait à gauche, y'a 245 fps.
250 c'est plus grand que 245 non?
Bon, ok, pour une config bien particulière...

Faut arrêté avec "JAVA c'est le meilleur langage du monde"

Tout à fait d'accord.
Mais il serait également bien que certains arrêtent de sous-entendre que Java c'est le langage le plus pourri du monde

Sinon, pour dire quelque chose de constructif, je trouve que ce débat s'embourbe un peu dans des affrontements stériles entre "pro" et "pas pro" Java, et s'écarte un peu du sujet initial. Tout le monde s'obstine à dire que Java n'est pas fait pour faire des jeux de haut niveau graphique, alors qu'on en est tous conscient (sauf à avoir une bête de compétition pour faire tourner le jeu).
Je crois me souvenir avoir vu une conclusion de Millie qui résumait assez bien la chose.

Là, on tourne en rond, les noms d'oiseaux commencent à voler, et la courtoisie à s'envoler...

Cela dit, moi, je garde mon java... de toute façon, les jeux en C++ rament aussi sur ma machine alors...

[Invité]

Tout le monde s'obstine à dire que Java n'est pas fait pour faire des jeux de haut niveau graphique, alors qu'on en est tous conscient (sauf à avoir une bête de compétition pour faire tourner le jeu).

Je ne suis pas d'accord. Je ne vois pas pourquoi Java ne pourrait pas faire tourner des jeux de haut niveau graphique. Ce n'est pas parce que ça n'a pas encore été fait que ça ne se fera jamais, il y a déjà des jeux Java en 3D avec des graphismes tout à fait acceptables:

Le GC de java, de Objective-C(++), de D et de C# est ecrit en C pour son implémentation sous GCC.
La différence entre java et C++ c'est qu'en C++ on peut changer l'alocateur, quitte à le remplacer par...
un GC. Bah oui.

Les algorithmes de garbage collection ne sont pas les mêmes en Java et en C++, l'implémentation et la manière de gérer la mémoire non plus.

j'ai beau lire et relire la page de benchmark
http://bytonic.de/html/benchmarks.html
j'aimerais bien savoir où tu as vue que jake2 était plus rapide.
D'un côté vue le nombre de fps, on s'en fou un peu, mais je comprend pas pourquoi autant d'obstination avec cette exemple...

Je ne me moque pas du frame rate et Jake2 n'utilise pas les dernières extensions des cartes graphiques, je n'ai pas vu de shader par exemple. Par contre, une des versions de Jake 2 utilise les VBO, qui n'étaient pas disponibles en 1997 mais qui ne donnent pas de meilleures performances avec les cartes graphiques utilisées (si on compare les display lists aux VBO statiques).

tu regarde des benchmark considéré comme non sérieux pour affirmer des choses???
Un benchmark c'est bancale, ont y montre ce que l'on as envie.

Tu ne veut voir que ce que tu as envie... c'est dommage et ça relance le troll à chaque fois...

Faut arrêté avec "JAVA c'est le meilleur langage du monde"

Toi tu ne vois que ce que tu as envie comme on vient de le voir pour les performances de Jake2. Je ne pense pas qu'il soit impossible de faire un bon benchmark, c'est une tâche difficile .

[yan]

Toi tu ne vois que ce que tu as envie comme on vient de le voir pour les performances de Jake2

y as un seule chiffre supérieur dans ton tableau et toi tu trouve que cela montre que la version java est plus rapide???

[kremvax]

Gouessej, les screenshots que tu nous montrent ne sont pas vraiment à l'avantage de java.
Un jeu c++ :


Tu vas dire que ce ne sont pas les graphismes qui importent, d'accord, mais ne sors pas ces arguments toi-même

[screetch]

Je ne me moque pas du frame rate et Jake2 n'utilise pas les dernières extensions des cartes graphiques, je n'ai pas vu de shader par exemple. Par contre, une des versions de Jake 2 utilise les VBO, qui n'était pas disponibles en 1997 mais qui ne donnent pas de meilleures performances avec les cartes graphiques utilisées (si on compare les display lists aux VBO statiques).

non ca c'est juste faux. faux faux faux. les VBO sont quand meme bien plus rapides que les display list. la géometrie est stockée sur la carte graphique...