Ton exemple est intéressant, mais c'est un FPS, par un STR. En pratique, si tu veux gérer un terrain de jeu de taille nxn, tu va bien entendu utiliser kxnxn octets, où k designe le nombre d'octets nécessaires au stockage des informations nécessaires dans chaque case du tableau. Le problème est Java est que tu te tapes :
1) un overhead d'au moins 12 octets par objet
2) une référence bouffant 4 octets par objet
3) une non localité en mémoire et donc une indirection pour chaque accès à une case du tableau
Exemple concret, j'ai une carte warcraft III de taille 128x128. Si je veux stocker une information par case en Java, je consomme 256 ko d'overhead. Bien entendu, ce n'est pas grand chose, mais c'est symptomatique des problèmes de Java. La même chose en C# ne consomme aucun overhead, n'a pas de problème de localité en mémoire et ne nécessite pas d'indirection, donc c'est strictement mieux.
Concernant les templates, le problème va beaucoup plus loin que les simples types fondamentaux. En Java, les templates sont gérés par effacement du type, ce qui pose plein de problèmes sémantiques (en particulier de sombres histoires avec les tableaux). Des choses logiques sont impossibles, ce qui gêne l'apprentissage. De plus, aucune optimisation du code des templates n'est possible car il est commun à toutes les instanciations. En C#, la machine virtuelle peut décider de spécialiser un code pour profiter de divers éléments, par exemple le fait que certaines méthodes ne sont pas virtuelles ce qui permet des inlining. De plus, j'ai des exemples concrets en C++ en calcul numérique de codes entièrement templates sur le type réel. En pratique, T=double pour les applications classiques, mais on peut écrire T=Complex dans certaines situations, voire T=Interval quand on souhaite utiliser l'analyse par intervalle pour mesurer la stabilité de l'algorithme.
Ta dernière remarque me fait penser à un point important : ça fait des années que certaines possiblités qui sont absentes en Java (les énumérés, les templates, les structs, le passage par référence, etc.) existent dans des langages très utilisés (comme C++) ou réputés pour leur qualité en terme de génie logiciel (comme Eiffel ou Ada). Ta remarque donne l'impression qu'utiliser ces possibilités est dangeureux, alors qu'on maîtrise parfaitement ces choses. Avoir deux paramètres de sortie pour une fonction est plus qu'élémentaire, n'a rien de casse-gueule et fait partie du bagage de l'informaticien classique. Ce n'est pas parce que Java a privilégié une certaine simplicité à ses débuts (bien loin de nous avec les versions récentes), qu'il faut oublier les fondamentaux !
[^] # Re: Excellent
Posté par boubou . En réponse à la dépêche Le code de Java3D est disponible. Évalué à 4.
1) un overhead d'au moins 12 octets par objet
2) une référence bouffant 4 octets par objet
3) une non localité en mémoire et donc une indirection pour chaque accès à une case du tableau
Exemple concret, j'ai une carte warcraft III de taille 128x128. Si je veux stocker une information par case en Java, je consomme 256 ko d'overhead. Bien entendu, ce n'est pas grand chose, mais c'est symptomatique des problèmes de Java. La même chose en C# ne consomme aucun overhead, n'a pas de problème de localité en mémoire et ne nécessite pas d'indirection, donc c'est strictement mieux.
Concernant les templates, le problème va beaucoup plus loin que les simples types fondamentaux. En Java, les templates sont gérés par effacement du type, ce qui pose plein de problèmes sémantiques (en particulier de sombres histoires avec les tableaux). Des choses logiques sont impossibles, ce qui gêne l'apprentissage. De plus, aucune optimisation du code des templates n'est possible car il est commun à toutes les instanciations. En C#, la machine virtuelle peut décider de spécialiser un code pour profiter de divers éléments, par exemple le fait que certaines méthodes ne sont pas virtuelles ce qui permet des inlining. De plus, j'ai des exemples concrets en C++ en calcul numérique de codes entièrement templates sur le type réel. En pratique, T=double pour les applications classiques, mais on peut écrire T=Complex dans certaines situations, voire T=Interval quand on souhaite utiliser l'analyse par intervalle pour mesurer la stabilité de l'algorithme.
Ta dernière remarque me fait penser à un point important : ça fait des années que certaines possiblités qui sont absentes en Java (les énumérés, les templates, les structs, le passage par référence, etc.) existent dans des langages très utilisés (comme C++) ou réputés pour leur qualité en terme de génie logiciel (comme Eiffel ou Ada). Ta remarque donne l'impression qu'utiliser ces possibilités est dangeureux, alors qu'on maîtrise parfaitement ces choses. Avoir deux paramètres de sortie pour une fonction est plus qu'élémentaire, n'a rien de casse-gueule et fait partie du bagage de l'informaticien classique. Ce n'est pas parce que Java a privilégié une certaine simplicité à ses débuts (bien loin de nous avec les versions récentes), qu'il faut oublier les fondamentaux !