Avec des pages standards de 4k:
25000*4k = 100 megas virtuels, à ne pas confondre avec 100 megas réeels !!!
C'est genial ca.
200'000 allocations de 32 bytes(qui apres tout n'est pas enorme) ca fait 800Mo virtuel et 200'000 handles, sachant qu'un process a un espace d'addresse de 3Go sur Linux x86 dont une partie deja est prise par les librairies utilisees par le soft, je t'explique pas comment ca va etre marrant de faire rentrer ca dans l'espace d'addressage sans parler des 200'000 handles.
Avec les threads, 200'000 allocations de 32 bytes ca fait 6.4 Mo et 0 handles....
Serieusement, t'as deja programme avec les shm ? On dirait pas.
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.
1) Le jour ou tu me feras un malloc pour shm plus rapide dans les cas habituels que le malloc de la glibc tu m'appelles et je t'offres une Ferrari, ok ?
2) Liberer une zone utilisee par un autre process avec les shm c'est dangereux aussi comme je te l'ai montre plus haut
La seule raison valable d'utiliser les threads, génératrices de nombreux bugs silencieux, est les performances.
Non, c'est aussi le fait qu'il est 10x plus simple d'ecrire un soft multithread qu'un soft avec segments partages.
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).
Certains softs oui, mais c'est loin d'etre la plupart.
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.
La glibc 2.3 utilises des spinlocks pour locker malloc, resultat tu ne peux pas adapter ca a un environnement multiprocess facilement vu que les spinlock devront etre modifies pour etre sur un segment partage eux aussi, et inutile de te dire que c'est un bordel a adapter vu que cela doit etre fait avant la moindre allocation dans ton soft...
Je te le dis et redis, essaies toi meme, essaie d'ecrire un soft un tant soit peu consequent et complexe de cette maniere et tu verras par toi meme, c'est tout simplement pas viable et maintenable.
J'ai vraiment l'impression que tu n'as jamais essaye d'utiliser serieusement les shm vu tes arguments.
[^] # Re: le meilleur compromis performances vs sécurité
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 1.
25000*4k = 100 megas virtuels, à ne pas confondre avec 100 megas réeels !!!
C'est genial ca.
200'000 allocations de 32 bytes(qui apres tout n'est pas enorme) ca fait 800Mo virtuel et 200'000 handles, sachant qu'un process a un espace d'addresse de 3Go sur Linux x86 dont une partie deja est prise par les librairies utilisees par le soft, je t'explique pas comment ca va etre marrant de faire rentrer ca dans l'espace d'addressage sans parler des 200'000 handles.
Avec les threads, 200'000 allocations de 32 bytes ca fait 6.4 Mo et 0 handles....
Serieusement, t'as deja programme avec les shm ? On dirait pas.
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.
1) Le jour ou tu me feras un malloc pour shm plus rapide dans les cas habituels que le malloc de la glibc tu m'appelles et je t'offres une Ferrari, ok ?
2) Liberer une zone utilisee par un autre process avec les shm c'est dangereux aussi comme je te l'ai montre plus haut
La seule raison valable d'utiliser les threads, génératrices de nombreux bugs silencieux, est les performances.
Non, c'est aussi le fait qu'il est 10x plus simple d'ecrire un soft multithread qu'un soft avec segments partages.
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).
Certains softs oui, mais c'est loin d'etre la plupart.
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.
Et non c'est pas aussi simple : http://sources.redhat.com/ml/libc-alpha/2002-02/msg00108.html(...)
La glibc 2.3 utilises des spinlocks pour locker malloc, resultat tu ne peux pas adapter ca a un environnement multiprocess facilement vu que les spinlock devront etre modifies pour etre sur un segment partage eux aussi, et inutile de te dire que c'est un bordel a adapter vu que cela doit etre fait avant la moindre allocation dans ton soft...
Je te le dis et redis, essaies toi meme, essaie d'ecrire un soft un tant soit peu consequent et complexe de cette maniere et tu verras par toi meme, c'est tout simplement pas viable et maintenable.
J'ai vraiment l'impression que tu n'as jamais essaye d'utiliser serieusement les shm vu tes arguments.