Forum de Ti-Gen.org, le site francophone des TI

Bienvenue Invité ! Se connecter Mes sujets	Administrer
Utilisateurs actifs : Aucun membre + 1 visiteur

Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.

:: Index » Forum Ti68K » Programmation C » Méthode de gestion des mallocs (32 réponse(s))

./REPRISE DU POST PRECEDENT (post n°19) Marquer comme non lu.

LionelA

Ecrit le: Vendredi 15 juillet 2005 à 14:50

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 947

Membre n°206

Inscrit le 19 avril 2004

non non

En fait c'est pour detecter le nombre de handles non libérés a l'interieur du programme durant la phase de developpement.
En fait quand le main quitte on peut vouloir que ca soit normal que le Exit libere un certain nombre de handles qui sont utilisés tout au long du prog (ca evite de mettre du code pour liberer ces handles) et donc il ne faut pas qu'ils soient detectés parmi les handles anormalement non libérés.

Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/

./Post n°20 Marquer comme non lu.

Link

Ecrit le: Vendredi 15 juillet 2005 à 15:52

Membre: Magister

Messages: 302

Membre n°896

Inscrit le 25 juin 2005

Donc, ces NB_EXIT_HANDLES, c'est choisi par celui qui utilise la lib, non?
Parce qu'ils ne correspondent à aucune table...
L'utilisateur devrait donc définir NB_EXIT_HANDLES à une valeur qu'il aura trouvée en programmant, et la lib le préviendrait si à la fin il reste plus de handles non-libérés que la constante...

Mais si tu en libères un accidentellement et que tu oublies un leak, ce ne sera pas signalé, puisque les "exit handles" ne sont pas répertoriés... (ça pourrait être une bonne idée de les stocker dans une table à part ou de les marquer comme "exit handles" dans une table de flags?

./Post n°21 Marquer comme non lu.

LionelA

Ecrit le: Vendredi 15 juillet 2005 à 16:07

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 947

Membre n°206

Inscrit le 19 avril 2004

Oui en effet, mais pour liberer accidentellement faut le faire

Je pourrais faire une table des exit handles mais il faudrait rajouter une fonction pour les marquer, fonction qui n'existerai plus en mode "release" (i.e. DEV_PHASE == 0)
(Les valeurs qui sont données dans l'exemple sont celles de F-Zero et elle n'ont rien à voir avec cet exemple au fait)
Et c'est le programmeur qui determine toutes ces valeurs :
Pour F-zero j'ai 7 allocations permanentes :
- une par fichier ouvert (avec une fonction perso), 4 fichiers -> 4 handles
- une pour le Double Buffering de tigcc
- 2 pour les tables de mode7
J'ai donc mis NB_EXIT_HANDLES à 7 pour pas que ca me signale quand le prog les libere en fin de main.
Les autres constantes sont a ajuster aussi en fonction du nombre d'AI redirigées ou du nombre max de handle utilisés (et oui je redirige 5 AI en meme temps et j'ai un max de 27 handles a la fois)

./Post n°22 Marquer comme non lu.

Lionel Debroux

Ecrit le: Samedi 16 juillet 2005 à 11:37

Envoyer un message privé à Lionel Debroux

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

> - une par fichier ouvert (avec une fonction perso), 4 fichiers -> 4 handles
> - une pour le Double Buffering de tigcc
Est-ce que ça ne pourrait pas être dans le même handle ?

Sur les programmes qui allouent beaucoup de handles petits, il est souvent très avantageux de regrouper toutes les allocations. Voir les readme de Ice Hockey 68k, TI-Chess, Pepzip...
Le problème de la fragmentation de la mémoire qui permettrait d'allouer plus de blocs plus petits mais pas moins de blocs plus gros est théorique.
Partant du principe de sage utilisation qui est qu'il faut toujours archiver autant de trucs que possible (de toute façon, si on ne le fait pas, beaucoup de programmes refusent de fonctionner), qui a déjà vu une série de blocs lockés disséminés dans toute la mémoire de sorte que la taille du plus gros handle utilisable soit inférieure à 20 KB ?

Lionel Debroux - membre de TICT.

./Post n°23 Marquer comme non lu.

Link

Ecrit le: Samedi 16 juillet 2005 à 11:51

Membre: Magister

Messages: 302

Membre n°896

Inscrit le 25 juin 2005

Ben, je ne crois pas qu'on puisse regrouper plus: Il faut nécessairement un handle par fichier... (sauf s'il y a des buffers évidemment, là, il devrait être possible de regrouper lesdits buffers...

./Post n°24 Marquer comme non lu.

LionelA

Ecrit le: Samedi 16 juillet 2005 à 14:34

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 947

Membre n°206

Inscrit le 19 avril 2004

ben en fait j'ai une fonction perso qui marche a la maniere de fopen (enfin j'imagine car je n'ai pas regardé le source de fopen mais bon) et qui donc alloue un bloc pour y stocker ma structure equivalente a FILE.
Je sais que ca serait mieux de faire qu'une seule allocation mais quand j'ai commencé le dev de F-Zero je n'avais jamais programmé serieusement sur TI (ni sur embarqué) donc j'ai appliqué les techniques d'allocation vu en cours (et les mallocs ca y va, c'est gratuit) donc voila.
Enfin vu que les 4 blocs sont alloués à la suite (dans le code) ils devraient pas etre trop eloignés les uns des autres dans la RAM, et donc ca ne doit pas trop fragmenter. Ca revient donc au même que si ils etaient alloués en une seule fois mis à part que j'utilise 4 fois plus de HANDLE (mais y'en a 2000 de dispo, c'est pas un drame).

