Enfin thoériquement un langage qui produit du C en sorti aura dû mal à être plus rapide, si le compilateur a été capable d'écrire ce code, un programmeur sera capable de le faire.
Un langage de plus haut niveau que le C a un avantage énorme pour l'optimisation: le compilateur connaît plus de choses sur le "sens" des instructions que le compilateur de C. Par exemple, un compilateur de C a peu d'informations sur une boucle for quand le critère d'arrêt n'est pas une constante, et donc il lui est difficile de savoir comment dérouler la boucle de manière optimale. Un compilateur pour un langage de plus haut niveau pourrait avoir des informations supplémentaires sur la boucle, par exemple le fait qu'elle contient toujours un nombre pair d'itérations, etc. Dans ce cas, l'optimisation est souvent plus simple.
L'exemple que j'ai pris est un peu simpliste: on peut se dire que ce genre de cas peut aussi être géré en C par le développeur. Dans des cas plus compliqués, déléguer la tâche au compilateur est très appréciable. Comme les développeurs ont toujours une contrainte de temps, moins ils passent de temps à produire du code illisible mais optimisé et mieux c'est.
Pour prendre un autre exemple, les templates du C++ sont à la fois un outil qui aide à coder plus vite et un outil qui aide à optimiser. Si ça ne servait qu'à coder plus vite (au détriment de la vitesse d'exécution), l'intérêt serait beaucoup plus limité. Pourquoi est-ce que ça optimise aussi la vitesse d'exécution ? Parce que le traitement par le moteur de templates est effectué à la compilation, pas à l'exécution.
Quand le langage ne permet pas d'exprimer l'information nécessaire, le compilateur ne peut pas effectuer le travail pendant l'étape de compilation, et donc tu as le choix entre faire le travail toi même ou bien utiliser le langage pour faire le travail pendant l'exécution. Faire le travail soi même, c'est souvent long et compliqué, et faire le travail à l'exécution, ça implique souvent une perte de performance. Donc plus un langage donne d'informations au compilateur et plus il est à même de produire du code rapide si le compilateur est malin.
Dernier exemple, l'héritage: en C, tu ne peux pas exprimer l'héritage dans le langage, mais tu peux le simuler avec des pointeurs de fonctions et des casts bien placés. Par contre, le compilateur n'a aucune notion d'héritage, et donc l'héritage est forcément géré en partie pendant l'exécution. Ça veut dire que tu vas avoir des pointeurs de fonction dans tes objets, et que pour appeler une méthode d'objet, tu vas devoir accéder au pointeur de la fonction correspondante. Ça veut dire entre autres que tu ne peux pas inliner le code de ces méthodes. Ça implique une perte de performances.
Si le compilateur du langage L connaît l'héritage, alors il peut produire du code C qui évite dans la plupart des cas l'usage de pointeurs de fonctions pour simuler l'héritage, donc du code C qui sera plus facile à optimiser pour le compilateur C, et qui au final sera plus rapide. Faire la même chose pour le programmeur est théoriquement possible, mais en pratique irréalisable car trop long et trop compliqué.
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Yusei (Mastodon) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 3.
Un langage de plus haut niveau que le C a un avantage énorme pour l'optimisation: le compilateur connaît plus de choses sur le "sens" des instructions que le compilateur de C. Par exemple, un compilateur de C a peu d'informations sur une boucle for quand le critère d'arrêt n'est pas une constante, et donc il lui est difficile de savoir comment dérouler la boucle de manière optimale. Un compilateur pour un langage de plus haut niveau pourrait avoir des informations supplémentaires sur la boucle, par exemple le fait qu'elle contient toujours un nombre pair d'itérations, etc. Dans ce cas, l'optimisation est souvent plus simple.
L'exemple que j'ai pris est un peu simpliste: on peut se dire que ce genre de cas peut aussi être géré en C par le développeur. Dans des cas plus compliqués, déléguer la tâche au compilateur est très appréciable. Comme les développeurs ont toujours une contrainte de temps, moins ils passent de temps à produire du code illisible mais optimisé et mieux c'est.
Pour prendre un autre exemple, les templates du C++ sont à la fois un outil qui aide à coder plus vite et un outil qui aide à optimiser. Si ça ne servait qu'à coder plus vite (au détriment de la vitesse d'exécution), l'intérêt serait beaucoup plus limité. Pourquoi est-ce que ça optimise aussi la vitesse d'exécution ? Parce que le traitement par le moteur de templates est effectué à la compilation, pas à l'exécution.
Quand le langage ne permet pas d'exprimer l'information nécessaire, le compilateur ne peut pas effectuer le travail pendant l'étape de compilation, et donc tu as le choix entre faire le travail toi même ou bien utiliser le langage pour faire le travail pendant l'exécution. Faire le travail soi même, c'est souvent long et compliqué, et faire le travail à l'exécution, ça implique souvent une perte de performance. Donc plus un langage donne d'informations au compilateur et plus il est à même de produire du code rapide si le compilateur est malin.
Dernier exemple, l'héritage: en C, tu ne peux pas exprimer l'héritage dans le langage, mais tu peux le simuler avec des pointeurs de fonctions et des casts bien placés. Par contre, le compilateur n'a aucune notion d'héritage, et donc l'héritage est forcément géré en partie pendant l'exécution. Ça veut dire que tu vas avoir des pointeurs de fonction dans tes objets, et que pour appeler une méthode d'objet, tu vas devoir accéder au pointeur de la fonction correspondante. Ça veut dire entre autres que tu ne peux pas inliner le code de ces méthodes. Ça implique une perte de performances.
Si le compilateur du langage L connaît l'héritage, alors il peut produire du code C qui évite dans la plupart des cas l'usage de pointeurs de fonctions pour simuler l'héritage, donc du code C qui sera plus facile à optimiser pour le compilateur C, et qui au final sera plus rapide. Faire la même chose pour le programmeur est théoriquement possible, mais en pratique irréalisable car trop long et trop compliqué.