Plus tu ajoute d'étape (et de couches) moins la solution me semble pertinente, du point de vu performance comme de la maintenabilité.
Ce qui coûte en performance, ce n'est pas le fait d'ajouter de "couche", mais d'ajouter des services : GC, contrôle d'accès aux ressources, etc.
Grosso modo la VM .Net émule une CPU pourquoi garder cette émulation si elle peut être évitée ?
Il n'y a aucune forme d'émulation. la VM .NET est prévue dès le départ pour exposer un bytecode destiné à être compilé en code natif avant exécution, voir même avant déploiement.
Je présume que .Net est comme JVM est qu'elle est restée compatible (même modèle d'exécution) depuis la première version jusqu'à
Non elle a évoluée. Le CLR en est à la version 4.0.
La bibliothèque standard et le ramasse miette ne font pas partie de la VM.
Un sous-ensemble de la bibliothèque fait implicitement parti de la VM, et le GC est un service de la VM et en fait donc pleinement parti.
Ce que tu ne comprends pas, c'est ce qu'apporte une VM :
* une couche d'abstraction complète => portabilité. Pour un OS, c'est un gros atout.
* un modèle mémoire indépendant du hardware => possibilité d'ajouter des mécanismes de protection purement software, portable au passage, qui ne nécessite pas de faire appel aux ring hardware pour isoler les processus : paradoxalement il en résulte des performances bien meilleures qu'avec un OS classique basée suér les ring hardwares.
* un bytecode vérifiable avant exécution : pour un OS, pouvoir vérifier un programme avant de l'exécuter est un énorme atout niveau fiabilité et sécurité.
Il en résulte un OS beaucoup plus indépendant de la machine, avec un code beaucoup plus portable, plus simple, plus fiable et plus facile à maintenir.
[^] # Re: Les développeurs Java
Posté par TImaniac (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 4.
Ce qui coûte en performance, ce n'est pas le fait d'ajouter de "couche", mais d'ajouter des services : GC, contrôle d'accès aux ressources, etc.
Il n'y a aucune forme d'émulation. la VM .NET est prévue dès le départ pour exposer un bytecode destiné à être compilé en code natif avant exécution, voir même avant déploiement.
Non elle a évoluée. Le CLR en est à la version 4.0.
Un sous-ensemble de la bibliothèque fait implicitement parti de la VM, et le GC est un service de la VM et en fait donc pleinement parti.
Ce que tu ne comprends pas, c'est ce qu'apporte une VM :
* une couche d'abstraction complète => portabilité. Pour un OS, c'est un gros atout.
* un modèle mémoire indépendant du hardware => possibilité d'ajouter des mécanismes de protection purement software, portable au passage, qui ne nécessite pas de faire appel aux ring hardware pour isoler les processus : paradoxalement il en résulte des performances bien meilleures qu'avec un OS classique basée suér les ring hardwares.
* un bytecode vérifiable avant exécution : pour un OS, pouvoir vérifier un programme avant de l'exécuter est un énorme atout niveau fiabilité et sécurité.
Il en résulte un OS beaucoup plus indépendant de la machine, avec un code beaucoup plus portable, plus simple, plus fiable et plus facile à maintenir.