Version imprimable
Salut à tous !
Actuellement en stage en entreprise, on m'a filé un programme C et on m'a demandé de réduire la mémoire utilisée par ce dernier, qui est actuellement de 98%.
Bon j'adore le C, mais n'étant qu'en 2°A de DUT GEII, je n'ai pas ces compétences. Je suis donc parti à la recherche d'infos sur internet, mais ça prend du temps donc je viens ici pour avoir un complément, en espérant que vous puissiez m'aider !
Merci de votre aide ! :D
salut,
moi en lisant ça j'aurais plutot tendance à me pencher sur le code pour essayer de l'optimiser (algorithmiquement) plutot que de vouloir compresser la mémoireCitation:
Envoyé par RedArrrow
d'ailleurs au mieux ce sont les données qu'on compresse, pas la mémoire, et si ce sont des données utiles au programme ça veut dire que la compression/décompression plus ou moins régulière va engendrer un coût en terme de charge CPU, à voir si c'est vraiment ça qu'on te demande...
Ok alors après être allé sur plusieurs forums je me suis rendu compte que je n'avais pas été assez clair.
En fait je parle d'un programme, qui tourne sur un PIC18 implanté sur une carte électronique.
Le programme est directement chargé depuis MPLAB via usb sur le PIC (donc pas accès à un exe), et occupe 98% de la mémoire du PIC.
Ma tâche est de réduire le code pour qu'il prenne moins de place.
On m'a déjà parlé de padding et d'allocations dynamiques.
En espérant que tu en ai encore plus à m'apprendre ! :D
désolé non :aie: (effectivement des précisions s'imposaient)Citation:
Envoyé par RedArrrow
Bon tant pis, merci quand même !
Pour les nouveaux arrivant, je reste ouvert à toute proposition ! :D
Regarde dans le forum developpement systeme, il y a une section micro controleurs.
Vérifie déjà que tu compiles le programme en optimisation pour l'espace.
Dans tous les cas, améliorer les algorithmes du code devrait permettre de réduire le programme.
Ok merci je vais aller faire un tour sur cette section.
Je n'ai pas d'option particulière de compilateur.
Oui j'ai l'impression que c'est la seule solution ...
BonjourCitation:
Envoyé par RedArrrow
Il n'y a pas de méthode miracle pour réduire un code. C'est un truc qu'on fait au cas par cas. D'autant plus que maintenant les compilateurs savent optimiser pas mal de truc.
L'allocation dynamique éventuellement. Effectivement si le programmeur précédent a défini un tableau de 100000 items (pour être sûr que tout rentre) et qu'il n'est rempli qu'au tiers, alors ça peut-être intéressant de n'allouer que 40000. Mais dans ce cas, c'est à toi de gérer l'allocation/reallocation du tableau lors du remplissage ce qui impose alors un travail rigoureux.Citation:
Envoyé par RedArrrow
Le padding c'est essayer d'aligner une structure sur une valeur précise (généralement puissance de 2) afin que le déplacement entre différentes variables de cette structure soit plus rapide. C'est surtout utile quand on a des tableaux de structures. Ca optimise l'accès à tab[i]. Mais est-ce que les compilos ne le font pas déjà tout seul...?
T'es en train de me dire que je vais devoir annoncer à mon maître de stage que je ne lui ai fais gagner qu'un pourcent ? :ptdr:Citation:
D'autant plus que maintenant les compilateurs savent optimiser pas mal de truc.
Bon ben je vais devoir me concentrer sur le padding et l'allocation dynamique si j'ai bien compris.
Merci pour ta réponse !
Tu vas devoir comprendre ce qui prend de la place.
Et c'est ca qu'il faudra optimiser.
Avec un debugger, tu pourrais avoir des informations.
Bon courage!
Aller va pour le debugger !
J'ai trouvé quelques pistes de mon côté !
En ouvrant par curiosité les fichiers du dossier de mon projet, je suis tombé sur plusieurs fichiers intéressant.
Tout d'abord un fichier nommémain.LST: il y a écrit en en-têteROM used : 15106 bytes (92%), Largest free fragment is 1274. Le 1274 signifie qu'il y a un "trou" de 1274 bits en plein milieu ?? (donc possibilité de gagner de la place je présume)
Ensuite, j'ai ouvert le fichier main.sta : je vous montre pour une meilleure compréhension : main.sta . Ici on voit clairement que le main.c occupe 54% de la ROM, MATH.H 9%, stdlib.h 14% et string.h 4%. Déjà la somme ne fait que 81%, donc on a 11% qui disparaisse je ne sais où. Première idée que j'ai, tout simplement commenter les fonctions non utilisées des bibliothèques math, stdlib et string. Je pense qu'il y a moyen de gagner 4-5%. Si vous reprenez l'image juste au-dessus, il y a un tableau avec les colonnes Page, ROM, %, RAM et Functions. Quelqu'un saurait m'expliquer comment le déchiffrer, car je ne sais pas de quel pourcentage on parle.
Finalement j'ai ouvert le fichier main.tre : pour une meilleure compréhension : main.tre . J'ai un doute quand à son rôle, j'ai l'impression qu'on a ici l'utilisation de la RAM par chaque fonction (ce qui m'intéresse pour la suite), mais si l'on prend l'exemple de la fonction Read_EEPROM, je ne saisis pas la signification du 0/152. J'imagine que le Ram=9 veut dire 9 octets stockés sur la RAM ?
L'idée sur laquelle je pars du coup c'est essayer de gagner de la place sur les fonctions non utilisées des librairies, et ensuite tester la mémoire occupée par chaque fonction du main, et tester des modifications pour voir si je peux en gagner un peu plus.
J'attends vos réponses pour savoir si c'est viable comme solution, merci ! :D
C'est un travail très délicat quand on ne connait pas l'application actuelle. Il va déjà falloir que tu commences par bien la comprendre.
Si cette application a été codée avec les pieds, tu pourras gagner de la place. Sinon, tu ne gagneras sans doute pas grand chose, mais on est toujours à la recherche de quelques centaines de bytes sur PIC.
Il faut déjà que tu comprennes bien le terme mémoire : quand tu parles de 98 %, je présume que tu parles de la flash (ou ROM) et non de la RAM. Ainsi, l'allocation dynamique (qui sans doute interdite sur un PIC par le compilateur ou par les règles de codage de l'entreprise) n'y est pour rien, car elle utilise de la RAM et non de la ROM.
Ton compilateur a forcément des options, et souvent les compilateurs une option pour optimiser en taille (-Os avec gcc par exemple).
Si la flashes est pleine, il faut que tu factorises un maximum de code dans des fonctions. Il existe des outils pour analyser du code source et t'indiquer le pourcentage de duplication de code. Le code dupliqué, c'est du code qui pourrait être dans une seule fonction qu'on appelle depuis plusieurs autres endroits.
Bon courage.
Merci Bktero pour ta réponse ! :D
Ok je corrige la faute que j'ai faite au début du poste, la mémoire est remplis à 92% mais ce n'est qu'un détail.
Effectivement je parle bien de la ROM et non pas de la RAM.
--> pourquoi cela ?Citation:
l'allocation dynamique (qui sans doute interdite sur un PIC par le compilateur ou par les règles de codage de l'entreprise
Ben justement, si j'arrive trouver des variables déclarées en générales, alors qu'elles ne sont utilisées qu'une seule fois, pourquoi ne pas les stocker dans la RAM et les effacer ensuite ?
--> j'ai 2 logiciels : MPLAB, et l'autre qui s'appelle PIC C Compiler. Quand je compile sous MPLAB je n'ai pas besoin d'ouvrir PIC C Compiler, mais du coup j'imagine que si je veux paramétrer mon compiler faut que j'aille dans PIC C Compiler ? Parce que je l'ai survolé rapidement et j'ai rien vu qui m'intéressait. Après j'ai certainement râté des infos que je n'ai pas saisis.Citation:
Ton compilateur a forcément des options, et souvent les compilateurs une option pour optimiser en taille (-Os avec gcc par exemple)
--> t'as un exemple d'outil ?Citation:
Il existe des outils pour analyser du code source et t'indiquer le pourcentage de duplication de code.
J'avais oublié de relever ça :
Ne modifie pas ces fichiers ! Ils sont la "propriété" du compilo et un vrai compilateur est évidemment capable de ne pas embarquer les fonctions que tu n'utilises pas.Citation:
Première idée que j'ai, tout simplement commenter les fonctions non utilisées des bibliothèques math, stdlib et string.
En général, on évite l'allocation dynamique sur de l'embarqué enfoui, car il est difficile de savoir si un jour on ne va pas être à court de mémoire et faire planter le système.Citation:
--> pourquoi cela ?
Ben justement, si j'arrive trouver des variables déclarées en générales, alors qu'elles ne sont utilisées qu'une seule fois, pourquoi ne pas les stocker dans la RAM et les effacer ensuite ?
Une variable est presque toujours en RAM. Il n'y a que les constantes qui peuvent se retrouver en flash. Probablement peu de gain par là, sauf à les rendre non constantes ce qui n'est pas une excellent idée.
Il faut vraiment tu saches quel compilateur est utilisé. Ton maitre de stage devrait être capable de répondre à cette question. Quand vient le moment d'optimiser, on s'appuie aussi sur ses capacités et ses options.Citation:
--> j'ai 2 logiciels : MPLAB, et l'autre qui s'appelle PIC C Compiler. Quand je compile sous MPLAB je n'ai pas besoin d'ouvrir PIC C Compiler, mais du coup j'imagine que si je veux paramétrer mon compiler faut que j'aille dans PIC C Compiler ? Parce que je l'ai survolé rapidement et j'ai rien vu qui m'intéressait. Après j'ai certainement râté des infos que je n'ai pas saisis.
En Java, j'utilise SonarQube. On peut l'utiliser avec d'autres langages. Tu peux chercher d'autres outils qui détectent la duplication de code sur internet.Citation:
--> t'as un exemple d'outil ?
:salut:
Pour avoir dû les tester, je ne dirais pas que les compilateurs Microchip gratuits sont exceptionnels… La version pro effectue énormément d'optimisations (à peu près zéro en gratuit), notamment pour gagner de la place, c'est d'ailleurs pour ça qu'elle est payante (~ 500 - 1000 € la licence). Maintenant, ça m'étonnerait qu'il existe des tonnes d'autres compilateurs que XC8.
Sur les bibliothèques standard : bien évidemment, le compilateur n'inclut pas le code de toutes les fonctions. Maintenant, tu peux envisager de réimplémenter certaines fonctions qui prennent trop de place. Exemple : si tu utilises un sinus codé avec une LUT de très grande taille sans avoir besoin d'une grande précision, tu peux recoder le tout avec un polynôme de Taylor (par exemple, voir musl : http://git.musl-libc.org/cgit/musl/tree/src/math/sin.c, http://git.musl-libc.org/cgit/musl/t...c/math/__sin.c ; à comparer avec la glibc, absolument pas prévue pour de l'embarqué : https://sourceware.org/git/?p=glibc....4/s_sin.c#l283).
Maintenant, il y a sûrement de meilleures sources d'optimisation que la bibliothèque standard, à voir selon ton cas.
Solution trouvée !
Tout simplement en lisant la datasheet du compilateur, j'ai trouvée une option, #OPT n
avec n allant de 1 à 11 et qui permet de choisir le niveau d'optimisation du code !
J'ai pu donc passer de 92% à 71% !
Merci à tous !
Je dis souvent que quand vient le temps de l'optimisation, vient avec lui le temps du travail du compilateur :roll:
Penses à revalider ton logiciel : avec un haut niveau d'optimisation, tu n'as pas forcément le même comportement. Il peut déjà y avoir des erreurs du compilateur qui "optimise trop" et ne respecte plus tout à fait ton code. Il peut y avoir des timings différents, un exemple classique étant les délais faits avec des boucles (ce qui est souvent une idée "moyenne" car peu portable et justement souvent dépendantes des optimisations si la réalisation est mauvaise).