"En conclusion, la réduction de la taille du code n'est pas pertinente pour « arrêter d'inliner ». C'est la perte de localité le facteur déterminant d'arrêt de l'inlining."
On est d'accord :) Disons que c'est évident pour un code donné.
Dans le cas d'une heuristique pour un compilo, avoir le code qui ré-augmente de taille permet de savoir quand arrêter d'inliner, même si cela n'est pas optimal (comme tu le dis le L1 change selon les CPU, l'optimum dépend donc de chaque cpu, ce qui a peu d’intérêt pour un binaire à distribué).
[^] # Re: la performance par l'inlining
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Si si, le C++ peut parfois être plus rapide que le C. Évalué à 2.
"En conclusion, la réduction de la taille du code n'est pas pertinente pour « arrêter d'inliner ». C'est la perte de localité le facteur déterminant d'arrêt de l'inlining."
On est d'accord :) Disons que c'est évident pour un code donné.
Dans le cas d'une heuristique pour un compilo, avoir le code qui ré-augmente de taille permet de savoir quand arrêter d'inliner, même si cela n'est pas optimal (comme tu le dis le L1 change selon les CPU, l'optimum dépend donc de chaque cpu, ce qui a peu d’intérêt pour un binaire à distribué).
"La première sécurité est la liberté"