Discussion :

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