Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Quel avenir pour le C# dans les jeux vidéos ?
Pourra-t-il concurrencer le C++ dans un futur proche ?

Le , par SBHR_

259PARTAGES

5  0 
Les jeux vidéo sont aujourd'hui souvent développés à l'aide du langage C++.
Un indicateur fiable sont les offres d'emploi dans les studios de développement.

Pourtant, aujourd'hui, quelquefois, des connaissances en C# commencent à être demandées.
Cela reste rare.

J'ai posé directement la question suivante : "Hello. Do you think that C# will replace C++ in studios in a near future?"
à Stefan Boberg (directeur technique du Frosbite Engine chez EA DICE) et à Christopher Kline (directeur technique d'Irrational Games).

Voici leur réponse :
- Stefan Boberg : "Hi, no it will not replace C/C++ for AAA games at least. It may be used as a supplement though, for higher-level gameplay code."
- Christopher Kline : "not for AAA console titles. XBLA and other smaller games are already using it."

John Carmack (fondateur et directeur technique d'Id Software) a même écrit récemment :"if you are just starting, java or c# might be better than c++" et "all the snarky comments about shooting yourself in the foot with C and C++ are true. C# and java trade some perf for some safety."

Quel est votre avis sur le sujet?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de LLB
Membre expérimenté https://www.developpez.com
Le 26/05/2011 à 15:51
Citation Envoyé par oxyde356 Voir le message
mdr LLB tu pense bien que quand je parle d'un code morcelé je ne pense pas que ça va diviser en 2 un code à 5 lignes avec des fonctions built-in XD
Je ne sais pas comment t'expliquer mieux les choses. Si tu veux, je te donne un code plus complexe de 200 lignes, ça te suffira ? Et si je te donne un programme entier ?

Certes, je ne suis pas spécialiste des compilateurs JIT, mais pour avoir travaillé plusieurs années, dans plusieurs entreprises (dont Microsoft), sur plusieurs compilateurs (y compris générant du bytecode .NET), je pense avoir un peu de connaissance. Encore une fois, je réfute ta phrase "Après quelle soit faite pendant ou avant ça ne change rien à ce que j'ai dis, elle n'est pas totale !". Si, la compilation, une fois qu'elle est faite, est totale (même si je ne vois pas trop ce que tu veux dire par là).

Le JIT commence par allouer la mémoire spéciale au système. Un simple new/malloc ne suffit pas, car le système empêchera l'exécution du code. Il y a un appel système spécial pour obtenir de la mémoire en lecture / écriture et exécution. Certaines plateformes n'autorisent pas ça (certaines consoles par exemple), et c'est pour cela que l'on ne peut pas faire de JIT sur ces machines. C'est aussi ce qui explique que Havok Script, une implémentation optimisée de Lua pour les consoles, fait de l'interprétation de bytecode au lieu de JIT.

Quand le programme se lance, oui, le JIT prend du temps (parce qu'il compile des fonctions à l'avance). C'est vrai. C'est un problème pour certaines applications. Maintenant, je ne crois pas que le temps de chargement du jeu soit crucial.

Pendant l'exécution du programme, le JIT peut avoir des choses à faire. C'est vrai ; si on appelle le JIT au milieu de l'application, ce n'est pas optimal (et je suppose que ça fait du cache-miss). Mais ce coût n'est à payer qu'une seule fois, et ce coût est souvent négligeable à côté du code qui sera exécuté. Dans un jeu vidéo, c'est plus ou moins le même code qui est exécuté à chaque frame. Donc, le JIT qui n'est à payer qu'une seule fois ne devrait pas avoir d'impact sur le nombre de FPS (contrairement aux vérifications sur les accès aux tableaux ou strings).

Le JIT génère du code natif. C'est comme celui que génère un compilateur C++ (cf. mon exemple précédent). Une fois que le code est généré, il est copié dans la mémoire exécutable allouée au début. Pendant l'exécution, il n'y a pas des allers-retours à effectuer, non, il y a seulement le code natif à exécuter. Peu importe d'où il vient, c'est le même code. Quand il y a un appel de fonction, on ne doit pas demander au JIT où se trouve la fonction à appeler ; on fait bêtement l'appel (la commande "call" de x86) car l'adresse de la fonction est en dur dans le code exécutable (dans mon exemple précédent, il possède l'adresse de la fonction WriteLine).

Enfin, tu ne m'as peut-être pas cru lors de la phrase "ce coût est souvent négligeable à côté du code qui sera exécuté". Ca peut varier selon les applications, et c'est pour cela qu'il est possible de compiler le code à l'avance.

Je le redis : sous Windows, il existe ngen. ngen compile à l'avance tout le bytecode du programme, génère du code natif et le stocke avec l'application. À l'exécution, on n'a plus besoin du JIT, tout a été fait à l'avance. En pratique, on remarque deux choses : 1) le temps de démarrage est plus court ; 2) le temps d'exécution varie assez peu. Avec ngen, on peut gagner un peu de performance, mais parfois aussi, on en perd (parce que le JIT a des informations supplémentaires). Cela devrait aider à comprendre que les problèmes de performance de C# ne viennent pas tellement de la compilation JIT (dont on peut d'ailleurs se passer), mais plutôt du reste.

Sous Mono, il y a l'option --aot dont Screetch a parlé et qui n'est plus expérimentale. Cela génère du code natif sous forme de bibliothèque dynamique. C'est un fichier .so sous Linux, tu devrais même pouvoir le désassembler si tu le souhaites. L'équipe de Mono a aussi ajouté une option --aot=full qui garantit que le programme n'utilisera jamais le JIT à l'exécution. Cette option est particulièrement utile sur les plateformes interdisant le JIT (certaines consoles, et peut-être des téléphones portables).
10  0 
Avatar de
https://www.developpez.com
Le 24/05/2011 à 10:36
Citation Envoyé par cs_ntd Voir le message
Aaaah.


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?
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,

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.
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.
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.

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.
un peu hors sujet du coup puisque je ne critique pas le code généré

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.
cf mon post plus haut, un benchmark avantage les petits problèmes et les fonctions locales. Un benchmark ne sert a rien.
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...

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é.)
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.
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)
8  0 
Avatar de
https://www.developpez.com
Le 23/05/2011 à 19:29
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.
6  0 
Avatar de Camille_B
Membre confirmé https://www.developpez.com
Le 24/05/2011 à 12:04
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
7  1 
Avatar de LLB
Membre expérimenté https://www.developpez.com
Le 06/05/2011 à 3:12
Citation Envoyé par oxyde356 Voir le message
Et il faut arrêter de croire à des bêtises. Un programme écrit avec un langage interprété sera toujours moins rapide qu'un écrit avec un langage natif tout simplement parce que chaque opérations de base à une charge supplémentaire en interprété
.NET est compilé et c'est du code natif de la machine qui est exécuté au final (JIT), parler d'interprété n'a aucun rapport avec la discussion.

