Merci Corto pour ton expertise

>Normalement, le compilateur sait inliner (automatiquement) quand il faut
C'est ce que je pensais aussi ...

>Pour le groupement des fonctions afin d'améliorer la cachabilité ... je ne vois pas le gain puisque où que soit le code, s'il est exécuté souvent dans un temps réduit, il restera en cache.
Dans le cas où une fonction qui fais un gros traitement (donc se retrouve en cache) appelle une autre fonction souvent ... et donc se serait bien que les 2 soient dans le cache simultanément
Mais c'est purement spéculatif
Existe il un outil qui donne l'adresse des fonctions dans le binaire ? ainsi on connaittrais la position/taille des fonctions

>si vous mettez "inline" explicitement, sachez qu'il y a aussi une option de warning dans gcc
Oui je l'ai vu sur une fonction avec un nombre de paramétres variables = ca empéche d'inliner =normal
Ca m'a confirmé que les autres fonctions (que je voulais) avaient elles bien été inlinés

Alain

Normalement, le compilateur sait inliner (automatiquement) quand il faut. Il faudrait voir dans votre code quel facteur fait qu'il inline à outrance. L'inline sert pour les petites fonctions (qui n'en appellent pas d'autres) dont il applique le code directement dans le code des fonctions appelantes au lieu de le laisser dans une fonction dédiée : ça évite un saut, une éventuelle pénalité de cache, la gestion des paramètres, ...

Je ne compile jamais en -O3. Pas pour cette raison liée aux inlines mais surtout parce que en -O2 ... ça me va bien (et c'est moins long à compiler). L'optimisation : 1/ c'est une fois que ça marche bien 2/ ça demande toujours à être mesuré

Pour le groupement des fonctions afin d'améliorer la cachabilité ... je ne vois pas le gain puisque où que soit le code, s'il est exécuté souvent dans un temps réduit, il restera en cache.
Grouper des fonctions ça pourrait être valable pour éviter des fautes de TLB mais là encore ... il faut qu'il y ait manifestement un problème lié à ça et il faut donc le mesurer (un jour, avec Hieronymus ...).

Pour revenir aux inlines, si vous mettez "inline" explicitement, sachez qu'il y a aussi une option de warning dans gcc pour alerter s'il n'a pas pu inliner une fonction qui aurait dû l'être.

Oué .... Environ 4h par nuit :p
Donc la journée .... J'ai du mal :( MDR

Ok. Je vais testouiller voire si ça améliore les performances.

Ben tu mets "inline" devant la description de la fonction: je viens de l ecrire tu lis ou tu dors :-p
pour le cache je sais pas et je doute que cela soit possible...

Ce qui serait bien serait un outil qui donnerait la taille et l adresse des fonctions dans un binaire : comme ca on pourrait essayer de regrouper les fonctions strategiques au meme endroit en esperant qu elle soient toutes dans le cache.

Alain

Thellier,

Comment procèdes-tu pour le inline de certaines fonctions.

D'ailleurs, existe t-il une façon (via OS4 ou GCC) de mettre une fonction précise en cache ?

@+

Je me suis rabattu sur le -O2 qui a pas l'air mal pour mon cas puisque je retrouve les mêmes performances et avec un .exe plus petit
Mais j'ai quand même mis "inline" devant mes qques fonctions stratégiques

Après faut voir si certaines des options qu'activais aussi -O3 ne mériteraient pas d'être aussi remise manuellement (je veut dire en dehors de l'inlining que lui on peut remettre avec "inline" devant les fonctions stratégiques)

Voir ce site
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
Mais j'y comprends pas grand choses...

Alain

Oui Alain,

l'AmiDARK Engine étant un système basé sur des "fonctions" ... cela peut rapidement provoquer un grossissement des .EXE et des fonctions à rallonge.
(sachant qu'il y a des dépendances de fonctions)

Je vais testouiller sans le -03...
Sais-tu si le -O2 ou -O1 est intéressant ?

@+

>ça mériterait de mettre ça en anglais et le poster sur os4coding.net
Sans moi : mon anglais est trop afffreux

En fait il faut bien voir les limites du système de l'inlining :
1) Si ça insére ( les instruction d' ) une fonction petite dans toutes les grosses fonctions qui s'en servent = c'est bien
2) Si ça insére ( les instruction d' ) une fonction grosse dans toutes les petites fonctions qui s'en servent = c'est pas bien

Par exemple si on a une petite fonction mathématique comme mon Normalize (qui donnera peut être 20 instructions ASM) alors autant l'insérer aux rares endroits où on s'en sert = là l'inlining est efficace

Par contre si chaque fonction qui utilise ma grosse fonction DrawObject() (qui elle doit faire des milliers d'instructions) commence à insérer tout ça alors là l'obésité du code menace = là l'inlining fait n'importe quoi

En plus certaines fonctions servent rarement (par exemple mon AddObject() qui sert qu'au moment du chargement de fichiers 3D) ==> est il utile de les rendre objectivement plus rapides mais aussi plus grosses ?

Bref si on y réfléchis les fonctions que l'on veut vraiment inliner sont:

1) Celles qui servent qu'à un endroit où on aurait d'ailleurs dû écrire le code mais qu'on a mis dans une fonction séparée pour faire plus propre

2) Celles qui servent souvent et/ou dans des boucles et sont petites (comme une fonction mathématique)
Normalement on en ferait des macros mais parfois c'est plus pratique à écrire sous forme de fonction
Par exemple la fonction Normalize aurait été chiante à écrire en macro à cause de la variable locale size

Pour ces fonctions il faut donc ajouter "inline"
comme ça
inline void Normalize(Vertex3D *c)

Alain

Belle explication. Je ne connaissais pas ce "inline". ça mériterait de mettre ça en anglais et le poster sur os4coding.net

ouf tu ma fais peur... :-)