Discussion :

[progfou]

Bonjour à tous et toutes !
Je suis en train d'essayer d'optimiser un programme qui calcule des fft, et je vois, dans un code, que les fonctions qui reviennent très souvent sont passées en macro pour certaines et en "static inline" pour d'autres.
Je sais en gros ce que ça fait, mais j'aimerais avoir votre avis sur ce genre d'optimisation "basique". Est-ce efficace ?
Est-ce qu'il faudrait tout passer comme ça, ou seulement les fonctions simples, les plus appelées ?
Peut-on tout passer "les yeux fermés" ou y a-t-il des conditions à respecter ?

Merci d'avance aux gourous

[Emmanuel Delahaye]

Je suis en train d'essayer d'optimiser un programme qui calcule des fft, et je vois, dans un code, que les fonctions qui reviennent très souvent sont passées en macro pour certaines et en "static inline" pour d'autres.

classique...

Je sais en gros ce que ça fait, mais j'aimerais avoir votre avis sur ce genre d'optimisation "basique". Est-ce efficace ?

Ca peut... mais le choix, l'optimisation et le codage de l'algorithme sont aussi très déterminants.

Est-ce qu'il faudrait tout passer comme ça, ou seulement les fonctions simples, les plus appelées ?

#2

Peut-on tout passer "les yeux fermés" ou y a-t-il des conditions à respecter ?

• Passer son code au profiler pour déterminer les points de ralentissements.
• Eviter les macros et préférer les inline (C99)
• Attention, inline() n'est qu'une proposition. Si on utilise l'adresse de la fonction, l'inline ne se fera pas. Idem si elle n'est pas 'static'.

[progfou]

• Passer son code au profiler pour déterminer les points de ralentissements.
• Eviter les macros et préférer les inline (C99)
• Attention, inline() n'est qu'une proposition. Si on utilise l'adresse de la fonction, l'inline ne se fera pas. Idem si elle n'est pas 'static'.

Peux-tu m'expliquer les deux derniers points ?
Je croyais que les macros c'était mieux :s.
Si tu appelles la fonction directement (elle est supposée inline), pas en passant par son adresse, ça fonctionne, c'est ça ?

[Emmanuel Delahaye]

• Passer son code au profiler pour déterminer les points de ralentissements.
• Eviter les macros et préférer les inline (C99)
• Attention, inline() n'est qu'une proposition. Si on utilise l'adresse de la fonction, l'inline ne se fera pas. Idem si elle n'est pas 'static'.

Peux-tu m'expliquer les deux derniers points ?
Je croyais que les macros c'était mieux :s.

"Les macros c'est mal" notamment à cause de l'absence de contrôle des paramètres, des risques de double évaluation des paramètres, de la difficulté d'avoir une valeur de retour claire... Bref, en C90, c'est un pis-aller...

Si tu appelles la fonction directement (elle est supposée inline), pas en passant par son adresse, ça fonctionne, c'est ça ?

Ca fonctionnne toujours. Simplement, si on a besoin explicitement de l'adresse, la fonction ne sera pas 'inlinée'.

[progfou]

D'accord.
Dans ce cas, as-tu un lien qui m'expliquerait en deux mots (mais deux bons ) ce que signifie "inliner" une fonction ?
Plus précisément, que fait le compilateur ?

J'ai un cas où il y a un if, et entre les deux conditions if et else, la seule différence est une boucle for assez conséquente (incrémentation de 1 à environ 20000) et ce, assez souvent.
Si je fais une fonction static inline qui contient cete boucle, et que je sors le reste, vais-je gagner quelque chose ?

[Pragmateek]

Inliner une fonction veut dire que le compilo va remplacer les différents appels à la fonction par le code de la fonction ce qui évite les ralentissements dus aux passage de parametres notamment.

Voir : http://www.developpez.com/c/megacours/x559.html#AEN667

[progfou]

Si, dans ma boucle, j'ai des parmètres qui sont des pointeurs, ça ne pose pas de problème ??
Je vais donner un exemple, ce sera nettement plus clair, surtout pour moi ^_^ :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
for (count=1 ; count < SIZE ; count++) {
    psdval=(3072 - (*expbufptr << 7));
    expbufptr++;
    fftbuf[count]=psdval;
}

