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

[David Decotigny]

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/