Sachant qu'une VM n'est qu'une abstraction et que le bytecode peut être pré-compilé en code natif avant exécution (sans JIT donc), ca fou pas un peu en l'air tout ton raisonnement ? Sachant qu'on peut faire un processeur qui exécute directement du bytecode sans passer par une couche intermédiaire, l'avantage apparent du code natif ne peut-il pas être contourné ?
Si on sort du champs d'action de la VM, tout a fait que ça fout mon raisonnement en l'air, vu qu'il repose sur l'utilisation d'une VM.
Quel est le plus probable ? Un problème d'entrée/sortie disque ou un problème bas niveau au moment de l'exécution par le processeur ?
Sachant qu'on peut faire un processeur qui exécute directement du bytecode sans passer par une couche intermédiaire, l'avantage apparent du code natif ne peut-il pas être contourné ?
cf. réponse à pbpg sur les erreurs liées à l'OS
Quel est le plus probable : un bug dans l'application où dans le processus d'exécution sous-jacent ?
Partant de là, faut-il mieux fournir un environnement d'exécution sécurisé quitte à ajouter une couche supplémentaire ou faire du natif pour limiter les risques liées à l'exécution des instructions ?
On pourrait parler d'équi-probabilité même si expérimentalement cela ne serait pas démontré. Le meilleur remède aux erreurs de ce type, qui trouvent leur origine dans des causes extérieures au programme exécuté, reste d'essayer de faire des programmes les plus performant possible en notion de nombre d'instructions exécutées. Et donc d'éviter les VM.
Au final, je parlais de ça car avec les process de fabrication et la densité des portes qu'on trouve dans les puces aujourd'hui et les évolutions en cours, il n'est pas impossible que ce type d'erreur deviennent un futur casse-tête, même pour quelqu'un qui fait du développement d'application desktop.
[^] # Re: Techniquement, pourquoi Mono
Posté par Badeu . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
Sachant qu'on peut faire un processeur qui exécute directement du bytecode sans passer par une couche intermédiaire, l'avantage apparent du code natif ne peut-il pas être contourné ?
Si on sort du champs d'action de la VM, tout a fait que ça fout mon raisonnement en l'air, vu qu'il repose sur l'utilisation d'une VM.
Quel est le plus probable ? Un problème d'entrée/sortie disque ou un problème bas niveau au moment de l'exécution par le processeur ?
Sachant qu'on peut faire un processeur qui exécute directement du bytecode sans passer par une couche intermédiaire, l'avantage apparent du code natif ne peut-il pas être contourné ?
cf. réponse à pbpg sur les erreurs liées à l'OS
Quel est le plus probable : un bug dans l'application où dans le processus d'exécution sous-jacent ?
Partant de là, faut-il mieux fournir un environnement d'exécution sécurisé quitte à ajouter une couche supplémentaire ou faire du natif pour limiter les risques liées à l'exécution des instructions ?
On pourrait parler d'équi-probabilité même si expérimentalement cela ne serait pas démontré. Le meilleur remède aux erreurs de ce type, qui trouvent leur origine dans des causes extérieures au programme exécuté, reste d'essayer de faire des programmes les plus performant possible en notion de nombre d'instructions exécutées. Et donc d'éviter les VM.
Au final, je parlais de ça car avec les process de fabrication et la densité des portes qu'on trouve dans les puces aujourd'hui et les évolutions en cours, il n'est pas impossible que ce type d'erreur deviennent un futur casse-tête, même pour quelqu'un qui fait du développement d'application desktop.