Pas forcément, il vaut mieux avoir un boucle for non déroulée qui tient dans le cache L1 qu'une boucle déroulée qui n'y tient pas.
Je veux dire sur du vrai code de la vrai vie. Tu te rend compte de la taille de code qui rentre dans un cache L1 ? On parle de boucle interne, pour remplir les 16/32/64 Ko de cache L1, il faut sans doute, l'équivalent d'un millier de lignes de code.
C'est une chose qu'on contrôle très mal à l'échelle d'un programme, parceque passer d'un modèle à l'autre (folded/unfolded) change de façon imprévisible la façon dont le code est saucissonné en morceaux de pages de cache.
Oui et sur un code moyen, cela ne change rien. Par contre localement, la différence de performance est énorme. En -O3, gcc a tendance a dérouler les petites boucles 16 fois. J'estime que dérouler 4x fois ne peut jamais faire perdre de performance.
Le comportement normal du compilateur est l'optimisation pour la taille, mais on peut le configurer pour qu'il fasse autre chose.
Tu parles de Ocaml, car tous les compilateurs C optimisent pour la vitesse. Le "-Os" de gcc évitent seulement les optimisations connues pour faire enfler le code.
[^] # Re: Plutôt beauté du design
Posté par Nicolas Boulay (site web personnel) . En réponse au journal "beauté du code". Évalué à 3.
Je veux dire sur du vrai code de la vrai vie. Tu te rend compte de la taille de code qui rentre dans un cache L1 ? On parle de boucle interne, pour remplir les 16/32/64 Ko de cache L1, il faut sans doute, l'équivalent d'un millier de lignes de code.
Oui et sur un code moyen, cela ne change rien. Par contre localement, la différence de performance est énorme. En -O3, gcc a tendance a dérouler les petites boucles 16 fois. J'estime que dérouler 4x fois ne peut jamais faire perdre de performance.
Tu parles de Ocaml, car tous les compilateurs C optimisent pour la vitesse. Le "-Os" de gcc évitent seulement les optimisations connues pour faire enfler le code.
"La première sécurité est la liberté"