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.

[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.

[Guyt54]

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.

++

La question que j'attends depuis 20 ans, alors je me priverai pas!

Mon premier conseil: fuis les "floats" comme la peste. Y a rien qui bouffe plus de temps et d'espace-mémoire que des calculs en float.

J'ai beau le répéter à mes étudiants, y en rien à faire dès qu'ils voient la possibilité d'une décimale quelque part, ils me balancent un "float".

Par exemple, si je leur demande de me faire un thermomètre électronique avec une précision avec un "range" de -50 à + 50de 0,1 degrés Celsius (disons de -49,9 à + 49,9 degrés).

Si je le laisse aller, je vais voir des floats partout.

"Dites les gars, ça vous tenterait pas d'utiliser un "int" qui à l'interne va représenter des dixièmes de degrés (ex: -499 à 499)".

De temps en temps, y en a un qui me sort "Oui mais, j'ai besoin de précision". "Il vient d’où ton calcul?" . "D'un convertisseur analogique à numérique 10 bits.

Et là, je lui explique le principe de fonctionnement interne d'un ADC pour lui démontrer la précision réelle d'un ADC qui tourne autour de 8 bits et demi pour un ADC 10 bits. Et même si on avait une précision de 10 bits, il reste qu'on a seulement 1 024 valeurs discrètes, alors on va se calmer avec la précision de 23 chiffres après la virgule.

Évidemment, si je le sens contrarié, j'insiste pas, je veux surtout pas qu'un parent m'appelle pour se plaindre que j'ai bousculé son enfant.

[Bktero]

Je suis en mission chez un fabricant de chaudière en ce moment. Les températures sont stockées dans des entiers, représentées en 16e de degrés (voire 256e de degrés mais je me demande bien d'où sort une telle précision )

[3DArchi]

Mon premier conseil: fuis les "floats" comme la peste. Y a rien qui bouffe plus de temps et d'espace-mémoire que des calculs en float.

La problématique que tu décris ne concerne à mon avis pas tant l'optimisation que le fait de choisir le type pertinent pour représenter correctement une donnée physique dans un logiciel. Ici, clairement, un entier (avec un facteur d'échelle) suffit. D'ailleurs les calculs seront (et c'est ce qui déroute au premier abord les jeunes étudiants) plus précis avec des entiers qu'avec des réels.

[Guyt54]

La problématique que tu décris ne concerne à mon avis pas tant l'optimisation que le fait de choisir le type pertinent pour représenter correctement une donnée physique dans un logiciel. Ici, clairement, un entier (avec un facteur d'échelle) suffit. D'ailleurs les calculs seront (et c'est ce qui déroute au premier abord les jeunes étudiants) plus précis avec des entiers qu'avec des réels.

Faudrait s'entendre par ce qu'on entend par "optimalisation", parce que ce que tu dis me semble être une des règles fondamentales pour obtenir du code optimalisé, non?

[gangsoleil]

quelles sont les "règles" de bonnes conduites d'optimisations, astuces etc à adopter... Ou a contrario que faut il éviter ?

Faudrait s'entendre par ce qu'on entend par "optimalisation", parce que ce que tu dis me semble être une des règles fondamentales pour obtenir du code optimalisé, non?

Guyt54 vient de tout casser

Blague a part, il est bien evident qu'on ne peut pas tout optimiser, et que le developpement d'un programme n'est qu'un compromis entre les differentes optimisations possibles : a chaque fois que tu augmentes ou que tu baisses un parametre (consommation CPU par exemple), tu diminues ou augmente d'autant un autre (temps de developpement par exemple).

Obtenir un code optimal dans tous les domaines demande ainsi un temps infini.

[3DArchi]

Salut,

Faudrait s'entendre par ce qu'on entend par "optimalisation", parce que ce que tu dis me semble être une des règles fondamentales pour obtenir du code optimalisé, non?

Ca n'a rien à voir.
L'optimisation, en général, cherche à minimiser la taille du code et/ou (quoique 'et' soit souvent contradictoire) sa vitesse d'exécution.
Ce qui est fondamentalement différent de savoir si le type est pertinent ou non pour représenter la donnée. Même si un jour les calculs en flottants sont sans commune mesure plus rapides et tiennent moins de place qu'un calcul en entier (on peut toujours supposer), certaines mesures physiques resteront plus pertinentes en entier ne serait-ce qu'à cause des impacts sur les algorithmes numériques liés à la représentation flottante. Le choix du type pour représenter une donnée dépend d'abord de ce qu'elle représente et de ce qu'on en fait. Et ça n'a que peu à voir avec l'optimisation(*).


(*) : ce qui n'empêche pas qu'une fois qu'on a décidé de travailler en entier de se poser la question sur la taille de l'entier à choisir. Et là, la réponse peut dépendre d'un tas de paramètres du micro et avoir une influence sur taille du code et/ou vitesse d'exécution.