Oui bien sur, va allouer 25'000 shm, tu vas voir l'occupation en RAM apres..
Avec des pages standards de 4k:
25000*4k = 100 megas virtuels, à ne pas confondre avec 100 megas réeels !!!
Dans le cas des threads, malloc est mauvais pour les performances et la sécurité/fiabilité:
1. Performances: consommation de CPU et de mémoire supplémentaire. Mutex obligatoire.
2. Sécurité/fiabilité: libérer une zone utilisée par les autres threads peut produire des bugs silencieux.
La seule raison valable d'utiliser les threads, génératrices de nombreux bugs silencieux, est les performances.
Or malloc impacte fortement les performances.
Beaucoup d'applications perfermantes sont obligées de gérer elle-meme leur allocations ou d'utilisent une bibliothèque d'allocation plus rapide (quitte à consommer un peu + de mémoire).
Et tu es de mauvaise fois sur les équivalents de malloc pour shm. Les bibliothèques d'allocation sont vieilles comme l'informatique et sont très bien éprouvées. Et encore une fois, les malloc standards peuvent fonctionner avec n'importe quelle zone mémoire sans le modifier: il suffit de les compiler avec un brk qui utilise shm au lieu d'utiliser le brk habituel.
[^] # 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.
Avec des pages standards de 4k:
25000*4k = 100 megas virtuels, à ne pas confondre avec 100 megas réeels !!!
Dans le cas des threads, malloc est mauvais pour les performances et la sécurité/fiabilité:
1. Performances: consommation de CPU et de mémoire supplémentaire. Mutex obligatoire.
2. Sécurité/fiabilité: libérer une zone utilisée par les autres threads peut produire des bugs silencieux.
La seule raison valable d'utiliser les threads, génératrices de nombreux bugs silencieux, est les performances.
Or malloc impacte fortement les performances.
Beaucoup d'applications perfermantes sont obligées de gérer elle-meme leur allocations ou d'utilisent une bibliothèque d'allocation plus rapide (quitte à consommer un peu + de mémoire).
Et tu es de mauvaise fois sur les équivalents de malloc pour shm. Les bibliothèques d'allocation sont vieilles comme l'informatique et sont très bien éprouvées. Et encore une fois, les malloc standards peuvent fonctionner avec n'importe quelle zone mémoire sans le modifier: il suffit de les compiler avec un brk qui utilise shm au lieu d'utiliser le brk habituel.