Voir Data Oriented Design, qui n'a aucun lien avec le langage à proprement parlé, c'est juste une technique de conception, très utile pour rendre des algos parallélisables.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Voir Data Oriented Design, qui n'a aucun lien avec le langage à proprement parlé, c'est juste une technique de conception, très utile pour rendre des algos parallélisables.
dans un sens c'est faisable en C++, comme en C#, mais c'est plus dangereux du a la présence d'effets de bord.
En general on arrive pas a 100% de parallèlisme dans ces applications, et toute les parties du jeu orientées objet sont plus complexes a rendre parallèles.
En même temps, programmer en C++ plutôt qu'en C# n'aidera pas à faire venir DirectX sous Mac ou Linux...Envoyé par LittleWhite
La question est plutôt sur l'intégration de ces langages avec les framework graphiques des plate-formes concernées. C# comme C++ offrent de bonnes possibilités sous Windows et XBox360, car ils savent bien gérer DirectX. Mais sur Mac, Linux, Wii ou PS3, les choses sont différentes. Là, c'est souvent le règne d'OpenGL et de ses dérivés. Je ne suis pas certain qu'utiliser une couche comme Mono apporte beaucoup dans ce domaine. J'avoue que je ne connais pas très bien Mono, et je ne sais pas quel est son niveau de support d'OpenGL, mais de toute manière, il faudra tout réécrire par rapport à du code pour DirectX. L'apport de Mono ne me parait pas vraiment intéressant dans ce contexte. C'est juste une couche supplémentaire qui va ajouter de la complexité et bouffer des performances sans apporter grand-chose de concret...
C++ s'impose dans l'industrie du jeu vidéo non seulement pour des raisons historiques mais aussi (et surtout) parce que c'est jusqu'à aujourd'hui le seul langage qui permet de faire aussi bien du haut niveau que du bas niveau (voir très bas niveau) sans rajouter de couche d'interop superflue.
Je pense même personnellement que les nouveautés apportées par la nouvelle norme C++11 vont assoir cette domination pour les applications temps réel (notamment ces aspects multi-threading, GC, ...).
Aussi bien dans l'industrie du jeux vidéos que pour les CAO industrielles.
Linux > *
Exemple de jeu qui cartone tout en n'étant pas en C++: Minecraft (c'est du Java)
C# TRES bon pour des petits jeux. Imaginez vous jouer à un Call of Duty ou à un Crysis en C#, ou si alors avec une machine des années 3000.
Quand on voit que C# est utilisé dans le framework de jeu XNA et également dans le moteur de jeu Unity, on aurait tord de se priver d'autant que ce dernier fournit d'excellents résultats que ce soit sur PC ou sur MAC (les autres plateformes suivent également, ios, android, wii...)
Mais Linux est soigneusement évité par Unity (du moins de ce que j'en ai vu sur les forums) pourtant mono existe sous Linux...
Copier c'est copier; voler c'est vendre un CD une vingtaine d'euros!
Code C : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
Le C# peut avoir des performances excellentes. Naturellement bonnes, du fait que ce nest PAS un langage interprété, ce qui le rend équivalent au C++ en terme de rapidité (instructions par secondes disons).
Après, au final, le C# gère plus de choses, des objets plus complexes, un garbage collector, ... donc au final, comme cela a déja été dit, on sacrifie un peu de performances pour une meilleures sécurité.
Le C# manques d'optimisations "spécifiques". La ou en C++ vous vous seriez passé d'un mécanisme de vérification quelquonque, le C# va le mettre en place a chaque fois.
Il est vrai qu'en C++, on peut gérer plus finement la mémoire, tout ca, mais si au final, on ré-implémente toutes les sécurités du .NET pour avoir un code "sur"..., autant coder en C# directement....
Sans compter que le C# autorise des accès mémoire non managés grace a l'instruction 'unsafe' (qui porte bien son nom : avec elle, vous pouvez faire n'importe quoi...), et qui, bien utilisée, peut permettre des performances décoiffantes, sans perdre trop de "sureté"...
De plus, certains on dit un jeu en C# vaut mieux qu'un jeu en C++ mal codé. Je suis d'accord avec ca. Mais rien ne dit que le jeu C# est bien codé
Et je pense qu'un jeu en C# tres bien codé peut venir titiller un jeu C++ bien codé, question performances...
Alors pourquoi pas de jeux en C# ? Et bien parceque toute la base est en C++... les moteurs graphiques le sont, les gens qui travaillent dessus sont des "spécialistes" C++, les codes a réutiliser sont en C++.
Pour voir des jeu en C# apparaitre, il va falloir regarder des Indy effectivement, qui partent de rien, et qui ont besoins de développer 'rapidement' un jeu.
Au rythme ou ca va acuellement, coté améliorations du C#, et coté amélioration des performances des PC, je pense que les premiers "grand" jeux populaires en C# devraient appaitre d'ici 5 a 10 ans. Ce n'est qu'une estimation a la louche, mais vu la bonne facture de certains jeux "complets" en C#, ca me semble plausible.
Pour un jeu entierement C#/XNA, il y a Magicka, aussi disponible sur Steam. C'est un jeu de bonne facture, avec de bonnes idées, ... mais qui demanderai un peu d'optimisation coté performances
The magic of Opera, La magie de l'Opera
The mysteries of Space Opera, Les mystères de l'Opera Spatial
Mr. Know-it-all, M. Je-Sais-Tout
Prelude in C sharp minor, the most beautiful piano song and the best C sharp prelude ever, Prélude en do dièse mineur, le plus beau morceau de piano et le meilleur prélude au C#
The Mesmerizing Saphir Division for Nerds, L'Hypnotisante Division Saphire pour les Nerds (HDSN)
pour tuer définitivement la bête: C# _est_ lent, il ne suffit pas de générer du code assembleur pour être rapide. Les gens qui disent qu'on peut atteindre la même vitesse en C# qu'en C++ sont des gens qui ne connaissent pas la vraie architecture d'un processeur, et C# comme Java violent toute les lois de rapidité.
Les CPUs sont bien de plus en plus rapide mais le vrai bottleneck des applications Java et C# c'est l'utilisation intempestive de la mémoire.
Le vrai problème c'est que la machine virtuelle utilise beaucoup de mémoire (ce qui est déjà un problème en soi) qui ne tient pas forcément dans le cache.
alors oui une fois qu'on a compilé son programme d'exemple de 14 lignes appliqué a un problème bien spécifique, le C# rivalise avec le C++ voire même le bat (encore que les gens qui disent ca ont sans doute jamais utilisé le profile-based optimisation)
oui oui oui ca c'est vrai, mais si chaque méthode arrive a peu près a la vitesse du C++ individuellement, a chaque retour de fonction tu peux te taper des cache-miss qui vont faire pauser le processeur en attendant que les données soient transférées de la mémoire au cache ou au registre, et on a beau avoir un dudecacore a 5,27 petahertz, c'est un processeur qui est en pause. Sans compter que ce que tu viens de ramener du cache pour la machine virtuelle vient peut-être de prendre la place de données précieuses dans le cache que tu vas peut être devoir retransférer dans quelques microsecondes.
après si une application C# est (mettons, c'est un chiffre) 2 fois plus lentes qu'une application C++ (bien codée), avec c'te vitesse on fait quand même des merveilles.
mais code natif ne veut pas dire code rapide, bordel de diou.
Lorsqu'un programmeur de jeu vidéo essaye de faire de la perf, utiliser C# rend ca impossible. Utiliser C++ rend ca possible (mais pas facile, ni automatique). Dans 99% des cas les gens ils y verront pas la différence entre une application C++ faite par un étudiant qui ne connait pas l'architecture du proc et un developpeur C# qui débute, le C# c'est vachement bien. Mais dés lors qu'il faut traiter un batch de données en utilisant le cache CPU a fond et en foutant tout sur le coproc SSE (sans jamais transférer vers la FPU sinon c'est immédiatement une pause du processeur aussi) on peut plus utiliser C#, c'est tout.
Pour tout le reste, C# c'est bien, c'est souvent mieux, plus moderne, plus facile a lire, plus beau, et ca faut la vaisselle quand vous avez le dos tourné. Mais si vous connaissez un minimum le CPU vous pouvez faire un x10 avec une gestion correcte de vos données et une attention toute particulière au code écrit en C++. say tout.
les deux mon capitaine!
Tout d'abord, le C# la CLR et la CLI sont des standart ecma LittleWhite ! Ensuite mono supporte .NET 4.
Toujours pour LittleWhite concernant DirectX, qui n'est pas utilisé sur console, (même pas sur xbox360 où l'on préfère faire du "direct to metal"), c'est hors sujet car tu auras de tout manière le même problème en C++. Il existe des solutions comme http://www.opentk.com/ pour faire du jeu en mono portable, et maintenant android (monoDroid arrive, et même sur iphone, un projet dont je n'ai plus le nom permettrai d'exporter un projet XNA vers iOS natif/statique) et tu peux très bien faire du C# sur ps3 et Wii, le problème se situe plus à l'obtention d'un sdk
Côté performance je suis d'accord on ne peut égaler un programme écrit en "super assembleur", mais les projets a un certain niveau de complexité deviennent vraiment pas "optimisable" (ou alors t'y passe ta vie) et on commence à dépendre de plus en plus de middleware, d'OS multitâche (empêchant certaine optimisation), donc cela va être de moins en moins problématique (au niveau production s'entend) de passer par du code managé.
Pour moi le problème est plus de savoir s'il faut se coltiner les "lourdeurs" du c++ (même avec une nouvelle norme bien venue), je pense notamment au manque de réelle framework/librairie standard... ou sacrifier une certaine neutralité.
Sinon concernant OSX et iOS ca se code en Objectiv-C et pas en c++, alors oui ok on peut utiliser des lib en c++ (orgre3d etc), mais tu peux également le faire en C# via des pInvoke par example. Pour arithmétique de pointeur il existe, faut il le rappeler un mode "unsafe" en C#/CLI.
Sinon juste pour rire avant le C++ on en voulait pas dans le jeu vidéo, c'était du C (car on maitriser le code de sortie), et avant ça l'assembleur, et encore fallait être conscient qu'un appel au stack coutait quelquechose comme 200 cycle (toujours d'actualité quand tu appel la moindre méthode en c++ donc) !!!
EDIT: oops excusez si mon post n'est pas pertinent, j'avais pas les commentaires après les 6 premiers!!!!
Aaaah.
Il n'y a PAS de machine virtuelle en C# boudiou...
La machine virtuelle, laissez-la au Java s'il vous plait
Ensuite l'histoire des cachemiss, machin truc, SSE, patin couffin : c'est pas du ressort du code C#, c'est effectivement du ressort du JIT (qui n'est donc pas une machine virtuelle), mais le JIT peut théoriquement optimiser tres correctement le code, et optimiser l'utilisation du cache processeur.
Alors le probleme bien sur, c'est que c'est de l'optimisation générale, et pas particuliere, donc en prenant un cas particulier, on peut toujours *mieux* faire, et ensuite, c'est sur que si vous voulez tout optimiser au poil de c****** près, c'est sur il faut descendre en langage machine.
En plus l'instruction unsafe permet pratiquement d'ecrire du code C++ et de travailer directement avec la mémoire...
Ensuite, je ne connais pas la qualité des code généré par le JIT, c'est peut etre pas top, c'est peu etre excellent, je ne sais pas. Mais c'est toujours améliorable.
Ensuite, si vous developpez en C++, vous passez aussi par un compilateur, et meme si il est très un bon, il n'est pas toujours parfait dans tous les cas non plus.
Encore mettre C# et Java en meme temps... Non la consomation mémoire d'une appli en C# est très faible (peut etre parcequ'il n'y a pas de machine virtuelle ?), plus qu'en C++ pour une application équivalente peut etre, mais parceque le C# gere des objets plus complexes, et implémente plus de choses.
Cf un benchmark en première page du topic.
M'est avis que tu connais très bien comment marche un processeur, mais que pour le C#, tu as une connaissance un peu trop fragmentaire de la chose (et non, ce n'est pas du tout le meme mécanisme que Java, meme si il y a un code intermédiaire de généré.)
The magic of Opera, La magie de l'Opera
The mysteries of Space Opera, Les mystères de l'Opera Spatial
Mr. Know-it-all, M. Je-Sais-Tout
Prelude in C sharp minor, the most beautiful piano song and the best C sharp prelude ever, Prélude en do dièse mineur, le plus beau morceau de piano et le meilleur prélude au C#
The Mesmerizing Saphir Division for Nerds, L'Hypnotisante Division Saphire pour les Nerds (HDSN)
Le dernier message de screetch résume parfaitement bien les choses.
Oui, et le JIT marche bien. Mais la CLR, le garbage collector, toutes les facilités d'introspection, toutes les vérifications offertes par le langage qui te garantissent qu'il n'y aura pas de segfault, les exceptions, les vérifications pour les accès aux tableaux (même si elles ne sont pas toujours faites)... tout ça, c'est génial en temps normal. Mais c'est un coût. C'est un choix de design, troquer un peu de performance (dans beaucoup d'applications, on ne s'en rend même pas compte) contre de la sûreté.mais le JIT peut théoriquement optimiser tres correctement le code, et optimiser l'utilisation du cache processeur.
En C++, tu choisis exactement ce que tu veux payer. Il y a même besoin de mettre le mot-clé virtual si on veut s'offrir une vtable. Je règle même mon compilateur C++ pour désactiver le système d'exceptions et ne pas avoir à le payer.
Le JIT est rapide et c'est difficile de faire mieux tout en respectant les spécifications du langage. Le JIT doit même vérifier si une valeur est à null avant de la déréférencer pour pouvoir lancer l'exception qui va bien ; en C++, le compilo s'en fout si le programme plante lamentablement au final.
Note aussi que le compilo C# (enfin, l'implémentation de Microsoft) n'optimise pas les tail calls. Les compilos C++ sont bien plus performants là-dessus (g++ fait même des miracles). Ça, plus tous les arguments donnés par screetch (cache-miss, SSE et compagnie).
C'est ce qu'il dit. En C++, on peut descendre au bas-niveau, alors qu'en C# il reste une couche d'abstraction (ce qui est une bonne chose dans 99% des cas). Pour la majorité des jeux, on s'en fout, mais la discussion est pour les jeux AAA.Alors le probleme bien sur, c'est que c'est de l'optimisation générale, et pas particuliere, donc en prenant un cas particulier, on peut toujours *mieux* faire, et ensuite, c'est sur que si vous voulez tout optimiser au poil de c****** près, c'est sur il faut descendre en langage machine.
+10 avec l'argumentaire de screetch, il n'y a rien à redire c'est exactement ça.
Ce n'est pas parce que le service marketing de Microsoft a dit de ne pas appeler ça une machine virtuelle que ça n'en est pas une, hors au niveau des fonctionnalités c'est flagrant.Il n'y a pas de machine virtuelle en C# boudiou...
La machine virtuelle, laissez-la au Java s'il vous plait
et la la marmotte elle met le bytecode dans le processeur?Aaaah.
Il n'y a PAS de machine virtuelle en C# boudiou...
La machine virtuelle, laissez-la au Java s'il vous plait
sérieusement, si il ne faut pas appeler ca une machine virtuelle, OK, remplace "machine virtuelle" par "JIT" dans mon post, il reste pertinent.
Le JIT n'opère pas par magie,
mais ce queje critique (car tu n'as pas lu) ce n'est pas le code généré, mais les resources occuppées par le JIT lui même. Peut etre le JIT fera du meilleur boulot sur le code généré en faisant une analyse du code, mais cette analyse de code n'est pas gratuite, elle tourne aussi sur le CPU, et le compilateur JIT utilise le CPU, et il utilise la bande passante de la mémoire et le cache du processeur.Ensuite l'histoire des cachemiss, machin truc, SSE, patin couffin : c'est pas du ressort du code C#, c'est effectivement du ressort du JIT (qui n'est donc pas une machine virtuelle), mais le JIT peut théoriquement optimiser tres correctement le code, et optimiser l'utilisation du cache processeur.
Après le code généré par le JIT il est peut-être très bien hein, mais le JIT lui-même n'est pas gratuit.
un peu hors sujet du coup puisque je ne critique pas le code généréAlors le probleme bien sur, c'est que c'est de l'optimisation générale, et pas particuliere, donc en prenant un cas particulier, on peut toujours *mieux* faire, et ensuite, c'est sur que si vous voulez tout optimiser au poil de c****** près, c'est sur il faut descendre en langage machine. En plus l'instruction unsafe permet pratiquement d'ecrire du code C++ et de travailer directement avec la mémoire...
Ensuite, je ne connais pas la qualité des code généré par le JIT, c'est peut etre pas top, c'est peu etre excellent, je ne sais pas. Mais c'est toujours améliorable.
Ensuite, si vous developpez en C++, vous passez aussi par un compilateur, et meme si il est très un bon, il n'est pas toujours parfait dans tous les cas non plus.
cf mon post plus haut, un benchmark avantage les petits problèmes et les fonctions locales. Un benchmark ne sert a rien.Encore mettre C# et Java en meme temps... Non la consomation mémoire d'une appli en C# est très faible (peut etre parcequ'il n'y a pas de machine virtuelle ?), plus qu'en C++ pour une application équivalente peut etre, mais parceque le C# gere des objets plus complexes, et implémente plus de choses.
Cf un benchmark en première page du topic.
J'admets que le C# tourne plus vite que Java si je compare les outils d'IDE de microsoft par exemple contre les outils Eclipse ou Netbeans qui sont codés en Java. On voit bien que Java souffre de beaucoup de lenteurs. Mais ca ne fait pas de C# un miracle...
OK j'ai les mauvais termes, mais je ne ferme pas les yeux sur ce qui se passe, je vois bien. J'ai d'ailleurs travaillé un peu sur Mono et je sais (pas bien, mais je comprends) comment ca marche.M'est avis que tu connais très bien comment marche un processeur, mais que pour le C#, tu as une connaissance un peu trop fragmentaire de la chose (et non, ce n'est pas du tout le meme mécanisme que Java, meme si il y a un code intermédiaire de généré.)
Mono a ou avait 3 modes de fonctionnement:
Interprété (qui etait le seul mode dispo pour certaines architectures, puisqu'il etait difficile de generer du code pour SPARC par exemple vu le faible nombre d'utilisateurs et de coders dessus), JIT, AOT (Ahead of Time) qui etait (est?) experimental a l'epoque ou j'ai triffouillé.
Et le JIT fonctionnait ainsi: les fonctions etaient remplacées au chargement par un stub qui se chargeait de compiler la fonction (le bytecode) et de remplacer le stub par le code compilé en accédant aux informations Runtime de mono (les infos runtime+ces stubs qui ocmpilent le code c'est ce que j'appelle la machine virtuelle)
le code C++ que l'on a se compile en 10 minutes. Pour moi, même si le code C# etait plus simple, il devrait prendre quand même 5 minutes pour compiler en JIT l'integralité du bytecode. C'est pas pour ca que c'est gratuit, c'est juste fait a un autre moment, et ca pompe des resources qui pourraient etre disponibles pour le jeu.
et puisqu'on aime effacer les parties ou je dis que C# est bien histoire de me faire passer pour un integriste, je repète que C# est plus adapté que C++ pour 99% des projets, pour lesquels payer pour le JIT n'est pas un problème visible.
(ca commence a me courir sur le haricot que je dise que le C# est aussi bien ou "mieux" que le C++ dans 99% des cas et y'a toujours un gusse qui vient râler pour le dernier pourcent, en niant les faits présentés plus haut et en évitant soigneusement de quoter que je dis que C# c'est bien)
Ca c'est parce que tu n'es pour qu'à 99%
Il y aura toujours un fan boy pour te dire que c'est faux même si la théorie ET les faits sont là, si tu ne prend pas ta carte à leur secte tu es forcément en tord
JIT ? Comme HotSpot, tu veux dire ?Aaaah.
Il n'y a PAS de machine virtuelle en C# boudiou...
La machine virtuelle, laissez-la au Java s'il vous plait
Ensuite l'histoire des cachemiss, machin truc, SSE, patin couffin : c'est pas du ressort du code C#, c'est effectivement du ressort du JIT (qui n'est donc pas une machine virtuelle), mais le JIT peut théoriquement optimiser tres correctement le code, et optimiser l'utilisation du cache processeur.
Alors le probleme bien sur, c'est que c'est de l'optimisation générale, et pas particuliere, donc en prenant un cas particulier, on peut toujours *mieux* faire, et ensuite, c'est sur que si vous voulez tout optimiser au poil de c****** près, c'est sur il faut descendre en langage machine.
En plus l'instruction unsafe permet pratiquement d'ecrire du code C++ et de travailer directement avec la mémoire...
Ensuite, je ne connais pas la qualité des code généré par le JIT, c'est peut etre pas top, c'est peu etre excellent, je ne sais pas. Mais c'est toujours améliorable.
Ensuite, si vous developpez en C++, vous passez aussi par un compilateur, et meme si il est très un bon, il n'est pas toujours parfait dans tous les cas non plus.
Encore mettre C# et Java en meme temps... Non la consomation mémoire d'une appli en C# est très faible (peut etre parcequ'il n'y a pas de machine virtuelle ?), plus qu'en C++ pour une application équivalente peut etre, mais parceque le C# gere des objets plus complexes, et implémente plus de choses.
Cf un benchmark en première page du topic.
M'est avis que tu connais très bien comment marche un processeur, mais que pour le C#, tu as une connaissance un peu trop fragmentaire de la chose (et non, ce n'est pas du tout le meme mécanisme que Java, meme si il y a un code intermédiaire de généré.)
http://fr.wikipedia.org/wiki/Compila..._la_vol%C3%A9e
Il faut bien distinguer le concept de machines virtuelles (qui est assez flou) et celui de modèle d'exécution.
Les modèles d'exécution
La compilation pure et simple (C, Vala etc.)
On écrit du code pour une machine, et on compile en langage machine.
Avec du C :
Source -> production du code machine -> éxecution
Avec Vala , au fond, c'est pareil :
Source -> production d'un source en C -> prod code machine -> éxecution
Bytecode ou AST interprété(Perl, Lua...) :
Le code source est traduit dans un représentation intermédiaire (bytecode pour Lua, Arbre Syntaxique pour Perl), puis interprété : le code machine est produit à mesure que le code intermédiaire est "lu".
Perl est quand même un peu à part car la phase de traduction en représentation intermédiaire est difficile à distinguer complètement de la phase d'interprétation .
Source ->bytecode -> lecture du bytecode & production code machine & exécution [simultané]
Compilation dynamique (LISP, Objective-C aussi il me semble) :
Le compilateur peut-être lancé pendant l'exécution afin de créer des fonctions compilées qui "s'adaptent" à l'état du programme.
Source -> bytecode -> lecture du bytecode & prod code machine & exécution & prod bytecode à la volée & lecture & exécution etc.
JIT (Java, .NET, Python...) :
La première étape est la création d'un bytecode que l'on peut déployer sur les machines disposant de l'environnement d'exécution adéquat. Ensuite, à l'éxecution, le bytecode est traduit à la volée en langage machine. Quelle différence avec l'interprété ? C'est le cache !
Source -> bytecode -> lecture bytecode & prod code machine & mise en cache & exécution [la mise en cache précède intelligemment l'exécution].
Le concept de "machines virtuelles" :
Le terme machine virtuelle ne doit pas induire en erreur. C'est quoi une machine virtuelle appliquée à la programmation ? C'est juste l'idée de l'isolation d'une application des spécificités d'une machine.
Il s'agit moins d'une technique particulière, que des fonctions dont dispose un langage.
Ainsi, au fond, tout langage de programmation produisant un "code intermédiare" quelconque, que ce soit du bytecode ou un arbre syntaxique, et qui dispose de suffisamment de fonctions permettant de produire du code multiplateforme, peut-être dit "disposant d'une machine virtuelle".
Par exemple, prenons un langage BABA qui créé un bytecode et fait du JIT mais qui ne dispose (que ce soit en interne ou dans sa bibliothèque) que des fonctions spécifiques à Windows sur proc x86, peut-on dire qu'il dispose d'une machine virtuelle ? Non.
Prenons un langage comme Perl, qui est "simplement" interprété, mais qui dispose de tout l'attirail lui permettant de produire du code parfaitement exécutable sans modifications sur tous les système disposant de l'interpréteur en question. Comment lui dénier le concept de machine virtuelle ?
Parce qu'il n'a pas JIT ? Mais, enfin, les premières versions de Java, qui ont popularisée le mot de "machine virtuelle", ne disposaient pas de JIT non plus !
Bref, le concept qui se cache derrière le mot de machine virtuelle remonte aux premiers langages interprété de haut niveau. Java n'a fait que populariser un mot.
Bref, .NET et Java, ici, c'est kiff-kiff
JIT again
- Donc en JIT on obtiens bien un code machine ou pas ? si c'est compilé avant d'être exécuté (une seule fois donc), il n'y a plus de trace de runtime si? je sais pas ce qu'est un stub alors pardonnez-moi.
- Sinon on peut imaginer un compilo qui crache du code machine pour un déploiement sur une configuration précise n'est pas ? et la compilation, JIT ou pas, vas certainement s'améliorer et permettre d'optimiser ces histoire d'appel à la mémoire etc non ?
- Carmack qui conseille d'apprendre directement le C# ça n'est pas rien non plus ! Même en AAA je pense qu'on va de plus en plus vers des architectures "n-tiers", de ce fait on ne pourra plus optimiser comme avant. Il y aura toujours des spécialistes d'optimisation CPU, mais là ou pourrait même aller à coder en C et Assembleur ... (comme pour les OS aujourd'hui si je ne me trompe pas).
Je pense qu'il y aura toujours du C++ et même de l'assembleur (d'ailleurs on bypass les API directX sur xbox maintenant je crois, c'est dire...) mais que la complexité des architecture des jeux AAA veront de plus en plus de "couches" faite en C#, quand au jeu indépendant XNA est vraiment magnifique...
- En Java et C# : GC pose t elle toujours problème (ralentissement non prévisible...) ?
Le bytecode est compilé en code machine à la volée. Au lancement du programme, quelques fonctions sont compilées et le programme peut s'exécuter. Les autres fonctions sont compilées à la demande. Donc le JIT a du travail à faire, pas uniquement au démarrage du programme. Dans un jeu, c'est quasiment le même code qui est exécuté en boucle. Donc rapidement tout sera compilé et le JIT pourra se reposer.
Le JIT est rapide et ce n'est pas vraiment le problème. D'ailleurs, il est aussi possible de compiler le bytecode en avance (--aot sous Mono, ngen chez Microsoft) et de ne plus payer ce coût.
Oui, il va s'améliorer. Mais il y aura toujours des coûts supplémentaires que le C++ n'a pas à payer ; ça a déjà été cité plusieurs fois, le C# offre des garanties en matière de sûreté et doit faire des vérifications supplémentaires.
Je pense aussi.
Oui, si on ne fait pas attention. Là où en C++ les allocations et désallocations prennent toujours quasiment le même temps, en C#, c'est le GC qui passe une fois de temps en temps. Le GC peut donc entrainer un ralentissement visible occasionnel.
Mais, on peut faire attention... Si je devais faire un jeu en C#, je ferais très attention à ne faire aucune allocation dans la boucle principale (d'ailleurs, il vaut mieux faire ça en C++ aussi).
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager