Discussion :

[screetch]

Je viens d'ailleurs de remarquer de l'explication sur Wikipedia est incorrecte, il peut y avoir un traitement et les réponses envoyées ne sont pas toujours les mêmes... Je corrigerais ça quand j'aurais le temps !

en fait je pense que la description de "stub" est bonne, c'est surtout mon utilisation qui était uncorrecte, c'est en fait un "trampoline", un code qui redirige vers un autre.
Un trampoline etait utilisé avant lorsque les saut ne permettait pas d'aller partout dans le code, insérer un trampoline permettait d'aller plus loin (d'ou le terme je pense)
dans le cas du JIT un trampoline est un code qui compile le code puis "saute" dessus

[Elendhil]

Elendhil si on part du principe que C# est 20/30% plus lent ton post n'a déjà sans doute pas de sens;
sur console on a le choix entre 2 framerate, 60 et 30. Si on atteint pas les 60 on est obligé de descendre a 30 ou a 15.
Si call of duty est a 60, les 20% vont sans doute les faire descendre a 30
si ils sont seulement a 30, les 20/30% peuvent les faire descendre a 15.
Enfin il y a quand meme une chance que ca marche hein
Et ca vient seulement d'une évaluation "au pif", donc c'est difficile de se faire une idée.

Oui tu as raison ce que j'ai écris n'a pas vraiment trop de sens ^^ .

Enfin bref de toute manière pour répondre à la question C# a quand même un bonne avenir dans le domaine car ce qui embauche le plus en ce moment c'est surement pas les studios qui développent les jeux AAA. Et avec le succès phénoménal de l'unity engine, les offres d'emplois vont continuer à fleurir.

Bon maintenant pour quelqu'un qui commence à programmer vaut mieux débuter par le C++ de toute manière. Cela va lui apporter plus de compétences, et une meilleur compréhension de la gestion de la mémoire ce qui est très important dans tous les langages.

[screetch]

oui a part pour les 1% de AAA le reste C# marchera aussi bien que C++

[LLB]

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

[screetch]

c'est très complet, merci pour les informations.
On est bien d'accord en général, mon avis diffère sur le coût de lancer le JIT une fois de temps en temps, et sur le fait que le coût est negligeable par rapport au code généré.
Et apparemment on est pas d'accord sur le cout en mémoire du runtime.

[supertonic]

je crois que c'est pas la peine d'insister là LLB, ya rien à faire

[rt15]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
            int sum = 0;
00000000  push        ebp 
00000001  mov         ebp,esp 
00000003  sub         esp,0Ch 
00000006  mov         dword ptr [ebp-4],ecx 
00000009  cmp         dword ptr ds:[0011313Ch],0 
00000010  je          00000017 
00000012  call        61BD63AB 
00000017  xor         edx,edx 
00000019  mov         dword ptr [ebp-0Ch],edx 
0000001c  xor         edx,edx 
0000001e  mov         dword ptr [ebp-8],edx 
00000021  xor         edx,edx 
00000023  mov         dword ptr [ebp-8],edx 
            for (int i = 0; i < 100; i++)
00000026  xor         edx,edx 
00000028  mov         dword ptr [ebp-0Ch],edx 
0000002b  nop 
0000002c  jmp         00000037 
                sum += i;
0000002e  mov         eax,dword ptr [ebp-0Ch] 
00000031  add         dword ptr [ebp-8],eax 
            for (int i = 0; i < 100; i++)
00000034  inc         dword ptr [ebp-0Ch] 
00000037  cmp         dword ptr [ebp-0Ch],64h 
0000003b  jl          0000002E 
            Console.WriteLine(sum);
0000003d  mov         ecx,dword ptr [ebp-8] 
00000040  call        5B41C340 
        }

C'est mieux à la main quand même.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
xor eax, eax
mov ecx, 63h
add eax, ecx
dec ecx
jnz -5h
push eax
push dword ptr ...
call printf
add esp, 8h

[supertonic]