./Post n°25 Marquer comme non lu.

Folco

Ecrit le: Samedi 16 juillet 2005 à 15:08

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Tu devrais essayer de regrouper, j'ai gagné pas mal de place en le faisant (et en passant par une section BSS également, ça évite des allocations/vérifications/exit/désallocation à la main).

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°26 Marquer comme non lu.

LionelA

Ecrit le: Samedi 16 juillet 2005 à 15:15

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 947

Membre n°206

Inscrit le 19 avril 2004

Vu comment c'est codé avec les pieds je prefere laisser comme c'est sinon ca remet trop de code en cause.
Et puis je n'ai que allocation a faire car verification/desaloc/exit se fait automatiquement avec le manager de memoire etc..
Et enfin j'ai besoin a un endroit du code de faire beaucoup de petits malloc pour le calcul de placement de waypoints sur la piste (avec orientation des portions de la route et tout) donc voila

-Edité le Samedi 16 juillet 2005 à 15:15 par LionelA-

./Post n°27 Marquer comme non lu.

Folco

Ecrit le: Samedi 16 juillet 2005 à 15:41

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

tous tes petits malloc pourraient se réduire à un gros si tu regardes avant la place dont tu dois disposer non?

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°28 Marquer comme non lu.

LionelA

Ecrit le: Samedi 16 juillet 2005 à 15:49

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 947

Membre n°206

Inscrit le 19 avril 2004

non, je ne connais pas a l'avance l'agencement des map : nombre de croisements etc... je me suis tellement arraché de cheveux en faisant cet algo que j'y toucherai plus jamais je pense

./Post n°29 Marquer comme non lu.

Folco

Ecrit le: Samedi 16 juillet 2005 à 16:33

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

oui, je me souviens des topics là-dessus

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°30 Marquer comme non lu.

Kevin Kofler

Ecrit le: Samedi 16 juillet 2005 à 16:47

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

LionelA :
non, je ne connais pas a l'avance l'agencement des map : nombre de croisements etc... je me suis tellement arraché de cheveux en faisant cet algo que j'y toucherai plus jamais je pense

Tu peux toujours connaître en faisant 2 passes, une pour calculer la mémoire nécessaire (ou une bonne borne supérieure pour la mémoire nécessaire) et une pour faire les vrais calculs. Les routines d'exportation de ld-tigcc fonctionnent comme ça, par exemple: on fait une fois le tour de toutes les structures de données à exporter pour calculer la taille (et elle doit être précise à l'octet, une borne supérieure ne suffit même pas dans ce cas) et une deuxième fois pour exporter vraiment. Les versions récentes de AutoClBr fonctionnent comme ça aussi.

Une autre solution est de faire des réallocations au fur et à mesure. Les premières versions de AutoClBr faisaient ça (une réallocation de la ligne d'entrée pour chaque parenthèse rajoutée).
-Edité le Samedi 16 juillet 2005 à 16:48 par Kevin Kofler-

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!

./Post n°31 Marquer comme non lu.

LionelA

Ecrit le: Samedi 16 juillet 2005 à 16:55

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 947

Membre n°206

Inscrit le 19 avril 2004

y'a moyen de faire ca en effet mais ca prendrait 2x plus de temps (meme si je sais que c'est pas les "loading..." pendant 10s qui te font peur

) Je ne crois pas que le gain en taille du programme (ou d'ailleurs perte) en vaille la peine par rapport a une utilisation abusive d'allocations. (Et puis j'ai vraiment plus envie de toucher à cette partie que j'ai testé a mort et qui ne doit plus contenir de bugs)

./Post n°32 Marquer comme non lu.

Lionel Debroux

Ecrit le: Dimanche 17 juillet 2005 à 09:34

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

> Tu devrais essayer de regrouper, j'ai gagné pas mal de place en le faisant
C'est évident.
> (et en passant par une section BSS également,
C'est beaucoup plus rare. Kevin cite toujours CC comme étant amélioré en taille par l'utilisation de BSS, ce qui veut surtout dire que CC est codé avec les pieds: il y a des blocs de mémoire assez gros, qui devraient plutôt être gérés à la main.
Il y a au moins 1 KB de BSS dans TI-Chess (au moins 600 octets si je me souviens bien dans opening.c que j'ai modifié récemment, et il y en a ailleurs), et pourtant, le programme se porte mieux après passage à -mno-bss: taille décompressée peu changée, taille compressée réduite...
> ça évite des allocations/vérifications/exit/désallocation à la main).
Mais (en AMS native) nécessite tout un stub de démarrage pour remplir les références xxx.l relogées (au lieu des d(pc) / d(an) utilisables en -mno-bss)...

GCC ne le faisant pas tout seul, il est souvent très intéressant d'utiliser des pointeurs auxiliaires. Sur TI-Chess, opening.c, j'ai gagné plus de 100 octets (l'ancienne version est commentée).

Lionel Debroux - membre de TICT.