Tu n'aimes peut être pas mon style, alenvers est sans doute très compétant, mais cela n'enlève pas mes compétence non plus.
Par exemple, dans le projet Lisaac, il a été fait un test sur le compilateur (50 kloc) pour voir l'effet, incrément par incrément, de l'inlining, et la diminution puis l'augmentation de la taille du code était très visible. ET le pourquoi aussi.
L'équation fournis plus haut, formalise simplement le fait que l'on va plus vite en évitant un appel de fonction, et les aller-retour dans les registres que cela implique. Ce genre de code va en effet plus vite, mais, comme je l'ai déjà dit les compilo font bien plus que ça. Dés que l'on parle d'inline, on entend toujours quelqu'un dire "attention cela va pourri les caches avec l'augmentation de la taille du code", sauf que personne n'a jamais montré cette augmentation.
Et de mes propres expériences, j'ai remarqué une diminution. Cette croyance va si loin, que j'ai déjà vu des gens découpés un projet en différent .c pour empêcher l'inline automatique du compilateur, car il croit mieux faire le compilo : le code est finalement plus lent et plus gros. C'est une croyance tenace pour les gros code, alors que c'est justement ceux qui ont le plus tendance à réduire.
J'ai aussi codé un firmeware fondu dans un chip TI pour la gestion d'énergie des SOC de téléphone, le genre de truc où tu comptes les octets. Au final, tu te retrouves avec l'équivalent d'un gros fichier avec plein de fonctions static (sinon le code est inliné mais une fonction existe toujours en cas d'appel externe dans le code objet), ce qui correspond au code généré le plus petit. Je dis "l'équivalent d'un gros fichier" car c'est tout de même plus propre de découper et d'utiliser des "#includes".
Il ne faut pas oublier non plus le début du thread : "il y a le fait que ça augmente la taille du code et met donc plus de pressions sur le(s) cache(s) et au final peut ralentir l'exécution d'un programme complexe (ce qui ne se verra pas forcément dans un micro benchmark)." pour que cela soit vrai, la fonction doit être énorme, et ne pas se recombiner avec le code alentour, ce qui est rarement le cas.
[^] # 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é à 4.
Tu n'aimes peut être pas mon style, alenvers est sans doute très compétant, mais cela n'enlève pas mes compétence non plus.
Par exemple, dans le projet Lisaac, il a été fait un test sur le compilateur (50 kloc) pour voir l'effet, incrément par incrément, de l'inlining, et la diminution puis l'augmentation de la taille du code était très visible. ET le pourquoi aussi.
L'équation fournis plus haut, formalise simplement le fait que l'on va plus vite en évitant un appel de fonction, et les aller-retour dans les registres que cela implique. Ce genre de code va en effet plus vite, mais, comme je l'ai déjà dit les compilo font bien plus que ça. Dés que l'on parle d'inline, on entend toujours quelqu'un dire "attention cela va pourri les caches avec l'augmentation de la taille du code", sauf que personne n'a jamais montré cette augmentation.
Et de mes propres expériences, j'ai remarqué une diminution. Cette croyance va si loin, que j'ai déjà vu des gens découpés un projet en différent .c pour empêcher l'inline automatique du compilateur, car il croit mieux faire le compilo : le code est finalement plus lent et plus gros. C'est une croyance tenace pour les gros code, alors que c'est justement ceux qui ont le plus tendance à réduire.
J'ai aussi codé un firmeware fondu dans un chip TI pour la gestion d'énergie des SOC de téléphone, le genre de truc où tu comptes les octets. Au final, tu te retrouves avec l'équivalent d'un gros fichier avec plein de fonctions static (sinon le code est inliné mais une fonction existe toujours en cas d'appel externe dans le code objet), ce qui correspond au code généré le plus petit. Je dis "l'équivalent d'un gros fichier" car c'est tout de même plus propre de découper et d'utiliser des "#includes".
Il ne faut pas oublier non plus le début du thread : "il y a le fait que ça augmente la taille du code et met donc plus de pressions sur le(s) cache(s) et au final peut ralentir l'exécution d'un programme complexe (ce qui ne se verra pas forcément dans un micro benchmark)." pour que cela soit vrai, la fonction doit être énorme, et ne pas se recombiner avec le code alentour, ce qui est rarement le cas.
"La première sécurité est la liberté"