Oui clairement on peut aussi dire que c++ ne permet pas les optimisations que l'ont peut faire en C et en assembleur ou alors me trompe-je ?

[oxyde356]

mon avis diffère sur le coût de lancer le JIT une fois de temps en temps, et sur le fait que le coût est negligeable par rapport au code généré.

Surtout dans le cas d'un jeu vidéo ...

Et apparemment on est pas d'accord sur le cout en mémoire du runtime.

+1

je crois que c'est pas la peine d'insister là LLB, ya rien à faire

Faut pas faire sa mijaurée, on peut être en désaccord, le débat fut très intéressant

Oui clairement on peut aussi dire que c++ ne permet pas les optimisations que l'ont peut faire en C et en assembleur ou alors me trompe-je ?

Théoriquement c'est possible mais il faudrait embarquer un cerveau humain avec le compilateur

[supertonic]

Merci pour le "mijaurée".
Si on veut pas comprendre qu'il est possible d'avoir un programme natif (sans aucune machine virtuelle ou je ne sais quoi d'autre en mémoire) en compilant totalement à l'avance un programme dotnet bon ben tant pis on va pas insister...

J'ai l'impression que coder en c++ rend pas très aimable en tout cas.

[dourouc05]

Oui clairement on peut aussi dire que c++ ne permet pas les optimisations que l'ont peut faire en C et en assembleur ou alors me trompe-je ?

On peut absolument faire les mêmes optimisations, on peut même déclarer des bouts de code en C ou en assembleur, histoire d'encore gagner un peu. Le C++ est prévu principalement pour les perfs tout en permettant l'OO, alors que l'OO permet déjà de perdre en perfs et en mémoire par rapport à du code C de base (on va créer plus d'objets, avec des getters/setters ; en C, on aura peut-être autant de structures, mais on va plus modifier barbarement les propriétés - même si un bon compilateur C++ va inliner ces méthodes, on ne perdra alors plus rien).

Quand on voit aussi le temps que prend le C++ à compiler, c'est surtout à cause des optimisations que le compilo fait (bon, pas uniquement, c'est déjà pas un langage qu'on parse facilement...). Si, en plus, tu fais beaucoup de travail d'optimisation à la main, tu peux aller encore plus loin. En cela, le C++ permet énormément d'optimisations par rapport au C# : on peut notamment aller en assembleur pour certaines routines, ce qui ne se fait pas de base en C# (AFAIK).

[screetch]

Merci pour le "mijaurée".
Si on veut pas comprendre qu'il est possible d'avoir un programme natif (sans aucune machine virtuelle ou je ne sais quoi d'autre en mémoire) en compilant totalement à l'avance un programme dotnet bon ben tant pis on va pas insister...

J'ai l'impression que coder en c++ rend pas très aimable en tout cas.

le RTTI est toujours en mémoire, quoi qu'il arrive, la description des classes/méthodes disponibles au runtime, et le code de Mono sera chargé lui aussi (il fait 2,5 a 4 megs chez moi), et je suis même pas certain que le bytecode soit pas chargé.
minimum 10% de ta mémoire sur consoles... shhhhhlllllurp

[LLB]

C'est mieux à la main quand même.

Je croyais avoir dit que je n'avais pas activé les optimisations. C'était en debug et je pouvais faire du pas à pas et voir chacune des variables (d'où les nop et le fait que ce soit similaire au code de base).

Si tu veux optimiser, tu peux même enlever la boucle et utiliser la formule de maths.

[supertonic]

Le fait qu'il existe monoTouch, qui génère du code natif statique pour iOS ne prouve t il pas qu'il n'y pas RTTI ou je ne sais quoi en sus du code natif, comme pour une application écrite en C++ ? (vu qu'apple n'accepte rien d'autre)

[screetch]

Le fait qu'il existe monoTouch, qui génère du code natif statique pour iOS ne prouve t il pas qu'il n'y pas RTTI ou je ne sais quoi en sus du code natif, comme pour une application écrite en C++ ? (vu qu'apple n'accepte rien d'autre)

le RTTI est différent, ca fait partie du langage C#.