le runtime pouvant peser son poids en megaoctets, c'est aussi le cache du CPU qui est potentiellement foutu en l'air a chaque appel de méthode.
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
le runtime pouvant peser son poids en megaoctets, c'est aussi le cache du CPU qui est potentiellement foutu en l'air a chaque appel de méthode.
Ouai donc en gros c'est vraiment juste des petits batch d'instructions qui sont transformés en byte-code et stockés, donc encore une grosse place pour l'interpréteur et plein d'optimisations qui sautent quoi.
ha oui, aussi, ne pas oublier le cache d'instructions qui a du mal avec ce genre de blagues
* Il est infiniment plus simple de faire rapidement un code qui marche que de faire un code rapide qui marche
* pour faciliter les recherches, n'oubliez pas de voter pour les réponses pertinentes
Mes articles
Tu exagères un peu (les appels de fonction ne sont pas tous virtuels, il y a un opcode spécial pour les appels virtuels, les autres sont directs ; le JIT est capable de supprimer une partie des vérifications des limites des tableaux ; les generics, bien mieux conçus qu'en Java, éliminent aussi pas mal de boxing), mais tu as raison, c'est l'idée. Bref, sacrifier un peu de performance contre de la sûreté est tout à fait pertinent pour la plupart des applications, mais pas pour du temps-réel quand on veut tirer le maximum de la machine.Envoyé par bafman
C'est bon de le rappeler. Trop de gens croient qu'il suffit de faire du C++ pour avoir du code performant. Quand on ne maitrise pas le C++, il y a trop de pièges dans le langage (oublier un simple "&" peut détruire les performances) et on n'est pas certain de faire mieux qu'en C#.Bon, par contre, pour faire du code VRAIMENT performant, ça ne resoud rien du tout le JIT. Pour cela, il faut au minimum l'ensemble des caractèristiques suivantes :
Ca offre des gains intéressants, mais le support SIMD est très partiel (la dernière fois que j'ai regardé). Ils ont aussi mis un backend LLVM dans Mono, ça améliore peut-être des choses. Mais ça ne rivalisera toujours pas avec du bon C++. J'attends avec impatience que ça soit ajouté dans Microsoft .NET(et utilisable explicitement).je croit qu'il existe une implementation de SIMD sous mono, mais je ne sais pas ce que ça donne au niveau performance
S'il te plaît... n'utilise plus le mot interpréteur dans cette discussion. Dans .NET (contrairement à Java il y a des années), ils n'ont même pas codé d'interpréteur de bytecode.donc encore une grosse place pour l'interpréteur
oui, bon, ok, c'est un peut exagerer et le JIT arriva parfoit à supprimer des appels virtuel. Par contre, je ne suis pas d'accord sur le fait que ça sacrifit un peu de performance. Pour moi, ça en fait perdre beaucoup
Alors la, 100% d'accord. C'est d'ailleurs, a mon avis, un des principaux problèmes du C++. Mal utilisé, il peut facilement donner des perf catastrophiques, et bien l'utilisé, c'est vraiment compliqué. C# a comme aventage la dessus qu'on programmeur moyen sur du code standard aura probablement de meilleurs perf qu'un programmeur moyen en C++ sur le même type de code. Par contre, quand il s'agit d'aller dans du code performant, c'est une autre histoire
Ok, merci pour l'info. Par contre, j'ai du mal a voir comment il vont faire pour regler les problèmes d'alignement memoire et autre qui sont les vrai difficultés de l'utilisation d'instruction SIMD.
* Il est infiniment plus simple de faire rapidement un code qui marche que de faire un code rapide qui marche
* pour faciliter les recherches, n'oubliez pas de voter pour les réponses pertinentes
Mes articles
Alors là il se dit n'importe quoi dans ce topic.
C# n'est pas fondamentalement plus lent que C++ par contre je connais un paquet de très mauvais développeurs C++.
Ensuite le coup du DX est mal intégré avec C#, il faut pas si être intéressé pour dire cela: SharpDX ou SlimDX en son 2 excellents exemples, je vous défi de les mettre à genoux.
Idem pour opengl avec OpenTK.
Quant à XNA c'est une excellent prise en main pour débutant voir même pour confirmer ne souhaitant pas réinventer la roue.
Chacun prêche pour son langage favoris par contre avant d'enterrer une techno il faudrait y prêter un peu attention.
C++ a surtout l'avantage de l'existant, de nombreux outils existent et les boîtes qui ont investies des années sur la formation et la mise en place d'architecture ne vont pas tout jeter au orties pour un passage à .NET, et cela se comprend.
Si c'est quand même fondamentalement plus lent, ça ne serait pas le cas si le code exécuté était un bloc unique en langage natif, hors ce n'est pas ce qu'il se passe et la compilation à la volée ne fait pas tout. La segmentation du cache, le garbage collector sont des éléments que l'on peut éviter en C++ et qui font que C# est plus lent que le C++.
Après bien sûr que l'on peut pondre un code moins performant en C++ qu'il ne pourrait être en C# (dans quel langage ce n'est pas possible). S'il y a un paquet de très mauvais développeurs en C++ c'est surtout parce que c'est LE langage d'apprentissage en général. C'est le langage par lequel beaucoup commence pour apprendre la programmation. Et vu que c'est aussi plus répandu il y a forcément plus de personnes moins bonnes dans ce langage qu'en C# comme il y a surement plus de personnes meilleurs dans ce langage que dans le C# aussi.
Après pour comparer deux langages je ne suis pas sûr qu'il soit objectif de prendre le cas de deux amateurs qui font un benchmark mais plutôt deux professionnels qui connaissent bien leur langage respectif.
Mais je suis tout à fais d'accord avec toi il y a beaucoup de "mauvais" développeurs (pas qu'en C++ d'ailleurs, quand on voit la gueule des benchmarks C#/C++ par exemple on voit clairement que le développeur n'a fait du C++ qu'aux pauses déjeuners et nous pond un comparatif aux données bien étranges).
Certes, et même que j'aurais bien été content que ça existe quand j'ai commencer la programmation puis la 3D ça m'aurait grandement facilité la vie.
Personne n'enterre cette technologie il ne faut pas te sentir attaquer, on essaye juste de la placer "dans une boite". Si les derniers posts étaient assez incisifs c'est parce que l'on parlait d'un thème précis, les applications hautes performances où le C# n'excelle pas, cela ne veut pas dire que c'est un langage bon à rien bien au contraire.
Je sais pas pourquoi, mais à chaque fois qu'on parle d'un du débat du genre "Tel langage est-il adapté à la création de jeu vidéo?" ou "quel langage est le meilleur pour créer un jeu vidéo?" on tombe toujours dans l'incontournable discussion des performances, comme si c'était LA chose la plus importante. Dans la plupart des cas c'est plutôt superficiel, et ce, pour plusieurs raisons.
Mais bon, pour le C# plus spécifiquement, les performance ne sont pas si horrible que ça ? Bien sûr, avec le C++ on peut utiliser des optimisation comme le instruction SSE, et c'est bas niveau de base, il n'y a pas de garbage collector, etc. Par contre le C# reste quand même très performant, et il permet très bien faire du temps réel.
Il a été dit que le C# c'est interprété(Comme le Perl/LUA ?). C'est faux, le C# utilise un compilateur JIT qui est super optimisé et qui compile nativement le code au fur et à mesure qu'il interprète le code, donc le code n'est pas interprété, mais compilé. Enfin, on a fait des tests avec une compilateur qui compilait en binaire natif le code c#, et un qui utilisait le JIT de .NET et il n'y avait pratiquement aucune différence de performance. Par contre, Il y a une bonne différence entre les langages interprétés(Perl, Python, LUA) et le JIT de C#. En plus, le c# a le code unsafe, qui permet d'optimiser un peu plus(pratiquement au niveau du C++).
De plus, le c# n'a pas nécessairement la même vocalité que le C++. Le C++ on ne l'utilise pas pour faire directement des jeux dans l'industrie(Enfin, c'est très rare maintenant qu'on code un jeu qu'en C++). Il est utilisé pour programmer les parties critiques en performance d'un jeu, on l'engin en tant que tel, ensuite le gameplay est codé dans un langage de script(Exemple: Python, C#, LUA). Ces langages de script ont un taux de productivité plus grande que le C++, et sont plus facilement accessible.
Enfin, même si le C++ est plus performant que le c#, la différence peut être négligé dans beaucoup de cas. Le rapport productivité/performance du c# est meilleur, selon moi, que celle du C++, ce qui fait que c'est super intéressant pour les développeur qui veulent faire des jeux indépendant, des jeux amateurs et même des jeux pro. Minecraft n'a pas eu besoins du C++ pour se vendre à plusieurs millions d'exemplaires, il a été codé en java.
La plupart des jeux PC aujourdhui sont beaucoup plus GPU intensif que CPU intensif. Un jeu va "lagger" parceque les graphiques sont trop exigeant, mais la demande en graphisme est beaucoup plus dépendante au GPU qu'au CPU ce qui fait que le langage utilisé sur le CPU peu se permettre plus facilement d'être moins performant. Autrement dit, la qualité des graphiques ne dépend pas du langage énormément du langage CPU(C++ ou C# disons), mais plutôt de la puissance de calcul du GPU.
Enfin, selon moi, le C# est le meilleur moyen d'apprendre la programmation de jeu, de créer de petits jeux/frameworks rapidement, de créer des outils pour un engin, de scripter du gameplay pour un engin, et même de créer des jeux de pro de moyennes envergures sur PC/Xbox. Par contre pour les super jeux AAA, pour les engins de jeux, les points de performances critiques, le C++ reste le meilleur choix.
les langages de scripts ne sont pas très utilisés dans le jeu vidéo en général pour leur poids en mémoire (si lorsque tu démarres python tu perds directement 10% de ta mémoire tu reflechis a deux fois).
sans compter l'absence de C# sur la PS3 qui est aussi un fait très bloquant.
J'ajouterai que le C# n'est pas possible sur les titres non LiveArcade sur XBox, cela le cantonne aux titres Indy.
de plus tu essayes toi même d'être l'avocat de la performance du C# tout en disant que ce n'est pas le point le plus important... je ne comprend pas bien
pour etre franc dans ce post les intervenants n'ont pas été très "fanboys" et ont levé des points plutôt objectifs (des points précis sur la performance et sur la portabilité). ce n'est pas un denigrement complet du langage mais simplement une liste des points faibles. Lesn ier c'est juste foncer droit dans le mur (libre a toi). Les connaître et pouvoir dire "ce n'est pas un problème pour moi" est une énorme qualité, c'est plus sympa.
comme tu dis beaucoup de jeux n'auront pas ce problème de performance, beaucoup de jeux seront limités par du codage de merde (franchement). Beaucoup de jeux ne pourront pas dépasser le stade du concept, tout simplement car codés au dessus de leurs moyens. Et en général le C++ fait partie des trucs "au dessus de leurs moyens" justement. C# peut être d'une grande aide pour ces développeur, une aide a la productivité. C# est plus moderne, plus simple (même que java) et plus sécurisé.
De la a l'utiliser sur Battlefield 3 (ce que l'auteur original impliquait) il y a un pas que personne de l'equipe Frostbite ne fera.
Au contraire, les langages de script sont très utilisés dans le jeux vidéo. TOUT les engins de jeux AAA utilisent une quelconque forme de langage de script. L'unreal Engine avec UnrealScript/Kismet, le Cryengine avec LUA, l'Infernal engine avec Dante Scripting, Insomniac Games(Pyhon pour tools), Unity avec C#/Mono. Et j'en nomme que quelques uns.
Le C# n'est pas absent sur PS3. Avec Mono/C# on peut compiler sur PS3, ainsi que la Wii. Même sur IPhone et Android. Et c'est faux, certains jeux LiveArcade de dev Indie sont fait avec Xna/C#, depuis le début de Xna il y a quelques années. Autre exemple, Les Sims 3, un jeu AAA qui est multiplatforme a été programmé en partie en C#/Mono.
Je vais éclaircir mon point: Les performances sont importantes, mais jusqu'à un certain point. Les performances du C# ne sont pas dramatique. Au final, je trouve que le C# offre un meilleur rapport Productivité/Performance que le C++ sauf pour le développement où la performance est excessivement critique(Dev sur console) ou jeux AAA. Par contre, même sur les jeux AAA(Même console de salon) la performance du C# peut être acceptable pour le scripting.
Je suis simplement réaliste. Certains arguments sur la performance du C# étaient faux(Exemple, le C# n'est pas interprété). De plus, j'en parle parce que beaucoup de gens ont la fausse idée qu'il faut le plus de performance possible pour créer un jeu, alors qu'au final, dans la plupart des jeux indépendants/amateur(Qu'on retrouve sur ce forum) ce n'est même pas important. Mais je ne dit pas que le C# est mieux que le C++, c'est du cas par cas, c'est très important d'apprendre le C++ si on veut travailler dans la création d'engin/outils de jeux pro. Si on veut être programmeur gameplay ce n'est pas si important par contre. De plus, si on ne veut que créer des jeux indépendants/amateur ou apprendre les concepts de la programmation de jeu(Qui sont très importantes et indépendantes du langage), on a plus de productivité avec un langage comme C#.
Je n'ai pas insinué que le Frostbite engine utilisait le C# ??? Enfin, les technos du Frostbite ne sont pas publique, à ce que je sache, par contre ils ont présentés leur langage de script par node au GDC pour scripter les shaders visuel, alors ça ne m'étonnerait pas qu'ils utilisent un langage de script pour le gameplay aussi.
Oui, enfin la partie de script seulement ... pas tout le jeu
Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi
Ma page sur DVP
Mon Portfolio
Qui connaît l'erreur, connaît la solution.
c'est vrai, mais dans tous les moteurs sur lesquels j'ai travaillé, a deux mois de la release on passait une grosse partie du langage de script en C++ a cause de perfs pas assez correctes (véridique...). Même sur l'unreal engine.
certes... le C# est techniquement possible mais n'est pas utilisé du tout sur PS3 et sur Wii, et tres tres peu sur iphone pour l'instant.Le C# n'est pas absent sur PS3. Avec Mono/C# on peut compiler sur PS3, ainsi que la Wii. Même sur IPhone et Android. Et c'est faux, certains jeux LiveArcade de dev Indie sont fait avec Xna/C#, depuis le début de Xna il y a quelques années. Autre exemple, Les Sims 3, un jeu AAA qui est multiplatforme a été programmé en partie en C#/Mono.
Comme je l'ai dit, il est plutot présent sur XBox live avec des jeux indy, ce qui est très bien. Certains de ces jeux ont une qualité visuelle eblouissante, qui n'est pas due a la technique mais a la direction artistique, ce qui prouve bien ton point (et arrete de te braquer, je suis en gros d'accord avec toi...)
c'est tout a fait vraiJe vais éclaircir mon point: Les performances sont importantes, mais jusqu'à un certain point. Les performances du C# ne sont pas dramatique. Au final, je trouve que le C# offre un meilleur rapport Productivité/Performance que le C++ sauf pour le développement où la performance est excessivement critique(Dev sur console) ou jeux AAA. Par contre, même sur les jeux AAA(Même console de salon) la performance du C# peut être acceptable pour le scripting. Je suis simplement réaliste. Certains arguments sur la performance du C# étaient faux(Exemple, le C# n'est pas interprété). De plus, j'en parle parce que beaucoup de gens ont la fausse idée qu'il faut le plus de performance possible pour créer un jeu, alors qu'au final, dans la plupart des jeux indépendants/amateur(Qu'on retrouve sur ce forum) ce n'est même pas important. Mais je ne dit pas que le C# est mieux que le C++, c'est du cas par cas, c'est très important d'apprendre le C++ si on veut travailler dans la création d'engin/outils de jeux pro. Si on veut être programmeur gameplay ce n'est pas si important par contre. De plus, si on ne veut que créer des jeux indépendants/amateur ou apprendre les concepts de la programmation de jeu(Qui sont très importantes et indépendantes du langage), on a plus de productivité avec un langage comme C#.
comme j'ai dit c'est ce que l'auteur original (celui du premier post) disait, pas ce que toi tu dis. L'auteur initial demande si un jour le C# remplacera le C++ pour les titres AAA comme Battlefield 3 ou les prochains jeux Frostbite, et donc, je réponds a cela que non, même si 95% des jeux devraient être fait en C#, les plus grosses productions devront toujours être faites en C++. Le problème principal n'étant pas la performance du code mais le poids en mémoire de la machine virtuelle (comme je l'avais dit plus haut) qui pompe immédiatement des mega octets.Je n'ai pas insinué que le Frostbite engine utilisait le C# ??? Enfin, les technos du Frostbite ne sont pas publique, à ce que je sache, par contre ils ont présentés leur langage de script par node au GDC pour scripter les shaders visuel, alors ça ne m'étonnerait pas qu'ils utilisent un langage de script pour le gameplay aussi.
d'ailleurs je remarque que tu as soigneusement évité de citer le paragraphe ou je dis du bien de C#, je trouve ca un peu limite.
Et non il n'y a pas de langage de script dynamique dans Frosbite, il n'y a que du C++. L'éditeur de shader (et l'éditeur en général) ponds des fichiers de données, pour créer des instances d'objets C++.
Le .Net et DirectX (via XNA) pour créer des jeux donne de très bonnes performances.
Ex: le projet OpenRails
Tu peux surtout faire du DX sans XNA (qui fait très joujou pour certain) en passant par slimdx qui est très bon ou encore SharpDX que j'utilise depuis quelques mois et qui est encore meilleurs (cocorico).
Pour les fans d’OpenGL il y a OpenTK.
Ecrire des algos avec LINQ est un vrai bonheur, sans pour autant faire l'impasse sur les perfs.
Je pense surtout que c'est l'existant, tant en terme d'outils que de compétences qui poussent à rester en C++, plus que la pauvreté des langages concurrents.
Bien que n'ayant pas d'expérience professionnelle dans la conception de jeux, je prédis aussi que les langages semi-compilés (C#, Java, Python...) feront finalement aussi une entrée dans le domaine. Mais la raison qui me pousse à cette conclusion est le multithreading et la gestion multicore. Evidemment que c'est possible de le faire sous C++, mais la différence de complexité de développement entre C++ et C# pour du multithread poussé me parait, à vue de nez, devenir rapidement trop grande pour que le développement en C++ reste rentable. L'aspect temps réel, facteur déterminant dans les jeux AAA, concerne surtout la programmation monocore. Alors que l'exemple opposé, supposons un jeu AAA sur le cloud, aurait une architecture radicalement différente, pouvant potentiellement mieux convenir à du semi compilé.
Bien entendu, ce n'est qu'une prédiction qui n'engage que moi et qui n'est basée que sur mon expérience de projets applicatifs.
Donc au final quasiment tout le monde est d'accord pour dire que le C++ dans le jeux vidéo n'est pas près d'être remplacé par un autre langage.
Quelque part c'est pas le langage le plus "performant" ?
Keith Flint 1969 - 2019
Il y a un detail en plus, que nous n'avons pas dit.
C'est que la plupart des entreprises ont deja du code d'operationnel (stable / fiable / et je l'espere reutilisable) et que ce serait une perte de temps de repartir a zero. Ce code est en C++.
Mais, il ne faut pas oublier que le C# fait la part belle dans les outils (editeur de niveau ... et autre) et quelques fois dans le scripting des jeux.
Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi
Ma page sur DVP
Mon Portfolio
Qui connaît l'erreur, connaît la solution.
Un point a été assez peu soulevé, il a été abordé mais sans plus :
Avez-vous besoin de performances monstres pour votre jeu ?
Prenez (cas extrême) des jeux comme Nethack, ou Dungeon Crawl, vous savez les "roguelike", ces RPG extraordinaires au graphismes simplistes (parfois élaborés avec de bonnes "tuiles") mais aux potentialités inégalées. Croyez-vous qu'un Nethack en C# ou en Python soit lent ? Non. Il sera très rapide même sur un vieux pentium 1.
L'arrivée de WebGL montre qu'un langage aussi haut niveau que Javascript peut produire des jeux 3D dans un navigateur web qui sont excellents. Certes les perfs sont certainement moins bonnes qu'un équivalent C++, mais dans dans certains cas la portabilité peut-être primordiale.
Voir par exemple le moteur Rage d'Id Software en WebGL :
C'est un super jeu mais malheureusement codé en Java. Même avec une très bonne machine ça rame...
D'ailleurs il faut absolument éviter de faire un jeu 3D avec le Java, le type structure il ne connait pas !!! Aller chercher l'adresse mémoire pour chaque vecteur je vous laisse imaginer... Notch devrait le faire en C#, on verra la différence.
pour info sur ma config (1920*1200) un peu plus de 1Go de ram d'utilisé et 60% du proc (Core Duo)
Le C++ comme le C# sont mal adaptés au multithreaded. La conception orientée objet, en général, pose problème au niveau de la parallèlisation. Il ne suffit pas de créer des threads pour qu'on programme aille plus vite; il faut leur donner des trucs a faire.
Pour ce genre d'opérations, il vaut mieux éviter l'objet et passer plutôt par du "bon vieux C" en quelques sortes; avoir des données et un programme qui traite ces données, est plus rapide qu'avoir un objet pour chaque instance de données.
Un langage fonctionnel est en fait ce qu'il y a de plus rapide (a partir d'un set de données en entrée, calcul une sortie). C'est possible en C++ et C# hein, mais tous les deux ne sont pas ce qu'il y a de mieux.
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