Le reste est inutile.
Les noms ne sont pas importants, mais c'est le principe...
Cette boucle est beaucoup appelée, et tourne sur SIZE qui peut être important.
Je suis certain de pouvoir mieux faire, mais je ne sais pas si un inline est utilisable dans ce cas.
Autre chose, peut-on appeler des macros dans des fonctions "inlinées" ?

[Emmanuel Delahaye]

Si, dans ma boucle, j'ai des parmètres qui sont des pointeurs, ça ne pose pas de problème ??

Non.

Je vais donner un exemple, ce sera nettement plus clair, surtout pour moi ^_^ :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
for (count=1 ; count < SIZE ; count++) {
    psdval=(3072 - (*expbufptr << 7));
    expbufptr++;
    fftbuf[count]=psdval;
}

Le reste est inutile.
Les noms ne sont pas importants, mais c'est le principe...
Cette boucle est beaucoup appelée, et tourne sur SIZE qui peut être important.
Je suis certain de pouvoir mieux faire, mais je ne sais pas si un inline est utilisable dans ce cas.

pas de problème tant que tu es 'static', et que l'adresse de la fonction n'est pas utilisée explicitement (callback, pointeur de fonction...)

Autre chose, peut-on appeler des macros dans des fonctions "inlinées" ?

Les macros ne sont que des substitutions de texte, on fait ce qu'on veut, c'est traité avant la compilation... Moi, je m'en sers pour écrire du C répétitif...

[progfou]

Oki !
Merci .
Donc, cette boucle peut être passée dans une fonction "static inline".
Cool

[progfou]

Si je prend cette boucle, précisément (je la redonne) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
for (count=1 ; count < SIZE ; count++) {
    psdval=(3072 - (*expbufptr << 7));
    expbufptr++;
    fftbuf[count]=psdval;
}

Je peux accélérer le processus en sortant le pointeur, non ?
Car là, j'ai l'impression que ça doit prendre du temps, il faut aller chercher la valeur à partir de l'adresse, la décaler de 7 bits vers la gauche, soustraire ce nombre à 3072, puis incrémenter l'adresse, et ce, SIZE fois...

Ca me parait un peu barbare, non ?

PS: le code n'est pas de moi, j'essaie de l'améliorer.

[Emmanuel Delahaye]

Si je prend cette boucle, précisément (je la redonne) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
for (count=1 ; count < SIZE ; count++) {
    psdval=(3072 - (*expbufptr << 7));
    expbufptr++;
    fftbuf[count]=psdval;
}

Je peux accélérer le processus en sortant le pointeur, non ?

Je ne vois pas bien comment améliorer ça. Peut être avec un pointeur pour accéder à fftbuf si ce n'est pas fait par le compilateur. Tu as regardé l'assembleur ?

si fftbuf est un tableau

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
T *p;
for (p = fftbuf + 1 ; p < fftbuf + SIZE ; p++) 
{
    psdval=(3072 - (*expbufptr << 7));
    expbufptr++;
    *p = psdval;
}

si fftbuf est un pointeur

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
T *p;
T *const p_end = fftbuf + SIZE;
for (p = fftbuf + 1 ; p < p_end ; p++) 
{
    psdval=(3072 - (*expbufptr << 7));
    expbufptr++;
    *p = psdval;
}

[progfou]

Non je n'ai pas regardé l'assembleur, le code généré est directement un code objet. Et je n'ai pas possibilité de modifier le makefile, mais je crois que je peux quand même avoir une idée du code, directement depuis l'objet ?
Quel outil (sous linux) permet de faire ça ?
fftbuf est un tableau, donc ce serait la première solution.

[Emmanuel Delahaye]

Non je n'ai pas regardé l'assembleur, <...>
Quel outil (sous linux) permet de faire ça ?

gdb ?

[progfou]

Ouais, donc insight .
Je ne maitrise pas du tout gdb, je préfère passer par une gui...
J'ai jamais trouvé de site expliquant vraiment très bien comme s'en servir.

[Jean-Marc.Bourguet]

Non je n'ai pas regardé l'assembleur, le code généré est directement un code objet. Et je n'ai pas possibilité de modifier le makefile, mais je crois que je peux quand même avoir une idée du code, directement depuis l'objet ?
Quel outil (sous linux) permet de faire ça ?
fftbuf est un tableau, donc ce serait la première solution.

tu copies la ligne de commande que ton makefile genere et tu remplaces -c par -S.

objdump a si je ne m'abuse aussi une option pour dessassembler.