Donc je vois mal les studios de jeux vidéos refaire leurs outils et middleware en C# ça coûterait une fortune pour un résultat et une pertinence fort improbables.
C'est vrai. Mais les nouveaux outils peuvent être écrits en C#, c'est d'ailleurs ce qui se fait parfois (j'ai eu plusieurs offres d'emploi pour ça). En matière d'interface graphique et d'outils, C# offre bien des avantages. Pour le cœur des jeux AAA, C# n'est pas d'actualité (parmi les problèmes, il y a le garage collector, peu adapté aux contraintes temps-réel des jeux les plus ambitieux).

Alors certes, il y a Mono (grand projet). Qui supporte jusqu'à .NET 2.0 je crois.
Mono n'est plus aussi en retard que certains voudraient le faire croire (en général, les gens répètent ce qu'ils ont entendu et c'est vrai que Mono était loin derrière il y a 5 ans). Mono supporte .NET 4.0, et il était même possible d'utiliser en partie C# 4.0 sous Mono avant que la version Microsoft ne soit publiée. Mono offre d'ailleurs des avantages et fonctionnalités qui ne sont pas sur la version Microsoft de .NET (par exemple, le shell interactif pour C#).

Standardisé, peut être. Ouvert, non.
C'est standardisé et il existe au moins une implémentation libre (tu peux même écrire la tienne, si tu as du temps à perdre). Que veux-tu de plus ? Microsoft a, à plusieurs reprises, aidé Mono (par exemple en leur donnant des fichiers de tests). Microsoft s'assure aussi que certains de ses produits tournent sur Mono. Prends F#, la compatibilité Mono est testée régulièrement et prise très au sérieux (Microsoft a même financé l'implémentation de plugins pour Monodevelop).

