• AgoraVox sur Twitter
  • RSS
  • Agoravox TV
  • Agoravox Mobile


En réponse à :

Marc Bruxman 29 novembre 2008 01:41

							

															
							
								Merci mais je sais exactement ce qu’est une machine virtuelle pour en avoir déjà codée moi même.
Machine virtuelle = interprété.

Bizarrement pourtant tout le monde fait cette différence dans l’industrie. 
Que vous ayez codé une machine virtuelle soit. C’est un exo classique en école d’ingénieur. Je crois même savoir d’ou vous venez à lire votre post. Donc vous avez codé votre "corewar" ou un projet similaire destiné à vous montrer comment on peut faire une machine virtuelle. C’est bien. Mais avoir fait un projet scolaire quelle que soit votre note à ce projet ne vous donne pas la connaissance du fonctionnement d’une VM dans l’industrie. Ce projet a un but pédagogique, mais techniquement il est à des années lumiéres d’une VM comme celle de Java. 

Le fait qu’on économise ou pas la phase de tokenisation à partir d’un langage source ne change rien à l’affaire, c’est de toute façon plus lent.

Y’a pas que la tokenisation que vous économisez ! Je vous ai parlé de parsing et comme beaucoup d’étudiants vous confondez allégrement l’analyse syntaxique et l’analyse lexicale. 

Par ailleurs, vous négligez que la phase de compilation et/ou d’interprétation du langage ne correspond pas seulement à une traduction vers le langage machine mais comprend une phase d’optimisation. Et que si certaines optimisations peuvent se faire de façon statique (ce qui sied à du code compilé), d’autres ne peuvent se faire que dynamiquement (à l’exécution). Et c’est pour cela qu’il existe des cas ou votre compilo JIT mais une raclée à votre code en C++ pourtant correct du point de vue de l’écriture. Ce qui veut dire que non un code JIT peut être plus rapide qu’un code C++ (cf les liens Wikipedia que je vous ai donné plus haut) et que toutes les études universitaires l’ont prouvées. Et qu’en moyenne la différence de vitesse ne sera pas énorme. 

l’utilisation d’un compilo JIT n’est pas aussi performante qu’une "compile statique" ou l’ont peut faire varier les options de compilation à volonté.

Vous pouvez aussi faire varier les options de votre VM et je vous encourage d’ailleurs vivement à le faire si vous voulez des perfos. Parce que forcément si vous utilisez la VM Sun de base sans la tuner, oui ce n’est probablement pas gagné. (C’est un peu comme laisser le -g et oublier les -O quand vous compilez avec gcc hein !). 

A cela il faut evidemment rajouter le temps de compilation temps réel (qui est loin d’être négligeable).

Oui ce surcoût existe je ne le nie pas et il est en grande partie compensé par les optimisations dynamiques du JIT que vous semblez ne pas connaitre. Vous semblez ne pas encore maitriser correctement la différence entre les aspects dynamiques et statiques d’un langage de programmation. Si vous venez bien de l’école que je pense, et que vous êtes en premiére année ce n’est pas très grave, vous avez tout le temps d’apprendre. Je ne peux que vous suggérer de regarder :
  • Le mécanisme des templates en C++ et leur utilisation pour faire de la métaprogrammation. (Allez voir le labo de l’école d’en face, ils pourront vous montrer ce qu’ils font avec). Je ne parles pas ici de la simple utilisation des templates pour faire de la généricité mais bel et bien de leur utilisation pour faire de la métaprog’. Enfin bon au passage posez vous les questions sur la différence entre l’approche statique (template) de la généricité et l’approche dynamique (on dérive tout de java.lang.object) de la généricité. Cela vous ouvrira des pistes de réflexion intéréssantes. 
  • Des langages vraiment dynamiques comme le Ruby (pour le coup effectivements assez lent). Regardez les mécanismes d’introspection et demandez vous comment vous auriez codé l’équivalent en C++. 
Maintenant il se peut que vous ne voyez pas la différence dans vos applis pour la simple et bonne raison que 90% du temps d’exécution d’une application classique se passe en communication avec l’OS et les autres ressources. Mais en temps d’execution machine, un programme compilé qui ne fait que manipuler la mémoire est evidemment infiniment plus rapide (et ce n’est pas négociable).

Vous paraissez bien sur de vous. Cela ne sera pas un mal pour votre future vie professionelle (il faut savoir être convainquant) mais vous gagneriez à ne pas avoir de religion en matière de technologie. A ce que je comprend de votre formation (vous êtes en Epitech 1 ou 2 non ?) votre erreur n’est pas extrémement grave et elle est très courante à ce stade de votre formation. Ne vous enfermez pas la dedans. Aussi étrange que cela paraisse, on sait maintenant faire de bons JIT et de bons garbage collector.

Ainsi, raconter que java est instrinsèquement presque aussi rapide que du compilé natif sous prétexte que ça se voit pas sur des OS chronovore à la windows, c’est que vous n’avez pas bien compris à quoi sert un compilo (allez dire ça aux gars de l’embarqué ils vous riront au nez).

Il y a d’autres raisons pour lesquelles on n’utilise pas ce genre de langages dans l’embarqué ou plus exactement pour les applications temps réel (parce que beaucoup de téléphones portables utilisent java et donc que votre remarque est fausse. Il y a également des cartes à puces et divers autres gadgets). Si vous voulez la vrai raison pour laquelle Java n’est pas utilisée dans l’informatique temps réelle, je vous suggére ce lien :
http://en.wikipedia.org/wiki/Real_time_Java

Ah oui et puis quand même un dernier petit lien pour la forme :
http://www.ece.arizona.edu/ embedded/Research/JITFPGA
(Ca parle de JIT mais pas de Java et je suis sur que cela pourra attirer votre attention). 

Répondre Signaler un abus Lien permanent

Ajouter une réaction

Pour réagir, identifiez-vous avec votre login / mot de passe, en haut à droite de cette page

Si vous n'avez pas de login / mot de passe, vous devez vous inscrire ici.


FAIRE UN DON


Palmarès