Les langages de prog de haut niveau donnent aussi trop de pouvoir de mettre une balle dans le pied de l'optimisation.
Je laisse la parole à John Carmack, qui a participé à l'un des moteurs 3D de jeu vidéo le plus optimisé qui soit, dans les limites de l'humainement possible. (mais il n'a pas été le seul, voir par ex : http://games.slashdot.org/article.pl?sid=06/12/01/184205
)
The biggest problem is that Java is really slow. On a pure cpu / memory / display / communications level, most modern cell phones should be considerably better gaming platforms than a Game Boy Advanced. With Java, on most phones you are left with about the CPU power of an original 4.77 mhz IBM PC, and lousy control over everything.
C'est son constat après avoir fait des jeux pour téléphone portable ( Doom RPG, haha ).
Ce même monsieur a pendant longtemps boudé le C++ et fait ses moteurs en C. Doom 3, qui était l'un des premiers jeux à exploiter le per pixel lighting, a la logique du jeu qui est codé en C++ mais le moteur 3D est toujours fait dans un style C, pas du C++ objet.
A noter que le mythe du C++ beaucoup plus rapide que Java est dû au fait qu'une grande, grande partie des développeurs C++ ne sont pas vraiment des développeurs C++ mais des développeurs C qui s'ignorent. Un programme C++ qui utilise tout le pouvoir d'abstraction offert par le C++ moderne risque même d'être plus lent qu'un programme Java qui tourne sous HotSpot. De très (trop?) nombreux projets ont des règles de Coding Style qui interdisent un grand nombre des outils offerts par le C++ moderne, à la fois pour des raisons de portabilité (compileurs pourris) et performances.
Malheureusement il ne sort plus de livres sur le C. Il y a eu une nouvelle norme C, le C99, mais très très peu de livres qui expliquent les nouveautés de cette norme. Ca n'encourage pas les jeunes développeurs à apprendre le vieux langage, qu'ils considèrent prématurément comme désuet.
L'avenir, et c'est même le présent, c'est d'alterner des couches bas et haut niveau. Sun a raté un train avec Java qui cherche absolument à tout faire en Java.
Alors que le java officiel prétends qu'il faut même faire le GUI en java (Swing), les Windows.Forms du C# font appel à des libs natives, ce ne sont que des wrappers, comme l'étaient les MFC du C++ qui cachaient l'API C.
Dotnet et Mono seront de plus grandes réussites sur le desktop, et peut-être même dans le monde du jeu vidéo parce que dotnet est bien plus facile à interfacer avec le monde natif et on est encouragé à le faire.
Les pythonistas ont eu aussi cette longueur d'avance sur les développeurs Java. Ils n'hésitent pas du tout à utiliser les libs natives dans leurs programmes python. Un programme python qui utilise des libs natives dans les points chauds sera forcément plus rapide qu'un programme codé par un drogué qui fait tout en Java.
[^] # Re: Plop !
Posté par taratatatata . En réponse au journal "L'informatique Paradoxale". Évalué à 6.
Je laisse la parole à John Carmack, qui a participé à l'un des moteurs 3D de jeu vidéo le plus optimisé qui soit, dans les limites de l'humainement possible. (mais il n'a pas été le seul, voir par ex :
http://games.slashdot.org/article.pl?sid=06/12/01/184205
)
The biggest problem is that Java is really slow. On a pure cpu / memory / display / communications level, most modern cell phones should be considerably better gaming platforms than a Game Boy Advanced. With Java, on most phones you are left with about the CPU power of an original 4.77 mhz IBM PC, and lousy control over everything.
C'est son constat après avoir fait des jeux pour téléphone portable ( Doom RPG, haha ).
Ce même monsieur a pendant longtemps boudé le C++ et fait ses moteurs en C. Doom 3, qui était l'un des premiers jeux à exploiter le per pixel lighting, a la logique du jeu qui est codé en C++ mais le moteur 3D est toujours fait dans un style C, pas du C++ objet.
A noter que le mythe du C++ beaucoup plus rapide que Java est dû au fait qu'une grande, grande partie des développeurs C++ ne sont pas vraiment des développeurs C++ mais des développeurs C qui s'ignorent. Un programme C++ qui utilise tout le pouvoir d'abstraction offert par le C++ moderne risque même d'être plus lent qu'un programme Java qui tourne sous HotSpot. De très (trop?) nombreux projets ont des règles de Coding Style qui interdisent un grand nombre des outils offerts par le C++ moderne, à la fois pour des raisons de portabilité (compileurs pourris) et performances.
Malheureusement il ne sort plus de livres sur le C. Il y a eu une nouvelle norme C, le C99, mais très très peu de livres qui expliquent les nouveautés de cette norme. Ca n'encourage pas les jeunes développeurs à apprendre le vieux langage, qu'ils considèrent prématurément comme désuet.
L'avenir, et c'est même le présent, c'est d'alterner des couches bas et haut niveau. Sun a raté un train avec Java qui cherche absolument à tout faire en Java.
Alors que le java officiel prétends qu'il faut même faire le GUI en java (Swing), les Windows.Forms du C# font appel à des libs natives, ce ne sont que des wrappers, comme l'étaient les MFC du C++ qui cachaient l'API C.
Dotnet et Mono seront de plus grandes réussites sur le desktop, et peut-être même dans le monde du jeu vidéo parce que dotnet est bien plus facile à interfacer avec le monde natif et on est encouragé à le faire.
Les pythonistas ont eu aussi cette longueur d'avance sur les développeurs Java. Ils n'hésitent pas du tout à utiliser les libs natives dans leurs programmes python. Un programme python qui utilise des libs natives dans les points chauds sera forcément plus rapide qu'un programme codé par un drogué qui fait tout en Java.