Et en aucun cas, il est dit que Microsoft fournis la spécification de la Machine virtuelle, par exemple.
Les spécifications de .NET sont disponibles depuis longtemps. Par exemple, pour la CLI, c'est ici. Tu trouveras les autres facilement (C#, etc.).

Mais qu'en est il de DirectX (ou XNA) pour Mono ? Car y a toujours pas de DirectX sous Mac ou GNU/Linux.
DirectX ne fait pas partie de .NET et Mono n'a pas vocation à l'implémenter. Mais cette question n'a rien à voir avec C# (en C++ non plus, tu n'as pas DirectX sous Mac).
5  0 
Avatar de
https://www.developpez.com
Le 26/05/2011 à 11:36
la plupart des développeurs utilisent DirectX et sont donc "entre les mains" de microsoft déjà, dans un sens
mais microsoft fait le maximum pour que DirectX soit le plus efficace possible pour les jeux vidéos, car tout le monde s'y retrouve;
microsoft vend plus de windows pour les jeux vidéo
les développeurs de jeux vidéo font de "meilleurs" (i.e. plus beaux) jeux
les cartes graphiques se vendent mieux

au final en collaborant tout le monde y gagne

ce serait pareil en C#; si microsoft venait a virer de bord et perdait les développeurs (de jeux ou d'autre chose) "son" langage tomberait en désuetude

l'inverse, c'est OpenGL, géré par un consortium qui se chamaille en permanence, et ca a donné OpenGL 3 qui n'était adapté a personne, et OpenGL ne perce toujours pas dans les jeux AAA, sauf sur quelques moteurs qui veulent tourner sur Mac. Quelque fois, un dictateur bien eclairé aide beaucoup au développement rapide
5  0 
Avatar de oxyde356
Membre éprouvé https://www.developpez.com
Le 05/05/2011 à 10:16
Citation Envoyé par iliak Voir le message
Niveau performances, le .Net n'a pas à rougir comparé à du C/C++, bien au contraire ! Il faut abandonner l'idée que de l'interprété sera toujours plus lent que du binaire (cf toujours wikipedia)
Et il faut arrêter de croire à des bêtises. Un programme écrit avec un langage interprété sera toujours moins rapide qu'un écrit avec un langage natif tout simplement parce que chaque opérations de base à une charge supplémentaire en interprété, c'est logique et toutes les optimisations qui existent et qui existeront ne serviront qu'à se rapprocher des performances des langages natifs mais ne pourront pas les atteindre.
C'est et ça sera toujours plus lent que du binaire, théoriquement, et concrètement, il suffit de faire quelques benchmark, par contre attention plein de fanboy des langages interprétés en font avec du langage natif mal écris et du coup forcément le résultat est totalement biaisé. Pour être sûr autant faire le benchmark soit même ou sinon être sûr de l'impartialité et de la compétence de l'auteur du benchmark.

Il ne faut pas s'offusquer du fait que les langages interprétés soient plus lent, ils ont leurs avantages et leur inconvénients, leur inconvénient majeur est d'être à peu près 4x plus lent qu'un langage natif comme le C++ (bien sûr tout dépend des opérations effectuées mais ils vaut mieux prendre le pire cas), mais la productivité, la portabilité est meilleur. Si les applications temps réel et semi temps-réel sont toujours écris en langage natif ce n'est pas qu'une question d'héritage du temps.

