Les instructions simples sont-elles plus rapides?

Question

Cette question est purement par curiosité et je suis sûr que la réponse dépend du compilateur. Ceci est également une micro-optimisation extrême qui conduira presque certainement à un code non-supportable. Le CPU doit évidemment effectuer chaque calcul et le stocker quelque part, donc peut-être que c'est fonctionnellement le même. Avec tout cela de côté, je me demandais si l'utilisation de moins de variables conduirait intrinsèquement à un code d'exécution plus rapide. Par exemple, il serait bon de laisser les résultats dans les registres pour de longs calculs. Bien sûr, si vous avez besoin du même résultat plus d'une fois, ce n'est pas utile.

Par exemple ce code:

var result = GetNumber(); 
var adjusted1 = result + 10; 
var adjusted2 = adjusted1/2; 
var final = GetFinal(adjusted2); 

peut être transformé en ce qui suit:

var final = GetFinal((GetNumber() + 10)/2); 

En général serait la sortie du compilateur de quelque chose comme ça, une seule ligne sans variables, toujours identiques à travers les langues? Si la déclaration ci-dessus impliquait des centaines de calculs serait-ce la même chose?

Answer 1

La question est vraiment spécifique au compilateur, pas spécifique à la langue. Et puisque n'importe quelle langue peut avoir un nombre quelconque de compilateurs, dont certains ne sont pas encore écrits, il est impossible de fournir une réponse générale.

La plupart des compilateurs suppriment automatiquement les variables temporaires locales inutiles, si possible. Évidemment, la valeur doit être stockée quelque part en passant, mais il peut ne pas être nécessaire de la stocker dans la mémoire principale à moins qu'elle ne soit mentionnée plus tard dans le programme, et même alors, elle peut toujours être disponible dans un registre. Cette optimisation est relativement simple, donc je m'attends à ce que cela soit fait par n'importe quel compilateur qui effectue une optimisation.

Même si un compilateur n'optimise pas ici, le matériel peut aider en faisant le stockage en parallèle. Même si le compilateur écrit et lit immédiatement la valeur de la mémoire principale, le processeur va probablement l'extraire du cache, ce qui ne sera que légèrement plus lent qu'un accès au registre. Il y a des langages dans lesquels cette optimisation serait interdite parce que les variables sont sacrées, ou plus simplement parce que la sémantique du langage permet l'introspection ou l'interprétation de l'exécution (par exemple, en utilisant une fonction intégrée eval). Dans ce cas, la variable doit exister même si elle n'est pas visiblement référencée, car une utilisation de l'introspection ou de l'évaluation dynamique pourrait y faire référence. Cela signifie également que la création de variables est une opération non triviale, puisqu'elle signifie les stocker avec leurs noms dans une sorte de structure de données persistante. Cependant: les langages de ce type sont rarement compilés, donc l'ensemble du programme souffre probablement de frais généraux d'interprétation beaucoup plus importants que le coût d'une variable supplémentaire. Dans l'ensemble, vous devez écrire les programmes de manière à les rendre plus faciles à comprendre. Cela vous aidera à éviter les bugs, à aider les autres à comprendre votre code, et même à aider un compilateur à trouver la meilleure optimisation. Il n'est presque jamais utile de faire des efforts cérébraux pour s'inquiéter des détails triviaux de l'optimisation. Au lieu de cela, concentrez-vous sur la recherche du meilleur algorithme pour chaque tâche.

Answer 2

Selon la langue et le compilateur que vous avez mentionné, le compilateur optimisera parfois le code pour vous. Dans le monde d'aujourd'hui, vous ne remarquerez vraiment pas la différence entre votre exemple. Plus important encore, serait la maintenabilité et la lisibilité de votre code. Vous n'obtiendriez pas beaucoup d'avantages à faire ce dernier à moins que vous ne disiez un développement d'algorithme et des centaines de milliers d'itérations ou sur un processeur embarqué où chaque milliseconde comptait. Les prédictions de branche et les échecs de cache peuvent être différents.