Discussion :

[sone47]

Bonjour,

Évoluant anciennement dans le monde de l'assembleur ou chaque cycle d’exécution ou octet mémoire était précieux, nous avions quelques "règles" d'optimisations liées au langage utilisé.

Aussi, dans le cadre de développement embarqué en C et également C++, quelles sont les "règles" de bonnes conduites d'optimisations, astuces etc à adopter... Ou a contrario que faut il éviter ? Ceci afin de partager les expériences sur un sujet qui n'est (a mon gout) pas assez poussé dans l'enseignement.

++

[Aquanum]

Personnellement je suis les règles du CodingStyle de Linux.
Vu que je travaille directement sur le kernel cela va de soi. Mais je l'applique à toutes les autres applications que je développe en C. Il y a déjà beaucoup de conseils généralistes qui s'appliquent tant à l'embarqué qu'au userland.

Ensuite concernant le dev embarqué, je n'utilise pas d'optimisation particulière supplémentaire, si ce n'est privilégier le:

Code :

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

for(;;)

au

Code :

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

while(1)

Aujourd'hui il est de moins en moins nécessaire avec le matériel récent d'optimiser à mort son code.

C'est comme le code limité à 80 colonnes en largeur. Même si en C il est toujours préconisé de continuer à suivre cette directive, en Java par exemple cela n'a plus de sens sur nos écrans récents de 24"...

Il est pas mal, à mon sens, de faire un compromis entre :

• l'optimisé
• le lisible/maintenable.
• le pratique à coder et surtout pas trop prise de tête pour des détails

[3DArchi]

Salut,

Aussi, dans le cadre de développement embarqué en C et également C++, quelles sont les "règles" de bonnes conduites d'optimisations, astuces etc à adopter...

LA première règle : lire la doc du compilateur et bien étudier ses options.

[Bktero]

Je viens de voir ça dans ton lien, Aquanum :

Do not unnecessarily use braces where a single statement will do.

if (condition)
do_this();
else
do_that();

Je ne trouve pas ça beau du tout