P.S. : le seul passage soulignant de meilleurs performances nécessite une référence, je serais tenté de lui donner un lien sur le site de Microsoft
6  3 
Avatar de LLB
Membre expérimenté https://www.developpez.com
Le 06/05/2011 à 23:07
Citation Envoyé par bafman Voir le message
la lenteur peut venir de pleins de truc :
- les verification au runtime des limites des tableaux
- le garbage collector
- les 18 niveau d'heritage qui font que la construction du moindre objet appel autant de constructeurs
- les autoboxing caché à pleins d'endroits
- le moindre appel de fonction est virtuel et fait dont un lookup dans la metaclass
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.

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 :
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#.

je croit qu'il existe une implementation de SIMD sous mono, mais je ne sais pas ce que ça donne au niveau performance
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).

donc encore une grosse place pour l'interpréteur
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.
3  0 
Avatar de Louhike
Membre habitué https://www.developpez.com
Le 24/05/2011 à 16:03
Citation Envoyé par supertonic Voir le message
[...]je sais pas ce qu'est un stub alors pardonnez-moi. [...]
Un stub est appelé "bouchon" en français. C'est un petit programme qui simule le traitement d'un programme conséquent. Il envoie des réponses codées en dur ou fait une interprétation partielle des informations qu'il reçoit. Ils sont plus ou moins complexes selon les besoins.
http://fr.wikipedia.org/wiki/Bouchon_(informatique)
En espérant que mon explication n'est pas trop confuse.
3  0 
Avatar de oxyde356
Membre éprouvé https://www.developpez.com
Le 25/05/2011 à 13:16
Citation Envoyé par gouessej Voir le message
Désolé de te contredire mais des chercheurs d'IBM dans le domaine du calcul haute performance ne sont pas de ton avis (ils invoquent le fait que pas mal d'optimisations possibles avec une machine virtuelle à l'exécution sont inenvisageables dans un langage compilé) ...
Il serait très intéressant pour tout le monde que tu partage plus amplement tes sources. Car même si je suis en partie d'accord sur la théorie (qui repose quand même en bonne partie sur de la prédiction ...) il n'y a toujours pas de chiffres, rien de concret. Peut-être pourrais tu étayer tes propos de cette façon.
Citation Envoyé par gouessej Voir le message
ainsi que les créateurs de Jake 2 (clone de Quake 2 en Java). D'où sors-tu que les programmes interprétés sont 4 fois plus lents que leurs équivalents natifs? Jake 2 est pourtant 15% plus rapide que Quake 2, voilà au moins un excellent contre-exemple et ce n'est pas le seul.
Wow en effet se permettre de comparer 2 codes qui ont 10 ans d'écart c'est vrai que c'est le summum de l'objectivité, ça c'est un excellent contre-exemple je suis scié, sachant que le deuxième s'inspire plus que largement du premier en plus :o Bon après c'est pas mal ça montre bien les 10 ans de retard dans le domaine ça c'est clair.

Citation Envoyé par gouessej Voir le message
Quant aux benchmarks, j'en connais aussi qui sont biaisés dans l'autre sens, quand le gars rajoute un appel à Thread.sleep() alors que cela casse la synchronisation tout ça pour faire comme dans son code C alors que sans cet appel, le résultat est très différent...
Oui bien sûr qu'il y en à des biaisés dans l'autre sens c'est pourquoi partant de la constatation que les tests sont très souvent foireux il faut vraiment les scruter attentivement, et les mieux faits montrent clairement de quel côté sont les performances.

Citation Envoyé par gouessej Voir le message
Je te conseille de ne pas dénigrer celles et ceux qui ne sont pas d'accord avec toi.
Je ne dénigre en rien les personnes qui sont en désaccord avec moi je dénigre leurs arguments, il me semble que c'est mon droit.

Citation Envoyé par gouessej Voir le message
Ton JIT ne vas pas compiler à la volée ton code pour au final en faire un bloc unique d'instructions il ne va compiler que petits morceaux par petits morceaux pseudo-indépendants et c'est pas du code en langage natif qui va faire le lien entre tout ça !
6  3