Bon je savais pas où poser ma question dans tout ce troll mais je me lance ici. Sachant que je ne suis pas familier des mécanismes des VM type java/mono et que mon travail concerne l'informatique robuste à bas niveau donc très loin des .net & co et proche des descriptions HDL et de l'assembleur (ce qui va influencer à fond la question qui suivra)
Sachant qu'aujourd'hui on s'oriente vers des architectures matérielles extrèmement complexes, le risque d'accumuler des erreurs transitoires lors du fonctionnement n'est plus négligeable, bien qu'on dispose de méthode pour abaisser ce risque et bien qu'on ne soit pas en environnement hostile.
si je fais un a = 5; en C qui sera traduit par le compilo en "li Rd, 5" (attention pseudo asm pour illustrer l'idée), l'opération est effectuée en un cycle. La probabilité qu'une erreur se produise pendant cette opération est donc faible.
si je fais un a = 5; en C# qui sera traduit en bytecode qui sera exécuté sur une VM qui va charger le 5 dans un "registre virtuel" de la machine virtuelle, qui va faire intervenir tout plein d'étapes supplémentaires pour finalement finir en mémoire car le fonctionnement de la machine implique un nombre d'aller-retours cache <-> registres plus nombreux que si on était en code natif.
Là l'opération prend beaucoup plus de cycles pour s'exécuter, et même si la différence de performance semble négligeable à l'échelle humaine, j'y vois surtout un risque d'erreur largement multiplié pouvant ne pas faire aboutir la simple opération a = 5, ou pire rendre l'exécution du programme dangereuse.
Alors n'y a t'il pas un risque d'avoir plus d'erreurs incontrôlables/indétectables à ajouter une énième couche d'abstraction, surtout aussi éloignée, pour l'exécution d'un programme ?
Si c'est pour l'aspect pédagogique de .net, éventuellement, je comprend qu'on puisse le défendre si ça permet à des gens d'apprendre à coder.
Mais, quand c'est pour faire des logiciels qui seront utilisés, parfois des applis critiques, à cause d'un simili-lobby d'ingénieurs qui veulent du "modernisme" là je trouve qu'il y a un soucis. Plus on s'éloigne du bas niveau, plus on augmente le risque d'erreur, risque d'erreur qui continue d'augmenter par le simple fait des évolutions techniques du matériel. Donc une croissance exponentielle du risque d'erreur.
[^] # Re: Techniquement, pourquoi Mono
Posté par Badeu . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
Sachant qu'aujourd'hui on s'oriente vers des architectures matérielles extrèmement complexes, le risque d'accumuler des erreurs transitoires lors du fonctionnement n'est plus négligeable, bien qu'on dispose de méthode pour abaisser ce risque et bien qu'on ne soit pas en environnement hostile.
si je fais un a = 5; en C qui sera traduit par le compilo en "li Rd, 5" (attention pseudo asm pour illustrer l'idée), l'opération est effectuée en un cycle. La probabilité qu'une erreur se produise pendant cette opération est donc faible.
si je fais un a = 5; en C# qui sera traduit en bytecode qui sera exécuté sur une VM qui va charger le 5 dans un "registre virtuel" de la machine virtuelle, qui va faire intervenir tout plein d'étapes supplémentaires pour finalement finir en mémoire car le fonctionnement de la machine implique un nombre d'aller-retours cache <-> registres plus nombreux que si on était en code natif.
Là l'opération prend beaucoup plus de cycles pour s'exécuter, et même si la différence de performance semble négligeable à l'échelle humaine, j'y vois surtout un risque d'erreur largement multiplié pouvant ne pas faire aboutir la simple opération a = 5, ou pire rendre l'exécution du programme dangereuse.
Alors n'y a t'il pas un risque d'avoir plus d'erreurs incontrôlables/indétectables à ajouter une énième couche d'abstraction, surtout aussi éloignée, pour l'exécution d'un programme ?
Si c'est pour l'aspect pédagogique de .net, éventuellement, je comprend qu'on puisse le défendre si ça permet à des gens d'apprendre à coder.
Mais, quand c'est pour faire des logiciels qui seront utilisés, parfois des applis critiques, à cause d'un simili-lobby d'ingénieurs qui veulent du "modernisme" là je trouve qu'il y a un soucis. Plus on s'éloigne du bas niveau, plus on augmente le risque d'erreur, risque d'erreur qui continue d'augmenter par le simple fait des évolutions techniques du matériel. Donc une croissance exponentielle du risque d'erreur.