Par exemple, je sais que mon prog en charge pleine bouffe 200Mo. Donc je fais dans mon thread un malloc de 200Mo d'entrée de jeu (et même le plus souvent un calloc par choix perso) et après je gère ma mémoire en interne sans refaire le moindre malloc ni le moindre appel a des signaux systèmes. J'ai fait un malloc et je distribue ensuite au threads qui ont en besoins ce qu'ils me demandent quand ils le demandent. Niveau vitesse je gagne en perf un maximum.
Il faut que tu expliques ça à pbpg ! Car son principal argument contre shm c'est qu'on peut pas utiliser le malloc standard :) Je suis entierement d'accord que c'est la méthode la plus rapide, et tu peux aussi gérer toi-même de très gros segments partagés avec shm sans avoir besoin de passer par un équivalent de malloc !
Quand je sous alloue d'un process vers un de ses threads je fais exactement 0 appels systèmes
Quand je sous-alloue à l'intérieur d'un gros shm, 0 appels systemes.
Quand je lock un segment via un thread encore 0 appels.
Alors tu utilises forcément un spinlock, bien que tu ne les aimes pas d'après un de tes messages un peu plus haut. Sache que le principe des spinlocks fonctionne exactement pareil dans un shm. Aucune différence.
Encore une fois, en regardant les page tables du systèmes, il est facile de voir que des process communiquants avec de gros shm, et des threads communiquant avec de gros mallocs, c'est exactement pareil.
Sauf que les process ont le droit d'avoir des variables strictement privées !
[^] # Re: le meilleur compromis performances vs sécurité
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Il faut que tu expliques ça à pbpg ! Car son principal argument contre shm c'est qu'on peut pas utiliser le malloc standard :) Je suis entierement d'accord que c'est la méthode la plus rapide, et tu peux aussi gérer toi-même de très gros segments partagés avec shm sans avoir besoin de passer par un équivalent de malloc !
Quand je sous alloue d'un process vers un de ses threads je fais exactement 0 appels systèmes
Quand je sous-alloue à l'intérieur d'un gros shm, 0 appels systemes.
Quand je lock un segment via un thread encore 0 appels.
Alors tu utilises forcément un spinlock, bien que tu ne les aimes pas d'après un de tes messages un peu plus haut. Sache que le principe des spinlocks fonctionne exactement pareil dans un shm. Aucune différence.
Encore une fois, en regardant les page tables du systèmes, il est facile de voir que des process communiquants avec de gros shm, et des threads communiquant avec de gros mallocs, c'est exactement pareil.
Sauf que les process ont le droit d'avoir des variables strictement privées !