Comment le code natif peut être plus lent que le code bytecode ?
tu lis où tu reposes la question pour le fun ?
J'ai tenté d'expliquer qu'il y a des différences liées aux nombre d'I/O au démarrage.
J'ai jamais dis qu'en cours d'exécution le code natif était plus lent.
(ce qui est faux en passant, difficile de faire plus compact que du x86)
J'adore tes affirmations gratuites théoriques qui ne se vérifient pas en pratique.
Tu peux concevoir qu'une instruction écrite dans un bytecode de plus haut niveau corresponde à un paquet d'instructions en code machine ?
Pour moi, la VM a un dilemme entre travailler le code pour le rendre ensuite plus rapide et l'interpréter au plus vite pour ne pas avoir une trop grosse latence.
Ca c'est le dilemme des VM Java effectivement.
Le bytecode .NET a été conçu dès le départ pour être compilé en code natif. C'est une différence fondamentale qui fait que .NET ou Mono n'interprête jamais le bytecode .NET (mono a un interprêteur pour d'autres raisons) alors que la VM HotSpot pour Java travaille comme tu l'indiques.
Dans tous les cas, ca ne change rien à ce que je disais au départ : même s'il y a un léger écart au niveau perf, il est la plupart du temps minime.
C'est donc pas la présence d'un compilateur JIT qui fait qu'un programme écrit en C# ou Java est plus lent qu'un programme écrit en C.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
tu lis où tu reposes la question pour le fun ?
J'ai tenté d'expliquer qu'il y a des différences liées aux nombre d'I/O au démarrage.
J'ai jamais dis qu'en cours d'exécution le code natif était plus lent.
(ce qui est faux en passant, difficile de faire plus compact que du x86)
J'adore tes affirmations gratuites théoriques qui ne se vérifient pas en pratique.
Tu peux concevoir qu'une instruction écrite dans un bytecode de plus haut niveau corresponde à un paquet d'instructions en code machine ?
Pour moi, la VM a un dilemme entre travailler le code pour le rendre ensuite plus rapide et l'interpréter au plus vite pour ne pas avoir une trop grosse latence.
Ca c'est le dilemme des VM Java effectivement.
Le bytecode .NET a été conçu dès le départ pour être compilé en code natif. C'est une différence fondamentale qui fait que .NET ou Mono n'interprête jamais le bytecode .NET (mono a un interprêteur pour d'autres raisons) alors que la VM HotSpot pour Java travaille comme tu l'indiques.
Dans tous les cas, ca ne change rien à ce que je disais au départ : même s'il y a un léger écart au niveau perf, il est la plupart du temps minime.
C'est donc pas la présence d'un compilateur JIT qui fait qu'un programme écrit en C# ou Java est plus lent qu'un programme écrit en C.