Pour moi, l'une des astuces les plus simples (c'est du bon sens, je me demande pourquoi je le dis), c'est pour les tests. Si tu dois effectuer plein de tests, je préfère les imbriquer et les prioriser pour limiter les évaluations. Par exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
if(condition qui arrive tout le temps)
{
   ...
}
else if(condition qui n'arrive jamais)
{
   ...
}
else
{
   ...
}

au lieu de :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
if(condition qui n'arrive jamais)
{
   ...
}
else if(condition qui arrive tout le temps)
{
   ...
}
else
{
   ...
}

[Bktero]

Au encore (surtout si condition 1 est peu probable) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
if (condition_1)
{
   if(condition_2)
   {
      ...
   }
   else if (condition_3)
   {
      ...
   }
}
else
{
   ...
}

au lieu de :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
if (condition_1 AND condition_2)
{
   ...
}
else if (condition_1 AND condition_3)
{
   ...
}
else
{
   ...
}

[Aquanum]

Qu'est-ce que tu ne trouves pas beau ?
Le fait de ne pas utiliser d'accolade ?

Avant je mettais des accolades partout, mais avec l'expérience j'applique de plus en plus cette technique quand il n'y a qu'une ligne/commande par scope. C'est moins lourd à lire.
Sinon je trouve les règles de code de Linux bien pensées, je les appliques à la lettre et j'en suis ravi Ça fait du code bien lisible.

Sinon, je suis complètement d'accord avec tes autres remarques.
Par contre pour éviter les conditions imbriquées qui rapidement donnent un code imbuvable, j'ai tendance à échapper les erreurs au plus vite.

Code :

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

1
2
3
4
5
6
7
8
if (erreur)
return -1;

if (erreur2)
return -1;

do_machin_truc();
return 0;

plutôt que :

Code :

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

1
2
3
4
5
6
if (erreur || erreur2) {
return -1;
} else {
do_machin_truc();
return 0;
}

[Bktero]

Oui, je ne trouve pas du tout beau le fait de ne pas utiliser d'accolade. Je trouve ça beaucoup plus lisible, car tu délimites tout de suite ce qui est fait pour le IF du reste. Certes, c'est plus lourd, mais cela évite des erreurs.

J'ai une fois corrigé une anomalie au taff, un problème assez....bizarre... Il s'est avéré qu'une personne avait ajouté une deuxième ligne et ne c'était pas aperçu qu'il n'y avait pas d'accolade. Ca compile, ça se lance, niquel. Oui, mais le comportement change et ce n'était pas flagrant dans le cas nominal.

Je t'accorde que c'est une erreur de programmation, mais s'il y avait eu des accolades dés le début, on n'aurait pas eu le problème.

J'étais partisan des accolades avant, mais après, je suis devenu un fanatique



Pour ce qui est de ton code, j'aime encore bien ta première solution aussi. Surtout quand les cas s'imbriquent et que l'indentation augmente. En revanche, le second code, j'aurais tendance à le faire comme ça :

Code :

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

1
2
3
4
5
6
7
8
9
if (erreur || erreur2)
{
    CODE_RETOUR = 1;
} else {
    do_machin_truc();
    CODE_RETOUR = 1;
}
return CODE_RETOUR;

Ainsi, je respecte l'une des fameuses qui dit que la fonction ne doit avoir qu'un seul point de sortie. Il faut avouer que c'est pratique pour concentrer les actions à faire en fin de fonction, genre les logs.... Ce n'est pas forcément très utilisé en embarqué les logs ^^



Une autre optimisation à laquelle je pense, en me remémorant de mes cours de C : c'est l'accès au tableau, selon si tu passes par un "vrai" tableau avec les [] ou par un pointeur.... Mais je ne m'en souviens plus :s Je vais fouiller un peu.

[Nicolus]

Bonsoir

Quelqu'un pourrait-il m'expliquer en quoi le

Code :

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

for(;;)

est plus optimisé que le

Code :

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

while(1)

?

Sinon, lorsque l'on cherche à tout prix l'optimisation, ne faut-il pas privilégier le compilateur Intel sur leurs architectures ?

Concernant le if en C, personnellement j'aurais tendance à privilégier l'écriture en une ligne:

Code :

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

if (condition) action();

De cette manière, il devient presque impossible de faire l'erreur citée précédemment

Je continue sur la typographie, depuis mes débuts en programmation je ne comprends pas pourquoi beaucoup de programmeurs notent leurs blocs de code comme ceci:

Code :

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

1
2
3
4
if (condition)
{
/* Action */
}

Je trouve cette notation tellement plus pratique et agréable:

Code :

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

1
2
3
if (condition) {
/* Action */
}

Agréable, par ce que l'on n'utilise pas des tas de lignes pour un seul caractère.
Pratique, car si l'on réduit le bloc on a:

Code :

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

if (condition) {...}

Et non:

Code :

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

1
2
if (condition)
{...}

Je trouve ça tellement mieux, mais ce n'est que subjectif et ce n'est en rien une optimisation, enfin on peut qualifier cela d'optimisation visuelle

Sinon, pour les pointeurs, personnellement j'utilise les deux notations:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
int * tab;
int ** tab2;

/* Allocation */
...

tab[indice] = ...
(*(tab2+indice))[indice] = ... ou encore (tab[indice])[indice] ...

/* Libération */
...

[Aquanum]

Dans nos remarques, il est plus question ici de normes de codage, de facilité de lecture que d'optimisation. Donc finalement, libre à nous d'utiliser la norme que l'on préfère.

Concernant tes remarques sur l’esthétique du code Nicolus, je ne suis (personnellement) pas un grand fan de ces écritures, mais ça n'engage que moi.
Il y a pas mal de normes de codage, avec souvent des explications derrière. Je ne les connais pas toutes.
Je sais juste que les normes de codage du kernel (dans mon cas, car je développe sur le kernel) sont strictes et définies par des règles bien précises.
C'est souvent le cas en open source. Tu as par exemple les normes de codage GNU, qui sont par contre assez violentes à suivre.

Comme dans pas mal de langages il y a plein de façons de présenter, indenter le code. C'est plus une question de goût qu'autre chose lorsque l'on code pour soi.
Dès qu'il s'agit d'un projet à plusieurs, voir open source, des normes de codage répandues deviennent pertinentes. Je trouve les règles du kernel pas trop contraignantes et bien expliquées. Donc je les suis.

Pour la différence for/while, au temps pour moi c'est exactement la même chose en C en terme de rapidité. Ça doit être une vieille habitude de je ne sais plus quel langage que j'ai étudié avant le C qui doit faire la distinction. Donc pour le coup while(1) ou for(; même combat C'est donc une question de préférence personnelle

[Nicolus]

Dans nos remarques, il est plus question ici de normes de codage, de facilité de lecture que d'optimisation. Donc finalement, libre à nous d'utiliser la norme que l'on préfère.

Oui, complètement, désolé d'avoir contribué à la déviation du sujet ^^

Comme dans pas mal de langages il y a plein de façons de présenter, indenter le code. C'est plus une question de goût qu'autre chose lorsque l'on code pour soi.

Initialement c'est probablement une question de goût, après je pense que c'est surtout une question d'habitude

Il est clair qu'il faut imposer des conventions de codage, personnellement je trouve qu'il est plus important de s'attarder sur les conventions de nommage que sur le placement des accolades d'un bloc, après mon manque d'expérience joue peut-être en ma défaveur sur ce point Je trouve ça dommage qu'il y ait autant de contraintes pour ceux qui souhaitent participer au développement des distrib', je pense qu'il faut surtout s'intéresser aux algorithmes, à l'indentation, au nom des variables / structures de données.

Après, c'est peut-être par ce que c'est répandu que j'aime me démarquer des autres, mais j'ai voulu me faire une raison objective

Pour la différence for/while, au temps pour moi c'est exactement la même chose en C en terme de rapidité. Ça doit être une vieille habitude de je ne sais plus quel langage que j'ai étudié avant le C qui doit faire la distinction. Donc pour le coup while(1) ou for(; même combat C'est donc une question de préférence personnelle

Justement, je posais la question car j'avais déjà vu cela, mais je n'ai jamais su quelle était la différence pour le compilateur. Donc je ne sais absolument pas laquelle est meilleure pour de l'embarqué !

[Aquanum]

Oui, complètement, désolé d'avoir contribué à la déviation du sujet ^^

Huhu, t'en fais pas parce que moi aussi

Justement, je posais la question car j'avais déjà vu cela, mais je n'ai jamais su quelle était la différence pour le compilateur. Donc je ne sais absolument pas laquelle est meilleure pour de l'embarqué !

De ce que j'ai compris, pour le compilo c'est la même chose. Mais je n'ai pas encore trouvé d'explication détaillée (qui m'intéresserait beaucoup). Mais en gros, la boucle for s'utilise plutôt dans le cas où tu connais le nombre d'itérations à l'avance, alors que le while s'utilise dans les cas où l'on ne connait pas à l'avance le nombre de tours de boucles. Je n'ai pas trouvé encore d'autres différences.

[Nicolus]

Yep, dans mon jargon d'étudiant on appelle ça une boucle déterministe (connaissance du nombre de tours) ou non déterministe !

Pour moi, une boucle for n'est qu'une écriture particulière d'une boucle while.. j'avais cru comprendre que c'était interprété comme cela pour un compilateur en tout cas.

[3DArchi]

Bonsoir,

La plus part des trucs du type 'utiliser ceci à la place de cela' souffrent de deux inconvénients majeurs :
=> vérité en deçà des pyrénées erreur au-delà : ce qui est vrai pour un micro/compilo n'est pas forcément vrai pour un autre.
=> o tempora o mores : les évolutions des architectures et/ou des outils rendent obsolètes ou même fausses ces règles.
Les seules règles d'optimisations :
=> "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" de Donald Knuth
=> En cas de besoin avéré : étudier dans l'ordre : l'algo, puis le compilo&les datasheets nécessaires.

Sur les règles de formatage du code, ici, chacun son style à quelques remarques près :
=> certaines sont plus 'error-prone' que d'autres : exemple l'absence d'accolade des if/for/while laisse toujours un doute sur l'intention de l'auteur (ne pas oublier qu'un code est plus souvent lu qu'exécuté). C'est même souvent interdit par des règles de codage en industrie et relever comme problématique par les outils d'analyse statique de code.
=> certaines branches de l'embarqué ont des règles de codage (comportant des règles de nommage et de formatage) imposées par l'industrie (MISRA) ou par des certifications de sécurité (DO-178B)

[gorgonite]

=> vérité en deçà des pyrénées erreur au-delà : ce qui est vrai pour un micro/compilo n'est pas forcément vrai pour un autre.
=> o tempora o mores : les évolutions des architectures et/ou des outils rendent obsolètes ou même fausses ces règles.

+100
un excellent exemple avec l'implantation de machine virtuelle dans un langage comme le C. Il y a 3 grandes méthodes, avec des avantages conséquents si le jeu d'instruction de la VM est bas niveau

1. le naïf switch/case a l'avantage de ne pas consommer trop de mémoire, il y a 3 instructions de contrôle pour une instruction de bytecode... dur dur si le bytecode est bas niveau (additionner deux entiers, etc)
2. le threaded-code assez portable. on crée une table d'adresse de la taille d'une adresse mémoire * le nombre d'instructions de la VM, et on remplace le switch/case par un goto à la fin de chaque exécution d'instruction... on passe du facteur 3 contrôles pour 1 bytecode au facteur 1 contrôle pour 1 bytecode. a priori c'est génial, mais sur certaines architectures avec des prédictions de branchement "subtiles" (Itanium, Pentium IV) on peut même être plus lent que la version naïve
3. le DAC ou le JIT peu portable, ultra dépendant de matériel, et comme toutes les optimisations de compilation parfois désastreuses dans des cas particuliers ou sur des architectures pathologiques

[Nicolus]

certaines sont plus 'error-prone' que d'autres : exemple l'absence d'accolade des if/for/while laisse toujours un doute sur l'intention de l'auteur (ne pas oublier qu'un code est plus souvent lu qu'exécuté). C'est même souvent interdit par des règles de codage en industrie et relever comme problématique par les outils d'analyse statique de code.

Désolé de relancer encore le débat ^^ mais je ne comprends pas trop en quoi c'est plus difficile de lire sans accolades

Perso un if(condition) action(); je le lis d'une traite et je trouve que c'est même plus rapide, en un coup d'oeil on voit le tout alors que dispatcher ça en trois lignes, ça fatigue

Enfin, cette réflexion n'apporte rien dans cette discussion, désolé ^^

Histoire de revenir un peu au sujet, je pense en effet que la première source d'optimisation, c'est la réflexion sur les algorithmes, avec au mieux un outil de monitoring

[3DArchi]

Désolé de relancer encore le débat ^^ mais je ne comprends pas trop en quoi c'est plus difficile de lire sans accolades

Code :

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

1
2
3
if(test)
action();
suite();

C'est :

Code :

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

1
2
3
4
5
if(test)
{
action();
}
suite();

ou (et alors erroné)

Code :

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

1
2
3
4
5
if(test)
{
action();
suite();
}

???
En relecture de code, il y a toujours un doute.

Pour rappel, la plus part des règles de code (MISRA étant très répandu en indus embarqué) exigent :
=> 1 instruction par ligne (donc on oublie le if(test) action; )
=> les accolades.
=> et un else même vide.
Soit :

Code :

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

1
2
3
4
5
6
7
if(test)
{
   action();
}
else
{
}

La plus part des IDE te proposeront des macros pour ne pas avoir à fatiguer tes doigts si tu trouves cela trop long .

[Bktero]

Je viens de lire ça dans un article :

Code :

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

1
2
3
4
5
6
7
for(i = 0; i < strlen(line); i++)
{
    ...
    doSomethingWith(line);
    ...
}

et l'auteur dit que c'est très mal !

Ce n'est pas le cas en C++ :

Code :

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

1
2
3
4
5
6
7
for(i = 0; i < line.length(); i++)
{
    ...
    doSomethingWith(line);
    ...
}

Voir : http://warp.povusers.org/OpenLetters...oTorvalds.html

[Bktero]

Je remonte un peu le sujet car je viens de retrouver un document PDF qui semble tout à fait intéressant et qui traite de l'utilisation du C++ pour l'embarqué.

J'ai trouvé un lien vers le PDF sur Internet, le voici pour ceux que ça intéresse

http://www.open-std.org/jtc1/sc22/wg..._401_paper.pdf

[3DArchi]

Je remonte un peu le sujet car je viens de retrouver un document PDF qui semble tout à fait intéressant et qui traite de l'utilisation du C++ pour l'embarqué.

J'ai trouvé un lien vers le PDF sur Internet, le voici pour ceux que ça intéresse

http://www.open-std.org/jtc1/sc22/wg..._401_paper.pdf

Dans la même veine, il y a le TR sur les performances : TR18015

[bpy1401]

Bonjour à tous

Cela fait une bonne vingtaine d'année que je travaille dans le développement C en environnement embarqué , et tout spécialement dans l'automobile. J'ai vu beaucoup de chose évoluer pendant ce temps. Au début, c'était plus de la bidouille que de la méthode, mais maintenant c"est plutôt l'inverse.

Déjà on a plusieurs procédures applicable dans le développement, certaines externes et d'autre interne. Du point de vue présentation du code, on a des règles de nommage et présentation du code pour que tous le monde chez nous applique les même règles. Ensuite, du point de vue qualité d'écriture, on applique les règles MISRA qui décrivent ce que l'on ne doit pas faire (pareil c'est issu d'un bêtisier).

Par rapport çà ce que vous dites, voici ce que l'on préconise chez nous

if(test)
action();

est interdit, on doit avoir les accolades. ce n'est pas pour embêter les programmeurs mais pour éviter ce genre de problème que l'on a déjà vu

Code :

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

1
2
3
4
5
#define ACTION()  fct1();fct2()

if(test)
   ACTION();

je vous laisse imaginer le résultat.

Du point de vue optimisation de code, une seule solution pour choisir entre deux écriture, c'est la comparaison du code assembleur généré.

J'aurais bien proposer un article décrivant les règles à respecter, mais je pense que cela va partir dans une bataille d'expert.