[SOS] Allocation Memoire Physique & Macro (List.h)

[Romain LABBE]

Saut David,

Merci pour ces précisions,

*Je ne savais pas que: condition ? True : False; etait du C pûr !

*Parfaite l'explication sur l'odre des pages et l'optimisation.

A++

Romain

> -----Message d'origine-----
> De : sos-bounces at the-doors.enix.org 
> [mailto:sos-bounces at the-doors.enix.org] De la part de David Decotigny
> Envoyé : dimanche 27 novembre 2005 12:53
> À : SOS mailing-list
> Objet : Re: RE : [SOS] Allocation Memoire Physique & Macro (List.h)
> 
> 
> 
> Bonjour,
> 
> Je vais essayer de rattraper plus d'un mois de retard, pas 
> facile. Par avance desole si je repete des choses qui ont ete 
> dites 3 semaines plus tard par quelqu'un d'autre.
> 
> romain wrote:
> > Question 1:
> > -----------
> > 
> > b = (a > 2) ? 1 : 0;
> > Ok on peut donc écrire cette sorte de syntaxe alors:  condition ? 
> > Retour si vérifié : Retour si non-vérifié; Merci c'est l'impide 
> > désormais !
> 
> Oui, pour detailler : romain pensait que cette syntaxe avait 
> a voir avec les macros. Non, cette syntaxe 
> (condition)?valeur_alors:valeur_sinon
> n'est pas purement "macro", c'est du C tout ce qu'il y a de 
> plus normal. Comme tout ce qui est "C", c'est un peu crade et 
> c'est facile de faire des erreurs avec. Donc a utiliser avec 
> precaution.
> 
> > Question 2:
> > -----------
> > 
> > -Les pages plus neuves ou dernierement libérées en début de queue 
> > libre -Les pages dernieremet alouées en  fin queue utilisé
> 
> Tout a fait. C'est volontaire si on alloue a partir de la 
> tete et si on libere vers la tete de la liste (ou l'inverse, 
> on me corrigera) : comme ca, on reutilise ce qu'on a le plus 
> recemment libéré. On espere que ce comportement va etre bon 
> vis a vis des caches : on a de bonnes chances ainsi d'acceder 
> a des donnees qui ont deja une place au chaud dans les 
> differents caches memoires. En effet, certaines politiques de 
> remplacement de cache sont de type "LRU" ("Least Recently 
> Used"). Dans ces politiques, les elements qui sont vires du 
> cache en cas de besoin sont ceux qui sont les moins recemment 
> utilises. Cette politique est la plus couramment implantee 
> dans les caches associatifs ou associatifs par ensemble, 
> l'architecture Intel en utilise quelques uns.
> 
> Vous aurez remarque que j'ecris "on espere". Tout simplement 
> parce que tout ce qui releve de l'optimisation est pur pari : 
> de temps en temps ca sera efficace, de temps en temps ca ne 
> le sera pas. Tout ça parce qu'on ne possede pas la faculte de 
> clairvoyance : l'optimisation "optimale" reviendrait en effet 
> a prevoir l'avenir ("clairvoyance" en algo) et a prendre la 
> meilleure decision sur la base de cette connaissance. Ne 
> connaissant que le passe, tout ce qu'on peut faire est 
> prendre les meilleurs paris sur ce qui va se passer en 
> fonction de ce qui s'est deja passe. L'art de l'optimisation 
> revient ensuite a faire un compromis entre la justesse du 
> pari et l'effort consenti (ici en terme de complexite des 
> algos, en electronique on s'interesserait plutot a une 
> surface de silicium necessaire).
> 
> Tout ca pour dire que cette cuisine est volontaire et, la ou 
> c'est pas trop complique, on essaiera de reflechir 2 secondes 
> avant de pondre le code : en l'occurence, je me suis juste 
> pose la question "en tete en ou en queue ?". La reflexion 
> n'est pas compliquee, le code ne l'est pas davantage, donc 
> c'est tout benef. Apres, est-ce que ca se comportera mieux 
> ?... "on espere" que ca ne contrariera pas trop les caches, 
> que ça ira meme dans leur sens, c'est tout.
> 
> Mais ne soyons pas pretentieux : de toute facon on ne gagnera 
> que quelques nanosecondes sachant que le code de sos est un 
> ramassis de choses pas optimisees DU TOUT. Bref, c'est un peu 
> comme optimiser 2+2 avant de factoriser un nombre a 65445465 
> decimales. Donc, faut bien reconnaitre, ce genre 
> d'optimisation est /vraiment/ anecdotique. Parce que nous 
> avons privilegie la clarte du code, n'utilisant quelques 
> optimisations simples que la ou le code ne s'en trouvait 
> pas/peu changé, en etant convaincu que ca n'apportera rien 
> dans le cas de sos.
> 
> Souvent, l'optimisation DOIT se jouer sur des considerations 
> de structures de donnees avant de se jouer sur des 
> considerations de cache: utilise-t'on les meilleures 
> structures de donnees pour les algos qu'on veut derouler ? Et 
> là, dans bien des cas nous n'utilisons pas les meilleures 
> solutions dans SOS (en toute conscience). Par exemple, nous 
> classons les plages d'adresses virtuelles des processus dans 
> des listes chainees. C'est une heresie : l'insertion et la 
> recherche d'une region virtuelle dans une telle liste seront 
> largement sous-optimales : si on double le nombre de regions 
> virtuelles, on double le temps pris par ces operations. Il 
> suffit de savoir qu'il existe des algos qui ne feraient 
> qu'ajouter un petit laps de temps supplementaire pour se 
> rendre compte qu'une optimisation de cache n'a alors 
> absolument plus aucun sens... on va gagner des nanosecondes a 
> certains endroits sachant qu'a d'autres on va perdre des 
> microsecondes (ou des millisecondes). Dans SOS, il a fallu 
> faire ce compromis : optimiser la ou ca mange pas de pain (ie 
> ca ne se voit pas de trop), faire clair plutot qu'optimiser 
> la ou ca aurait compliqué inutilement la lecture du code. Le 
> principal est d'en avoir conscience.
> 
> Bonne journee,
> 
> -- 
> http://david.decotigny.free.fr/ 
> _______________________________________________
> Sos mailing list
> Sos at the-doors.enix.org 
> http://the-doors.enix.org/cgi-> bin/mailman/listinfo/sos
>