[Optimisations] Langage C et C++ pour l'embarqué

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.

++

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:

---

for(;;)

---

au

Code:

---

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

Salut,

Citation:

---

Envoyé par sone47

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.

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

Citation:

---

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 :aie:



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:

---

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:

---

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 { ... }

---

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

Code:

---

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:

---

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 { ... }

---

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:

---

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:

---

1 2 3 4 5 6

if (erreur || erreur2) { return -1; } else { do_machin_truc(); return 0; }

---

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 :mouarf:



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:

---

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.

Bonsoir :)

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

Code:

---

for(;;)

---

est plus optimisé que le

Code:

---

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:

---

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:

---

1 2 3 4

if (condition) { /* Action */ }

---

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

Code:

---

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:

---

if (condition) {...}

---

Et non:

Code:

---

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 :P

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

Code:

---

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 */ ...

---

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 :P

Citation:

---

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 ^^

Citation:

---

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 :mouarf:

Citation:

---

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é !

Citation:

---

Envoyé par Nicolus

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

---

Huhu, t'en fais pas parce que moi aussi :P

Citation:

---

Envoyé par Nicolus

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.

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.

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)

Citation:

---

Envoyé par 3DArchi

=> 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 :aie:

Citation:

---

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 :mrgreen:

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 :)

Citation:

---

Envoyé par Nicolus

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:

---

1 2 3

if(test) action(); suite();

---

C'est :

Code:

---

1 2 3 4 5

if(test) { action(); } suite();

---

ou (et alors erroné)

Code:

---

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:

---

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 ;).

Je viens de lire ça dans un article :

Code:

---

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:

---

1 2 3 4 5 6 7

for(i = 0; i < line.length(); i++) { ... doSomethingWith(line); ... }

---

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

;)

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

Citation:

---

Envoyé par 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

---

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

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

Citation:

---

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:

---

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.

Citation:

---

Envoyé par 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.

++

---

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. ;)

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 :mouarf:)

Citation:

---

Envoyé par Guyt54

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.

Citation:

---

Envoyé par 3DArchi

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?

Citation:

---

Envoyé par sone47

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

---

Citation:

---

Envoyé par Guyt54

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.

Salut,

Citation:

---

Envoyé par Guyt54

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.