Ce qu'on fait les gens de Self que j'ai déjà cité précedemment, au tout début des années 90, c'est d'utiliser des techniques d'inlining agressif des méthodes appelées, combinées à du JIT. Du code natif inliné est plus performant qu'un appel direct.
Après, ça ne vient pas gratuitement, il faut tout un mécanisme d'instrumentation pour repérer les méthodes à inliner, le JIT a aussi un coût, etc. Je ne prétends pas que c'est plus rapide dans tous les cas, mais qu'on peut obtenir des performances équivalentes dans le cas général. Par ailleurs, ces optimisations dynamique sont souvent plus efficaces en pratique que les optimisations statiques faites par les compilateurs, puisqu'il y a beaucoup de cas où un raisonnement statique n'est pas possible mais où l'instrumentation donne des prédictions extrêmement précises. Cf. par exemple cet article sur le C++, qui s'inspire du travail fait sur Self : "Reducing Indirect Function Call Overhead In C++ Programs", Brad Calder and Dirk Grunwald, 1994.
Par ailleurs, je crois que tu te fourvoies sur le sens du mot "système" dans "programmation système". Dans la bouche des créateurs de Go, je pense qu'il ne s'agit pas d'écrire le gestionnaire de mémoire d'un noyau d'OS, mais plutôt de toute la partie "userland non graphique" qui se trouve au dessus du noyau. Et qui a plus besoin d'outils fiables qui permettent de programmer de larges systèmes que d'une élimination prédictible des appels indirects.
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par gasche . En réponse à la dépêche Quelques nouvelles rapides du langage Go. Évalué à 4.
Ce qu'on fait les gens de Self que j'ai déjà cité précedemment, au tout début des années 90, c'est d'utiliser des techniques d'inlining agressif des méthodes appelées, combinées à du JIT. Du code natif inliné est plus performant qu'un appel direct.
Après, ça ne vient pas gratuitement, il faut tout un mécanisme d'instrumentation pour repérer les méthodes à inliner, le JIT a aussi un coût, etc. Je ne prétends pas que c'est plus rapide dans tous les cas, mais qu'on peut obtenir des performances équivalentes dans le cas général. Par ailleurs, ces optimisations dynamique sont souvent plus efficaces en pratique que les optimisations statiques faites par les compilateurs, puisqu'il y a beaucoup de cas où un raisonnement statique n'est pas possible mais où l'instrumentation donne des prédictions extrêmement précises. Cf. par exemple cet article sur le C++, qui s'inspire du travail fait sur Self : "Reducing Indirect Function Call Overhead In C++ Programs", Brad Calder and Dirk Grunwald, 1994.
Par ailleurs, je crois que tu te fourvoies sur le sens du mot "système" dans "programmation système". Dans la bouche des créateurs de Go, je pense qu'il ne s'agit pas d'écrire le gestionnaire de mémoire d'un noyau d'OS, mais plutôt de toute la partie "userland non graphique" qui se trouve au dessus du noyau. Et qui a plus besoin d'outils fiables qui permettent de programmer de larges systèmes que d'une élimination prédictible des appels indirects.