Le Wed, 22 Dec 2010 13:11:56 +0000 (UTC),
Michel Talon écrivait :
> Toxico Nimbus wrote:
>> Michel Talon a écrit :
>>
>> En fait on se porte aussi bien d' utiliser un seul programme
>> > multithreadé.
>>
>> Et avec quoi tu synchronise tes threads ? Au hasard, des sémaphores
>> anonymes ?..
>>
>
> Au hasard des mutex, des variables de condition, etc.
Avec deux threads, ça peut encore passer. Mais lorsque tu as
plusieurs centaines de threads de calculs, il faut quelque chose de
plus subtil que des mutexes sous peine de sous utilisation de tes
processeurs.
JKB
Le Wed, 22 Dec 2010 13:11:56 +0000 (UTC),
Michel Talon <talon@lpthe.jussieu.fr> écrivait :
> Toxico Nimbus <ToxN@free.fr> wrote:
>> Michel Talon a écrit :
>>
>> En fait on se porte aussi bien d' utiliser un seul programme
>> > multithreadé.
>>
>> Et avec quoi tu synchronise tes threads ? Au hasard, des sémaphores
>> anonymes ?..
>>
>
> Au hasard des mutex, des variables de condition, etc.
Avec deux threads, ça peut encore passer. Mais lorsque tu as
plusieurs centaines de threads de calculs, il faut quelque chose de
plus subtil que des mutexes sous peine de sous utilisation de tes
processeurs.
JKB
Le Wed, 22 Dec 2010 13:11:56 +0000 (UTC),
Michel Talon écrivait :
> Toxico Nimbus wrote:
>> Michel Talon a écrit :
>>
>> En fait on se porte aussi bien d' utiliser un seul programme
>> > multithreadé.
>>
>> Et avec quoi tu synchronise tes threads ? Au hasard, des sémaphores
>> anonymes ?..
>>
>
> Au hasard des mutex, des variables de condition, etc.
Avec deux threads, ça peut encore passer. Mais lorsque tu as
plusieurs centaines de threads de calculs, il faut quelque chose de
plus subtil que des mutexes sous peine de sous utilisation de tes
processeurs.
JKB
JKB wrote:Le Wed, 22 Dec 2010 13:11:56 +0000 (UTC),
Michel Talon écrivait :
> Toxico Nimbus wrote:
>> Michel Talon a écrit :
>>
>> En fait on se porte aussi bien d' utiliser un seul programme
>> > multithreadé.
>>
>> Et avec quoi tu synchronise tes threads ? Au hasard, des sémaphores
>> anonymes ?..
>>
>
> Au hasard des mutex, des variables de condition, etc.
Avec deux threads, ça peut encore passer. Mais lorsque tu as
plusieurs centaines de threads de calculs, il faut quelque chose de
plus subtil que des mutexes sous peine de sous utilisation de tes
processeurs.
Mais qu'est-ce que tu racontes? Qu'une région de mémoire soit protégée
par un sémaphore ou un mutex quelle différence ça fait dans l'efficacité
de la gestion?
En quoi le fait qu'il y ait une centaine de threads
peut-il conduire à la sous utilisation d'au plus une huitaine de
processeurs?
Ca peut conduire à beaucoup de temps perdu en gestion de la
synchronisation, quelle que soit la méthode utilisée. D'ailleurs je suis
à peu près certain que les sémaphores sont en fait implémentés par un
mutex et une variable de condition - en fait je viens de vérifier
dans les sources de FreeBSD, si bien que tu peux toujours et dans tous
les cas t'en passer sans encourir de perte de performance.
JKB <jkb@koenigsberg.invalid> wrote:
Le Wed, 22 Dec 2010 13:11:56 +0000 (UTC),
Michel Talon <talon@lpthe.jussieu.fr> écrivait :
> Toxico Nimbus <ToxN@free.fr> wrote:
>> Michel Talon a écrit :
>>
>> En fait on se porte aussi bien d' utiliser un seul programme
>> > multithreadé.
>>
>> Et avec quoi tu synchronise tes threads ? Au hasard, des sémaphores
>> anonymes ?..
>>
>
> Au hasard des mutex, des variables de condition, etc.
Avec deux threads, ça peut encore passer. Mais lorsque tu as
plusieurs centaines de threads de calculs, il faut quelque chose de
plus subtil que des mutexes sous peine de sous utilisation de tes
processeurs.
Mais qu'est-ce que tu racontes? Qu'une région de mémoire soit protégée
par un sémaphore ou un mutex quelle différence ça fait dans l'efficacité
de la gestion?
En quoi le fait qu'il y ait une centaine de threads
peut-il conduire à la sous utilisation d'au plus une huitaine de
processeurs?
Ca peut conduire à beaucoup de temps perdu en gestion de la
synchronisation, quelle que soit la méthode utilisée. D'ailleurs je suis
à peu près certain que les sémaphores sont en fait implémentés par un
mutex et une variable de condition - en fait je viens de vérifier
dans les sources de FreeBSD, si bien que tu peux toujours et dans tous
les cas t'en passer sans encourir de perte de performance.
JKB wrote:Le Wed, 22 Dec 2010 13:11:56 +0000 (UTC),
Michel Talon écrivait :
> Toxico Nimbus wrote:
>> Michel Talon a écrit :
>>
>> En fait on se porte aussi bien d' utiliser un seul programme
>> > multithreadé.
>>
>> Et avec quoi tu synchronise tes threads ? Au hasard, des sémaphores
>> anonymes ?..
>>
>
> Au hasard des mutex, des variables de condition, etc.
Avec deux threads, ça peut encore passer. Mais lorsque tu as
plusieurs centaines de threads de calculs, il faut quelque chose de
plus subtil que des mutexes sous peine de sous utilisation de tes
processeurs.
Mais qu'est-ce que tu racontes? Qu'une région de mémoire soit protégée
par un sémaphore ou un mutex quelle différence ça fait dans l'efficacité
de la gestion?
En quoi le fait qu'il y ait une centaine de threads
peut-il conduire à la sous utilisation d'au plus une huitaine de
processeurs?
Ca peut conduire à beaucoup de temps perdu en gestion de la
synchronisation, quelle que soit la méthode utilisée. D'ailleurs je suis
à peu près certain que les sémaphores sont en fait implémentés par un
mutex et une variable de condition - en fait je viens de vérifier
dans les sources de FreeBSD, si bien que tu peux toujours et dans tous
les cas t'en passer sans encourir de perte de performance.
>
> Je viens de vérifier, les sémaphores anonymes partagés entre plusieurs
> processus n'existent pas sous FreeBSD 8.1 il faut aller à 9-CURRENT pour
> les trouver.
Et simplement partagé en threads d'un _même_ processus ? Tous les
codes multithreadés en sont plein (et c'est dans FreeBSD au moins
depuis la version 7.0 parce que j'ai commencé à toucher à FreeBSD à
cette version et que ça fonctionnait).
>
> Je viens de vérifier, les sémaphores anonymes partagés entre plusieurs
> processus n'existent pas sous FreeBSD 8.1 il faut aller à 9-CURRENT pour
> les trouver.
Et simplement partagé en threads d'un _même_ processus ? Tous les
codes multithreadés en sont plein (et c'est dans FreeBSD au moins
depuis la version 7.0 parce que j'ai commencé à toucher à FreeBSD à
cette version et que ça fonctionnait).
>
> Je viens de vérifier, les sémaphores anonymes partagés entre plusieurs
> processus n'existent pas sous FreeBSD 8.1 il faut aller à 9-CURRENT pour
> les trouver.
Et simplement partagé en threads d'un _même_ processus ? Tous les
codes multithreadés en sont plein (et c'est dans FreeBSD au moins
depuis la version 7.0 parce que j'ai commencé à toucher à FreeBSD à
cette version et que ça fonctionnait).
Le Wed, 22 Dec 2010 14:43:34 +0000 (UTC),
Michel Talon écrivait :JKB wrote:Le Wed, 22 Dec 2010 13:11:56 +0000 (UTC),
Michel Talon écrivait :Toxico Nimbus wrote:Michel Talon a écrit :
En fait on se porte aussi bien d' utiliser un seul programmemultithreadé.
Et avec quoi tu synchronise tes threads ? Au hasard, des sémap hores
anonymes ?..
Au hasard des mutex, des variables de condition, etc.
Avec deux threads, ça peut encore passer. Mais lorsque t u as
plusieurs centaines de threads de calculs, il faut quelque ch ose de
plus subtil que des mutexes sous peine de sous utilisation de tes
processeurs.
Mais qu'est-ce que tu racontes? Qu'une région de mémoire soi t protégée
par un sémaphore ou un mutex quelle différence ça fait dans l'efficacité
de la gestion?
Un mutex (portable), c'est verrouillé ou non verrouillé pour
l'ensemble des threads. Un sémaphore, c'est verrouillé seule ment
s'il est nul. Tu peux donc éviter des engorgements du séquen ceur
avec un sémaphore dans des zones critiques du code, ce que tu ne
peux pas faire avec des mutexes (par exemple pour éviter que le
swap te foute en l'air ton calcul). La programmation multithreadé e,
ce n'est pas que des verrous sur des zones de la mémoire, c'est u n
peu plus complexe que ça.
En quoi le fait qu'il y ait une centaine de threads
peut-il conduire à la sous utilisation d'au plus une huitaine de
processeurs?
Imagine qu'Ã un moment, chacun de tes threads travaille sur 8 Go de
mémoire et que ta machine n'a que 32 Go de mémoire. Tu vas p rotéger
le bout critique pour éviter de swap par un sémaphore bien s enti
pour que la zone critique ne puisse être utilisée que par 4 threads
simultanément.
Si tu ne décides pas par toi même de limiter dans la zone cr itique
le nombre de threads actives, tous tes beaux processeurs vont faire
le pied au mur en attendant que le dérobeur de pages fasse son
boulot.
Le Wed, 22 Dec 2010 14:43:34 +0000 (UTC),
Michel Talon <talon@lpthe.jussieu.fr> écrivait :
JKB <jkb@koenigsberg.invalid> wrote:
Le Wed, 22 Dec 2010 13:11:56 +0000 (UTC),
Michel Talon <talon@lpthe.jussieu.fr> écrivait :
Toxico Nimbus <ToxN@free.fr> wrote:
Michel Talon a écrit :
En fait on se porte aussi bien d' utiliser un seul programme
multithreadé.
Et avec quoi tu synchronise tes threads ? Au hasard, des sémap hores
anonymes ?..
Au hasard des mutex, des variables de condition, etc.
Avec deux threads, ça peut encore passer. Mais lorsque t u as
plusieurs centaines de threads de calculs, il faut quelque ch ose de
plus subtil que des mutexes sous peine de sous utilisation de tes
processeurs.
Mais qu'est-ce que tu racontes? Qu'une région de mémoire soi t protégée
par un sémaphore ou un mutex quelle différence ça fait dans l'efficacité
de la gestion?
Un mutex (portable), c'est verrouillé ou non verrouillé pour
l'ensemble des threads. Un sémaphore, c'est verrouillé seule ment
s'il est nul. Tu peux donc éviter des engorgements du séquen ceur
avec un sémaphore dans des zones critiques du code, ce que tu ne
peux pas faire avec des mutexes (par exemple pour éviter que le
swap te foute en l'air ton calcul). La programmation multithreadé e,
ce n'est pas que des verrous sur des zones de la mémoire, c'est u n
peu plus complexe que ça.
En quoi le fait qu'il y ait une centaine de threads
peut-il conduire à la sous utilisation d'au plus une huitaine de
processeurs?
Imagine qu'Ã un moment, chacun de tes threads travaille sur 8 Go de
mémoire et que ta machine n'a que 32 Go de mémoire. Tu vas p rotéger
le bout critique pour éviter de swap par un sémaphore bien s enti
pour que la zone critique ne puisse être utilisée que par 4 threads
simultanément.
Si tu ne décides pas par toi même de limiter dans la zone cr itique
le nombre de threads actives, tous tes beaux processeurs vont faire
le pied au mur en attendant que le dérobeur de pages fasse son
boulot.
Le Wed, 22 Dec 2010 14:43:34 +0000 (UTC),
Michel Talon écrivait :JKB wrote:Le Wed, 22 Dec 2010 13:11:56 +0000 (UTC),
Michel Talon écrivait :Toxico Nimbus wrote:Michel Talon a écrit :
En fait on se porte aussi bien d' utiliser un seul programmemultithreadé.
Et avec quoi tu synchronise tes threads ? Au hasard, des sémap hores
anonymes ?..
Au hasard des mutex, des variables de condition, etc.
Avec deux threads, ça peut encore passer. Mais lorsque t u as
plusieurs centaines de threads de calculs, il faut quelque ch ose de
plus subtil que des mutexes sous peine de sous utilisation de tes
processeurs.
Mais qu'est-ce que tu racontes? Qu'une région de mémoire soi t protégée
par un sémaphore ou un mutex quelle différence ça fait dans l'efficacité
de la gestion?
Un mutex (portable), c'est verrouillé ou non verrouillé pour
l'ensemble des threads. Un sémaphore, c'est verrouillé seule ment
s'il est nul. Tu peux donc éviter des engorgements du séquen ceur
avec un sémaphore dans des zones critiques du code, ce que tu ne
peux pas faire avec des mutexes (par exemple pour éviter que le
swap te foute en l'air ton calcul). La programmation multithreadé e,
ce n'est pas que des verrous sur des zones de la mémoire, c'est u n
peu plus complexe que ça.
En quoi le fait qu'il y ait une centaine de threads
peut-il conduire à la sous utilisation d'au plus une huitaine de
processeurs?
Imagine qu'Ã un moment, chacun de tes threads travaille sur 8 Go de
mémoire et que ta machine n'a que 32 Go de mémoire. Tu vas p rotéger
le bout critique pour éviter de swap par un sémaphore bien s enti
pour que la zone critique ne puisse être utilisée que par 4 threads
simultanément.
Si tu ne décides pas par toi même de limiter dans la zone cr itique
le nombre de threads actives, tous tes beaux processeurs vont faire
le pied au mur en attendant que le dérobeur de pages fasse son
boulot.
JKB wrote:>
> Je viens de vérifier, les sémaphores anonymes partagés entre plusieurs
> processus n'existent pas sous FreeBSD 8.1 il faut aller à 9-CURRENT pour
> les trouver.
Et simplement partagé en threads d'un _même_ processus ? Tous les
codes multithreadés en sont plein (et c'est dans FreeBSD au moins
depuis la version 7.0 parce que j'ai commencé à toucher à FreeBSD à
cette version et que ça fonctionnait).
Mais ça ne sert à rien entre threads d'un même processus, puisque on
peut protéger une zone de mémoire commune par un mutex.
La justification
des sémaphores c'est pour synchroniser une zone de mémoire partagée
entre plusieurs processus, et je ne suis pas sûr que ce soit une très
bonne idée de le faire. Il y a de toutes façon des moyens plus lâches
de communication entre plusieurs processus, comme les pipes, sockets,
etc. Je persiste à penser qu'une relecture de Butenhof te serait
salutaire, je vais faire ma BA tu peux le trouver piraté ici:
http://lib.org.by/_djvu/Cs_Computer%20science/CsPl_Programming%20languages/
JKB <jkb@koenigsberg.invalid> wrote:
>
> Je viens de vérifier, les sémaphores anonymes partagés entre plusieurs
> processus n'existent pas sous FreeBSD 8.1 il faut aller à 9-CURRENT pour
> les trouver.
Et simplement partagé en threads d'un _même_ processus ? Tous les
codes multithreadés en sont plein (et c'est dans FreeBSD au moins
depuis la version 7.0 parce que j'ai commencé à toucher à FreeBSD à
cette version et que ça fonctionnait).
Mais ça ne sert à rien entre threads d'un même processus, puisque on
peut protéger une zone de mémoire commune par un mutex.
La justification
des sémaphores c'est pour synchroniser une zone de mémoire partagée
entre plusieurs processus, et je ne suis pas sûr que ce soit une très
bonne idée de le faire. Il y a de toutes façon des moyens plus lâches
de communication entre plusieurs processus, comme les pipes, sockets,
etc. Je persiste à penser qu'une relecture de Butenhof te serait
salutaire, je vais faire ma BA tu peux le trouver piraté ici:
http://lib.org.by/_djvu/Cs_Computer%20science/CsPl_Programming%20languages/
JKB wrote:>
> Je viens de vérifier, les sémaphores anonymes partagés entre plusieurs
> processus n'existent pas sous FreeBSD 8.1 il faut aller à 9-CURRENT pour
> les trouver.
Et simplement partagé en threads d'un _même_ processus ? Tous les
codes multithreadés en sont plein (et c'est dans FreeBSD au moins
depuis la version 7.0 parce que j'ai commencé à toucher à FreeBSD à
cette version et que ça fonctionnait).
Mais ça ne sert à rien entre threads d'un même processus, puisque on
peut protéger une zone de mémoire commune par un mutex.
La justification
des sémaphores c'est pour synchroniser une zone de mémoire partagée
entre plusieurs processus, et je ne suis pas sûr que ce soit une très
bonne idée de le faire. Il y a de toutes façon des moyens plus lâches
de communication entre plusieurs processus, comme les pipes, sockets,
etc. Je persiste à penser qu'une relecture de Butenhof te serait
salutaire, je vais faire ma BA tu peux le trouver piraté ici:
http://lib.org.by/_djvu/Cs_Computer%20science/CsPl_Programming%20languages/
JKB wrote:Je viens de vérifier, les sémaphores anonymes partagés entre pl usieurs
processus n'existent pas sous FreeBSD 8.1 il faut aller à 9-CURRENT pour
les trouver.
Et simplement partagé en threads d'un _même_ processus ? T ous les
codes multithreadés en sont plein (et c'est dans FreeBSD au moins
depuis la version 7.0 parce que j'ai commencé à toucher à FreeBSD à
cette version et que ça fonctionnait).
Mais ça ne sert à rien entre threads d'un même processus,
JKB <jkb@koenigsberg.invalid> wrote:
Je viens de vérifier, les sémaphores anonymes partagés entre pl usieurs
processus n'existent pas sous FreeBSD 8.1 il faut aller à 9-CURRENT pour
les trouver.
Et simplement partagé en threads d'un _même_ processus ? T ous les
codes multithreadés en sont plein (et c'est dans FreeBSD au moins
depuis la version 7.0 parce que j'ai commencé à toucher à FreeBSD à
cette version et que ça fonctionnait).
Mais ça ne sert à rien entre threads d'un même processus,
JKB wrote:Je viens de vérifier, les sémaphores anonymes partagés entre pl usieurs
processus n'existent pas sous FreeBSD 8.1 il faut aller à 9-CURRENT pour
les trouver.
Et simplement partagé en threads d'un _même_ processus ? T ous les
codes multithreadés en sont plein (et c'est dans FreeBSD au moins
depuis la version 7.0 parce que j'ai commencé à toucher à FreeBSD à
cette version et que ça fonctionnait).
Mais ça ne sert à rien entre threads d'un même processus,
JKB a écrit :Le Wed, 22 Dec 2010 14:43:34 +0000 (UTC),
Michel Talon écrivait :JKB wrote:Le Wed, 22 Dec 2010 13:11:56 +0000 (UTC),
Michel Talon écrivait :Toxico Nimbus wrote:Michel Talon a écrit :
En fait on se porte aussi bien d' utiliser un seul programmemultithreadé.
Et avec quoi tu synchronise tes threads ? Au hasard, des sémaphores
anonymes ?..
Au hasard des mutex, des variables de condition, etc.
Avec deux threads, ça peut encore passer. Mais lorsque tu as
plusieurs centaines de threads de calculs, il faut quelque chose de
plus subtil que des mutexes sous peine de sous utilisation de tes
processeurs.
Mais qu'est-ce que tu racontes? Qu'une région de mémoire soit protégée
par un sémaphore ou un mutex quelle différence ça fait dans l'efficacité
de la gestion?
Un mutex (portable), c'est verrouillé ou non verrouillé pour
l'ensemble des threads. Un sémaphore, c'est verrouillé seulement
s'il est nul. Tu peux donc éviter des engorgements du séquenceur
avec un sémaphore dans des zones critiques du code, ce que tu ne
peux pas faire avec des mutexes (par exemple pour éviter que le
swap te foute en l'air ton calcul). La programmation multithreadée,
ce n'est pas que des verrous sur des zones de la mémoire, c'est un
peu plus complexe que ça.
oh oui encore ...
séquenceur, mutex , engorgements, zones critiques
connerie si t'on thread utilise une zone en écriture
les autres attende point barre mutex ou sémaphore meme topo
Imagine qu'à un moment, chacun de tes threads travaille sur 8 Go de
mémoire et que ta machine n'a que 32 Go de mémoire. Tu vas protéger
le bout critique pour éviter de swap par un sémaphore bien senti
pour que la zone critique ne puisse être utilisée que par 4 threads
simultanément.
Si tu ne décides pas par toi même de limiter dans la zone critique
le nombre de threads actives, tous tes beaux processeurs vont faire
le pied au mur en attendant que le dérobeur de pages fasse son
boulot.
4 threads en écriture haiiii
JKB a écrit :
Le Wed, 22 Dec 2010 14:43:34 +0000 (UTC),
Michel Talon <talon@lpthe.jussieu.fr> écrivait :
JKB <jkb@koenigsberg.invalid> wrote:
Le Wed, 22 Dec 2010 13:11:56 +0000 (UTC),
Michel Talon <talon@lpthe.jussieu.fr> écrivait :
Toxico Nimbus <ToxN@free.fr> wrote:
Michel Talon a écrit :
En fait on se porte aussi bien d' utiliser un seul programme
multithreadé.
Et avec quoi tu synchronise tes threads ? Au hasard, des sémaphores
anonymes ?..
Au hasard des mutex, des variables de condition, etc.
Avec deux threads, ça peut encore passer. Mais lorsque tu as
plusieurs centaines de threads de calculs, il faut quelque chose de
plus subtil que des mutexes sous peine de sous utilisation de tes
processeurs.
Mais qu'est-ce que tu racontes? Qu'une région de mémoire soit protégée
par un sémaphore ou un mutex quelle différence ça fait dans l'efficacité
de la gestion?
Un mutex (portable), c'est verrouillé ou non verrouillé pour
l'ensemble des threads. Un sémaphore, c'est verrouillé seulement
s'il est nul. Tu peux donc éviter des engorgements du séquenceur
avec un sémaphore dans des zones critiques du code, ce que tu ne
peux pas faire avec des mutexes (par exemple pour éviter que le
swap te foute en l'air ton calcul). La programmation multithreadée,
ce n'est pas que des verrous sur des zones de la mémoire, c'est un
peu plus complexe que ça.
oh oui encore ...
séquenceur, mutex , engorgements, zones critiques
connerie si t'on thread utilise une zone en écriture
les autres attende point barre mutex ou sémaphore meme topo
Imagine qu'à un moment, chacun de tes threads travaille sur 8 Go de
mémoire et que ta machine n'a que 32 Go de mémoire. Tu vas protéger
le bout critique pour éviter de swap par un sémaphore bien senti
pour que la zone critique ne puisse être utilisée que par 4 threads
simultanément.
Si tu ne décides pas par toi même de limiter dans la zone critique
le nombre de threads actives, tous tes beaux processeurs vont faire
le pied au mur en attendant que le dérobeur de pages fasse son
boulot.
4 threads en écriture haiiii
JKB a écrit :Le Wed, 22 Dec 2010 14:43:34 +0000 (UTC),
Michel Talon écrivait :JKB wrote:Le Wed, 22 Dec 2010 13:11:56 +0000 (UTC),
Michel Talon écrivait :Toxico Nimbus wrote:Michel Talon a écrit :
En fait on se porte aussi bien d' utiliser un seul programmemultithreadé.
Et avec quoi tu synchronise tes threads ? Au hasard, des sémaphores
anonymes ?..
Au hasard des mutex, des variables de condition, etc.
Avec deux threads, ça peut encore passer. Mais lorsque tu as
plusieurs centaines de threads de calculs, il faut quelque chose de
plus subtil que des mutexes sous peine de sous utilisation de tes
processeurs.
Mais qu'est-ce que tu racontes? Qu'une région de mémoire soit protégée
par un sémaphore ou un mutex quelle différence ça fait dans l'efficacité
de la gestion?
Un mutex (portable), c'est verrouillé ou non verrouillé pour
l'ensemble des threads. Un sémaphore, c'est verrouillé seulement
s'il est nul. Tu peux donc éviter des engorgements du séquenceur
avec un sémaphore dans des zones critiques du code, ce que tu ne
peux pas faire avec des mutexes (par exemple pour éviter que le
swap te foute en l'air ton calcul). La programmation multithreadée,
ce n'est pas que des verrous sur des zones de la mémoire, c'est un
peu plus complexe que ça.
oh oui encore ...
séquenceur, mutex , engorgements, zones critiques
connerie si t'on thread utilise une zone en écriture
les autres attende point barre mutex ou sémaphore meme topo
Imagine qu'à un moment, chacun de tes threads travaille sur 8 Go de
mémoire et que ta machine n'a que 32 Go de mémoire. Tu vas protéger
le bout critique pour éviter de swap par un sémaphore bien senti
pour que la zone critique ne puisse être utilisée que par 4 threads
simultanément.
Si tu ne décides pas par toi même de limiter dans la zone critique
le nombre de threads actives, tous tes beaux processeurs vont faire
le pied au mur en attendant que le dérobeur de pages fasse son
boulot.
4 threads en écriture haiiii
Le Wed, 22 Dec 2010 16:20:13 +0100,
remy écrivait :JKB a écrit :Le Wed, 22 Dec 2010 14:43:34 +0000 (UTC),
Michel Talon écrivait :JKB wrote:Le Wed, 22 Dec 2010 13:11:56 +0000 (UTC),
Michel Talon écrivait :Toxico Nimbus wrote:Michel Talon a écrit :
En fait on se porte aussi bien d' utiliser un seul programmemultithreadé.
Et avec quoi tu synchronise tes threads ? Au hasard, des sém aphores
anonymes ?..
Au hasard des mutex, des variables de condition, etc.
Avec deux threads, ça peut encore passer. Mais lorsque tu as
plusieurs centaines de threads de calculs, il faut quelque chose de
plus subtil que des mutexes sous peine de sous utilisation de tes
processeurs.
Mais qu'est-ce que tu racontes? Qu'une région de mémoire s oit protégée
par un sémaphore ou un mutex quelle différence ça fai t dans l'efficacité
de la gestion?
Un mutex (portable), c'est verrouillé ou non verrouillé po ur
l'ensemble des threads. Un sémaphore, c'est verrouillé seu lement
s'il est nul. Tu peux donc éviter des engorgements du séqu enceur
avec un sémaphore dans des zones critiques du code, ce que tu n e
peux pas faire avec des mutexes (par exemple pour éviter que le
swap te foute en l'air ton calcul). La programmation multithreadé e,
ce n'est pas que des verrous sur des zones de la mémoire, c'est un
peu plus complexe que ça.
oh oui encore ...
séquenceur, mutex , engorgements, zones critiques
connerie si t'on thread utilise une zone en écriture
les autres attende point barre mutex ou sémaphore meme topo
Foutaises. Un mutex est là pour protéger des accès à la mémoire et
ne doivent englober que peu de lignes de codes. Juste celles qui
utilisent cette mémoire. Il n'englobe pas un thread entier, ce
serait une erreur de conception.Imagine qu'Ã un moment, chacun de tes threads travaille sur 8 G o de
mémoire et que ta machine n'a que 32 Go de mémoire. Tu vas protéger
le bout critique pour éviter de swap par un sémaphore bien senti
pour que la zone critique ne puisse être utilisée que par 4 threads
simultanément.
Si tu ne décides pas par toi même de limiter dans la zone critique
le nombre de threads actives, tous tes beaux processeurs vont faire
le pied au mur en attendant que le dérobeur de pages fasse son
boulot.
4 threads en écriture haiiii
Où est-je parlé d'écriture ? Avant de répondre ce genre de chose, tu
devrais lire et comprendre.
Allez, pour toi, je réexplique avec un exemple. Considère qu e tu as
une cartographie complète du continent européen. Il y en a p our 2 Go.
Ces données ne sont accessibles qu'en _lecture_ car il y a assez
peu de chance qu'elles varient. Tes calculs nécessitent 2 Go de
mémoire par thread, mémoire accessible en lecture et en é criture et
propre à chaque thread. Tu n'as donc aucun problème d'accà ¨s
concurrent en écriture. Ta machine possède 16 Go de mém oire.
1/ En multitâche :
2 Go (carte) + 2 Go (calcul) par processus => 4 processus parallè les
2/ En multithread :
2 Go (carte) + n * 2 Go (calcul) => n = 7 threads parallèles
sans que ça ne commence à swapper.
Maintenant, ton calcul peut très bien faire autre chose juste apr ès,
quelque chose qui ne consomme que très peu de mémoire et bea ucoup de
temps CPU. Il peut donc ne pas être tout à fait idiot voire
être intéressant de limiter à 6 les calculs gros consom mateurs de
mémoire à l'aide d'un sémaphore (au hasard initialisà © à 6) et de
laisser courir les autres processus.
Le Wed, 22 Dec 2010 16:20:13 +0100,
remy <remy@fctpas.fr> écrivait :
JKB a écrit :
Le Wed, 22 Dec 2010 14:43:34 +0000 (UTC),
Michel Talon <talon@lpthe.jussieu.fr> écrivait :
JKB <jkb@koenigsberg.invalid> wrote:
Le Wed, 22 Dec 2010 13:11:56 +0000 (UTC),
Michel Talon <talon@lpthe.jussieu.fr> écrivait :
Toxico Nimbus <ToxN@free.fr> wrote:
Michel Talon a écrit :
En fait on se porte aussi bien d' utiliser un seul programme
multithreadé.
Et avec quoi tu synchronise tes threads ? Au hasard, des sém aphores
anonymes ?..
Au hasard des mutex, des variables de condition, etc.
Avec deux threads, ça peut encore passer. Mais lorsque tu as
plusieurs centaines de threads de calculs, il faut quelque chose de
plus subtil que des mutexes sous peine de sous utilisation de tes
processeurs.
Mais qu'est-ce que tu racontes? Qu'une région de mémoire s oit protégée
par un sémaphore ou un mutex quelle différence ça fai t dans l'efficacité
de la gestion?
Un mutex (portable), c'est verrouillé ou non verrouillé po ur
l'ensemble des threads. Un sémaphore, c'est verrouillé seu lement
s'il est nul. Tu peux donc éviter des engorgements du séqu enceur
avec un sémaphore dans des zones critiques du code, ce que tu n e
peux pas faire avec des mutexes (par exemple pour éviter que le
swap te foute en l'air ton calcul). La programmation multithreadé e,
ce n'est pas que des verrous sur des zones de la mémoire, c'est un
peu plus complexe que ça.
oh oui encore ...
séquenceur, mutex , engorgements, zones critiques
connerie si t'on thread utilise une zone en écriture
les autres attende point barre mutex ou sémaphore meme topo
Foutaises. Un mutex est là pour protéger des accès à la mémoire et
ne doivent englober que peu de lignes de codes. Juste celles qui
utilisent cette mémoire. Il n'englobe pas un thread entier, ce
serait une erreur de conception.
Imagine qu'Ã un moment, chacun de tes threads travaille sur 8 G o de
mémoire et que ta machine n'a que 32 Go de mémoire. Tu vas protéger
le bout critique pour éviter de swap par un sémaphore bien senti
pour que la zone critique ne puisse être utilisée que par 4 threads
simultanément.
Si tu ne décides pas par toi même de limiter dans la zone critique
le nombre de threads actives, tous tes beaux processeurs vont faire
le pied au mur en attendant que le dérobeur de pages fasse son
boulot.
4 threads en écriture haiiii
Où est-je parlé d'écriture ? Avant de répondre ce genre de chose, tu
devrais lire et comprendre.
Allez, pour toi, je réexplique avec un exemple. Considère qu e tu as
une cartographie complète du continent européen. Il y en a p our 2 Go.
Ces données ne sont accessibles qu'en _lecture_ car il y a assez
peu de chance qu'elles varient. Tes calculs nécessitent 2 Go de
mémoire par thread, mémoire accessible en lecture et en é criture et
propre à chaque thread. Tu n'as donc aucun problème d'accà ¨s
concurrent en écriture. Ta machine possède 16 Go de mém oire.
1/ En multitâche :
2 Go (carte) + 2 Go (calcul) par processus => 4 processus parallè les
2/ En multithread :
2 Go (carte) + n * 2 Go (calcul) => n = 7 threads parallèles
sans que ça ne commence à swapper.
Maintenant, ton calcul peut très bien faire autre chose juste apr ès,
quelque chose qui ne consomme que très peu de mémoire et bea ucoup de
temps CPU. Il peut donc ne pas être tout à fait idiot voire
être intéressant de limiter à 6 les calculs gros consom mateurs de
mémoire à l'aide d'un sémaphore (au hasard initialisà © à 6) et de
laisser courir les autres processus.
Le Wed, 22 Dec 2010 16:20:13 +0100,
remy écrivait :JKB a écrit :Le Wed, 22 Dec 2010 14:43:34 +0000 (UTC),
Michel Talon écrivait :JKB wrote:Le Wed, 22 Dec 2010 13:11:56 +0000 (UTC),
Michel Talon écrivait :Toxico Nimbus wrote:Michel Talon a écrit :
En fait on se porte aussi bien d' utiliser un seul programmemultithreadé.
Et avec quoi tu synchronise tes threads ? Au hasard, des sém aphores
anonymes ?..
Au hasard des mutex, des variables de condition, etc.
Avec deux threads, ça peut encore passer. Mais lorsque tu as
plusieurs centaines de threads de calculs, il faut quelque chose de
plus subtil que des mutexes sous peine de sous utilisation de tes
processeurs.
Mais qu'est-ce que tu racontes? Qu'une région de mémoire s oit protégée
par un sémaphore ou un mutex quelle différence ça fai t dans l'efficacité
de la gestion?
Un mutex (portable), c'est verrouillé ou non verrouillé po ur
l'ensemble des threads. Un sémaphore, c'est verrouillé seu lement
s'il est nul. Tu peux donc éviter des engorgements du séqu enceur
avec un sémaphore dans des zones critiques du code, ce que tu n e
peux pas faire avec des mutexes (par exemple pour éviter que le
swap te foute en l'air ton calcul). La programmation multithreadé e,
ce n'est pas que des verrous sur des zones de la mémoire, c'est un
peu plus complexe que ça.
oh oui encore ...
séquenceur, mutex , engorgements, zones critiques
connerie si t'on thread utilise une zone en écriture
les autres attende point barre mutex ou sémaphore meme topo
Foutaises. Un mutex est là pour protéger des accès à la mémoire et
ne doivent englober que peu de lignes de codes. Juste celles qui
utilisent cette mémoire. Il n'englobe pas un thread entier, ce
serait une erreur de conception.Imagine qu'Ã un moment, chacun de tes threads travaille sur 8 G o de
mémoire et que ta machine n'a que 32 Go de mémoire. Tu vas protéger
le bout critique pour éviter de swap par un sémaphore bien senti
pour que la zone critique ne puisse être utilisée que par 4 threads
simultanément.
Si tu ne décides pas par toi même de limiter dans la zone critique
le nombre de threads actives, tous tes beaux processeurs vont faire
le pied au mur en attendant que le dérobeur de pages fasse son
boulot.
4 threads en écriture haiiii
Où est-je parlé d'écriture ? Avant de répondre ce genre de chose, tu
devrais lire et comprendre.
Allez, pour toi, je réexplique avec un exemple. Considère qu e tu as
une cartographie complète du continent européen. Il y en a p our 2 Go.
Ces données ne sont accessibles qu'en _lecture_ car il y a assez
peu de chance qu'elles varient. Tes calculs nécessitent 2 Go de
mémoire par thread, mémoire accessible en lecture et en é criture et
propre à chaque thread. Tu n'as donc aucun problème d'accà ¨s
concurrent en écriture. Ta machine possède 16 Go de mém oire.
1/ En multitâche :
2 Go (carte) + 2 Go (calcul) par processus => 4 processus parallè les
2/ En multithread :
2 Go (carte) + n * 2 Go (calcul) => n = 7 threads parallèles
sans que ça ne commence à swapper.
Maintenant, ton calcul peut très bien faire autre chose juste apr ès,
quelque chose qui ne consomme que très peu de mémoire et bea ucoup de
temps CPU. Il peut donc ne pas être tout à fait idiot voire
être intéressant de limiter à 6 les calculs gros consom mateurs de
mémoire à l'aide d'un sémaphore (au hasard initialisà © à 6) et de
laisser courir les autres processus.
Allez, pour toi, je réexplique avec un exemple. Considère que tu as
une cartographie complète du continent européen. Il y en a pour 2 Go.
Ces données ne sont accessibles qu'en _lecture_ car il y a assez
peu de chance qu'elles varient. Tes calculs nécessitent 2 Go de
mémoire par thread, mémoire accessible en lecture et en écriture et
propre à chaque thread. Tu n'as donc aucun problème d'accès
concurrent en écriture. Ta machine possède 16 Go de mémoire.
1/ En multitâche :
2 Go (carte) + 2 Go (calcul) par processus => 4 processus parallèles
2/ En multithread :
2 Go (carte) + n * 2 Go (calcul) => n = 7 threads parallèles
sans que ça ne commence à swapper.
Maintenant, ton calcul peut très bien faire autre chose juste après,
quelque chose qui ne consomme que très peu de mémoire et beaucoup de
temps CPU. Il peut donc ne pas être tout à fait idiot voire
être intéressant de limiter à 6 les calculs gros consommateurs de
mémoire à l'aide d'un sémaphore (au hasard initialisé à 6) et de
laisser courir les autres processus.
tu na pas géré le swap de la mémoire dans _un_ processus multi threads
mauvaise exemple change d'exemple
Allez, pour toi, je réexplique avec un exemple. Considère que tu as
une cartographie complète du continent européen. Il y en a pour 2 Go.
Ces données ne sont accessibles qu'en _lecture_ car il y a assez
peu de chance qu'elles varient. Tes calculs nécessitent 2 Go de
mémoire par thread, mémoire accessible en lecture et en écriture et
propre à chaque thread. Tu n'as donc aucun problème d'accès
concurrent en écriture. Ta machine possède 16 Go de mémoire.
1/ En multitâche :
2 Go (carte) + 2 Go (calcul) par processus => 4 processus parallèles
2/ En multithread :
2 Go (carte) + n * 2 Go (calcul) => n = 7 threads parallèles
sans que ça ne commence à swapper.
Maintenant, ton calcul peut très bien faire autre chose juste après,
quelque chose qui ne consomme que très peu de mémoire et beaucoup de
temps CPU. Il peut donc ne pas être tout à fait idiot voire
être intéressant de limiter à 6 les calculs gros consommateurs de
mémoire à l'aide d'un sémaphore (au hasard initialisé à 6) et de
laisser courir les autres processus.
tu na pas géré le swap de la mémoire dans _un_ processus multi threads
mauvaise exemple change d'exemple
Allez, pour toi, je réexplique avec un exemple. Considère que tu as
une cartographie complète du continent européen. Il y en a pour 2 Go.
Ces données ne sont accessibles qu'en _lecture_ car il y a assez
peu de chance qu'elles varient. Tes calculs nécessitent 2 Go de
mémoire par thread, mémoire accessible en lecture et en écriture et
propre à chaque thread. Tu n'as donc aucun problème d'accès
concurrent en écriture. Ta machine possède 16 Go de mémoire.
1/ En multitâche :
2 Go (carte) + 2 Go (calcul) par processus => 4 processus parallèles
2/ En multithread :
2 Go (carte) + n * 2 Go (calcul) => n = 7 threads parallèles
sans que ça ne commence à swapper.
Maintenant, ton calcul peut très bien faire autre chose juste après,
quelque chose qui ne consomme que très peu de mémoire et beaucoup de
temps CPU. Il peut donc ne pas être tout à fait idiot voire
être intéressant de limiter à 6 les calculs gros consommateurs de
mémoire à l'aide d'un sémaphore (au hasard initialisé à 6) et de
laisser courir les autres processus.
tu na pas géré le swap de la mémoire dans _un_ processus multi threads
mauvaise exemple change d'exemple
Le Wed, 22 Dec 2010 16:59:38 +0100,
remy écrivait :Allez, pour toi, je réexplique avec un exemple. Considère que tu as
une cartographie complète du continent européen. Il y en a pour 2 Go.
Ces données ne sont accessibles qu'en _lecture_ car il y a asse z
peu de chance qu'elles varient. Tes calculs nécessitent 2 Go de
mémoire par thread, mémoire accessible en lecture et en à ©criture et
propre à chaque thread. Tu n'as donc aucun problème d'accà ¨s
concurrent en écriture. Ta machine possède 16 Go de mé moire.
1/ En multitâche :
2 Go (carte) + 2 Go (calcul) par processus => 4 processus parallà ¨les
2/ En multithread :
2 Go (carte) + n * 2 Go (calcul) => n = 7 threads parallèle s
sans que ça ne commence à swapper.
Maintenant, ton calcul peut très bien faire autre chose juste a près,
quelque chose qui ne consomme que très peu de mémoire et b eaucoup de
temps CPU. Il peut donc ne pas être tout à fait idiot voir e
être intéressant de limiter à 6 les calculs gros cons ommateurs de
mémoire à l'aide d'un sémaphore (au hasard initialisà © à 6) et de
laisser courir les autres processus.
tu na pas géré le swap de la mémoire dans _un_ process us multi threads
mauvaise exemple change d'exemple
Va apprendre les bases des systèmes d'exploitation.
<EOT>
Le Wed, 22 Dec 2010 16:59:38 +0100,
remy <remy@fctpas.fr> écrivait :
Allez, pour toi, je réexplique avec un exemple. Considère que tu as
une cartographie complète du continent européen. Il y en a pour 2 Go.
Ces données ne sont accessibles qu'en _lecture_ car il y a asse z
peu de chance qu'elles varient. Tes calculs nécessitent 2 Go de
mémoire par thread, mémoire accessible en lecture et en à ©criture et
propre à chaque thread. Tu n'as donc aucun problème d'accà ¨s
concurrent en écriture. Ta machine possède 16 Go de mé moire.
1/ En multitâche :
2 Go (carte) + 2 Go (calcul) par processus => 4 processus parallà ¨les
2/ En multithread :
2 Go (carte) + n * 2 Go (calcul) => n = 7 threads parallèle s
sans que ça ne commence à swapper.
Maintenant, ton calcul peut très bien faire autre chose juste a près,
quelque chose qui ne consomme que très peu de mémoire et b eaucoup de
temps CPU. Il peut donc ne pas être tout à fait idiot voir e
être intéressant de limiter à 6 les calculs gros cons ommateurs de
mémoire à l'aide d'un sémaphore (au hasard initialisà © à 6) et de
laisser courir les autres processus.
tu na pas géré le swap de la mémoire dans _un_ process us multi threads
mauvaise exemple change d'exemple
Va apprendre les bases des systèmes d'exploitation.
<EOT>
Le Wed, 22 Dec 2010 16:59:38 +0100,
remy écrivait :Allez, pour toi, je réexplique avec un exemple. Considère que tu as
une cartographie complète du continent européen. Il y en a pour 2 Go.
Ces données ne sont accessibles qu'en _lecture_ car il y a asse z
peu de chance qu'elles varient. Tes calculs nécessitent 2 Go de
mémoire par thread, mémoire accessible en lecture et en à ©criture et
propre à chaque thread. Tu n'as donc aucun problème d'accà ¨s
concurrent en écriture. Ta machine possède 16 Go de mé moire.
1/ En multitâche :
2 Go (carte) + 2 Go (calcul) par processus => 4 processus parallà ¨les
2/ En multithread :
2 Go (carte) + n * 2 Go (calcul) => n = 7 threads parallèle s
sans que ça ne commence à swapper.
Maintenant, ton calcul peut très bien faire autre chose juste a près,
quelque chose qui ne consomme que très peu de mémoire et b eaucoup de
temps CPU. Il peut donc ne pas être tout à fait idiot voir e
être intéressant de limiter à 6 les calculs gros cons ommateurs de
mémoire à l'aide d'un sémaphore (au hasard initialisà © à 6) et de
laisser courir les autres processus.
tu na pas géré le swap de la mémoire dans _un_ process us multi threads
mauvaise exemple change d'exemple
Va apprendre les bases des systèmes d'exploitation.
<EOT>