Le Thu, 23 Dec 2010 19:34:51 +0100, crouic écrivait :
Le 23/12/2010 00:22, JKB a écrit :
Le Wed, 22 Dec 2010 21:49:20 +0100,
JFK, si tu as de la doc technique, je suis preneur ;)
http://www.l4ka.org/projects/pistachio/
C'est rude, il faut se faire un noeud au cerveau pour comprendre comment ça fonctionne, mais c'est élégant.
Cordialement,
JKB
Merci, moi qui voulait avoir une vue d'ensemble... :D Il se trouve que j'ai commencé à la potasser ce matin même, c'est du technique pur avec le nombre de bits par registre, etc. Mais la lecture est en cours.
Je te conseille de commencer plutôt par la gestion des threads et de la mémoire sans te préoccuper de la façon dont les bits sont gérés dans les objets. Le plus compliqué à comprendre est le mapping entre la mémoire physique et la mémoire virtuelle (c'est pour cela qu'il faut plusieurs pagers en cascade) et le coup des fenêtres de mapping.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Thu, 23 Dec 2010 19:34:51 +0100,
crouic <lacigale@no-log.org> écrivait :
Le 23/12/2010 00:22, JKB a écrit :
Le Wed, 22 Dec 2010 21:49:20 +0100,
JFK, si tu as de la doc technique, je suis preneur ;)
http://www.l4ka.org/projects/pistachio/
C'est rude, il faut se faire un noeud au cerveau pour comprendre
comment ça fonctionne, mais c'est élégant.
Cordialement,
JKB
Merci, moi qui voulait avoir une vue d'ensemble... :D
Il se trouve que j'ai commencé à la potasser ce matin même, c'est du technique
pur avec le nombre de bits par registre, etc. Mais la lecture est en cours.
Je te conseille de commencer plutôt par la gestion des threads et
de la mémoire sans te préoccuper de la façon dont les bits sont
gérés dans les objets. Le plus compliqué à comprendre est le mapping
entre la mémoire physique et la mémoire virtuelle (c'est pour cela
qu'il faut plusieurs pagers en cascade) et le coup des fenêtres de
mapping.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Thu, 23 Dec 2010 19:34:51 +0100, crouic écrivait :
Le 23/12/2010 00:22, JKB a écrit :
Le Wed, 22 Dec 2010 21:49:20 +0100,
JFK, si tu as de la doc technique, je suis preneur ;)
http://www.l4ka.org/projects/pistachio/
C'est rude, il faut se faire un noeud au cerveau pour comprendre comment ça fonctionne, mais c'est élégant.
Cordialement,
JKB
Merci, moi qui voulait avoir une vue d'ensemble... :D Il se trouve que j'ai commencé à la potasser ce matin même, c'est du technique pur avec le nombre de bits par registre, etc. Mais la lecture est en cours.
Je te conseille de commencer plutôt par la gestion des threads et de la mémoire sans te préoccuper de la façon dont les bits sont gérés dans les objets. Le plus compliqué à comprendre est le mapping entre la mémoire physique et la mémoire virtuelle (c'est pour cela qu'il faut plusieurs pagers en cascade) et le coup des fenêtres de mapping.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
YBM
JKB a écrit :
Et je ne vois toujours pas la relation évidente entre la programmation système et qt. On n'est pas sur le même plan et on n'utilise surtout pas les mêmes techniques.
T'emballe pas trop, tu parle à "remy", le prototype du "très limité qui ouvre sa gueule sans trop savoir de quoi il parle" de Usenet-FR, si tu insistes tu vas devenir fou ou mourir de rire.
JKB a écrit :
Et je ne vois toujours pas la relation évidente entre la
programmation système et qt. On n'est pas sur le même plan et on
n'utilise surtout pas les mêmes techniques.
T'emballe pas trop, tu parle à "remy", le prototype du "très limité qui
ouvre sa gueule sans trop savoir de quoi il parle" de Usenet-FR, si tu
insistes tu vas devenir fou ou mourir de rire.
Et je ne vois toujours pas la relation évidente entre la programmation système et qt. On n'est pas sur le même plan et on n'utilise surtout pas les mêmes techniques.
T'emballe pas trop, tu parle à "remy", le prototype du "très limité qui ouvre sa gueule sans trop savoir de quoi il parle" de Usenet-FR, si tu insistes tu vas devenir fou ou mourir de rire.
ST
On 12/24/10 8:12 AM, YBM wrote:
JKB a écrit :
Et je ne vois toujours pas la relation évidente entre la programmation système et qt. On n'est pas sur le même plan et on n'utilise surtout pas les mêmes techniques.
T'emballe pas trop, tu parle à "remy", le prototype du "très limité qui ouvre sa gueule sans trop savoir de quoi il parle" de Usenet-FR, si tu insistes tu vas devenir fou ou mourir de rire.
Remarques, tu parles a JKB, un prototype egalement de la grande gueule.
-- Recherche un admin Linux/Perl devel pour un poste plutot intéressant basé sur Singapore. Me contacter directement pour plus d'information.
On 12/24/10 8:12 AM, YBM wrote:
JKB a écrit :
Et je ne vois toujours pas la relation évidente entre la
programmation système et qt. On n'est pas sur le même plan et on
n'utilise surtout pas les mêmes techniques.
T'emballe pas trop, tu parle à "remy", le prototype du "très limité qui
ouvre sa gueule sans trop savoir de quoi il parle" de Usenet-FR, si tu
insistes tu vas devenir fou ou mourir de rire.
Remarques, tu parles a JKB, un prototype egalement de la grande gueule.
--
Recherche un admin Linux/Perl devel pour un poste
plutot intéressant basé sur Singapore. Me contacter
directement pour plus d'information.
Et je ne vois toujours pas la relation évidente entre la programmation système et qt. On n'est pas sur le même plan et on n'utilise surtout pas les mêmes techniques.
T'emballe pas trop, tu parle à "remy", le prototype du "très limité qui ouvre sa gueule sans trop savoir de quoi il parle" de Usenet-FR, si tu insistes tu vas devenir fou ou mourir de rire.
Remarques, tu parles a JKB, un prototype egalement de la grande gueule.
-- Recherche un admin Linux/Perl devel pour un poste plutot intéressant basé sur Singapore. Me contacter directement pour plus d'information.
JKB
Le Fri, 24 Dec 2010 01:12:13 +0100, YBM écrivait :
JKB a écrit :
Et je ne vois toujours pas la relation évidente entre la programmation système et qt. On n'est pas sur le même plan et on n'utilise surtout pas les mêmes techniques.
T'emballe pas trop, tu parle à "remy", le prototype du "très limité qui ouvre sa gueule sans trop savoir de quoi il parle" de Usenet-FR, si tu insistes tu vas devenir fou ou mourir de rire.
Ce n'est pas le seul prototype du gars "très limité" qui traîne par ici, malheureusement. Quant aux réponses, c'est simplement pour éviter que quelqu'un qui trouverait le fil quelque part ne puisse prendre pour argent comptant ses élucubrations...
Cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Fri, 24 Dec 2010 01:12:13 +0100,
YBM <ybmess@nooos.fr.invalid> écrivait :
JKB a écrit :
Et je ne vois toujours pas la relation évidente entre la
programmation système et qt. On n'est pas sur le même plan et on
n'utilise surtout pas les mêmes techniques.
T'emballe pas trop, tu parle à "remy", le prototype du "très limité qui
ouvre sa gueule sans trop savoir de quoi il parle" de Usenet-FR, si tu
insistes tu vas devenir fou ou mourir de rire.
Ce n'est pas le seul prototype du gars "très limité" qui traîne par
ici, malheureusement. Quant aux réponses, c'est simplement pour
éviter que quelqu'un qui trouverait le fil quelque part ne puisse
prendre pour argent comptant ses élucubrations...
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Fri, 24 Dec 2010 01:12:13 +0100, YBM écrivait :
JKB a écrit :
Et je ne vois toujours pas la relation évidente entre la programmation système et qt. On n'est pas sur le même plan et on n'utilise surtout pas les mêmes techniques.
T'emballe pas trop, tu parle à "remy", le prototype du "très limité qui ouvre sa gueule sans trop savoir de quoi il parle" de Usenet-FR, si tu insistes tu vas devenir fou ou mourir de rire.
Ce n'est pas le seul prototype du gars "très limité" qui traîne par ici, malheureusement. Quant aux réponses, c'est simplement pour éviter que quelqu'un qui trouverait le fil quelque part ne puisse prendre pour argent comptant ses élucubrations...
Cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
pehache-youplaboum
"JKB" a écrit dans le message de news:
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.
Plusieurs centaines de threads de calculs sur un Mac ??? Tu as fumé quoi, là ?
Et même en dehors des Mac je ne vois pas de machine actuelle sur laquelle ça aurait un sens.
Mais sans doute utilises-tu un MacOS X adapté par tes soins pour tourner sur un Bull de 1977 que tu bricolé pour y implanter 4096 processeurs sur mémoire partagée ?
-- pehache http://pehache.free.fr
"JKB" <jkb@koenigsberg.invalid> a écrit dans le message de news:
slrnih3vgc.i3n.jkb@rayleigh.systella.fr
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.
Plusieurs centaines de threads de calculs sur un Mac ??? Tu as fumé quoi, là
?
Et même en dehors des Mac je ne vois pas de machine actuelle sur laquelle ça
aurait un sens.
Mais sans doute utilises-tu un MacOS X adapté par tes soins pour tourner sur
un Bull de 1977 que tu bricolé pour y implanter 4096 processeurs sur mémoire
partagée ?
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.
Plusieurs centaines de threads de calculs sur un Mac ??? Tu as fumé quoi, là ?
Et même en dehors des Mac je ne vois pas de machine actuelle sur laquelle ça aurait un sens.
Mais sans doute utilises-tu un MacOS X adapté par tes soins pour tourner sur un Bull de 1977 que tu bricolé pour y implanter 4096 processeurs sur mémoire partagée ?
-- pehache http://pehache.free.fr
Tonton Th
On 01/03/2011 02:10 AM, pehache-youplaboum wrote:
Plusieurs centaines de threads de calculs sur un Mac ??? Tu as fumé quoi, là ?
Bah là, j'ai un soft qui fait 512+ threads sur un Celeron 233 avec peu de ram (256 ?), et même si la machine est un peu à plat, ça marche très bien.
Et même en dehors des Mac je ne vois pas de machine actuelle sur laquelle ça aurait un sens.
Le même soft, sur un gros truc avec deux gros bouilleurs à multiples chaudières a fait en gros la même chose.
Alors, bon, le Mac, c'est iBanal.
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
On 01/03/2011 02:10 AM, pehache-youplaboum wrote:
Plusieurs centaines de threads de calculs sur un Mac ??? Tu as fumé
quoi, là ?
Bah là, j'ai un soft qui fait 512+ threads sur un Celeron 233
avec peu de ram (256 ?), et même si la machine est un peu à
plat, ça marche très bien.
Et même en dehors des Mac je ne vois pas de machine actuelle sur
laquelle ça aurait un sens.
Le même soft, sur un gros truc avec deux gros bouilleurs
à multiples chaudières a fait en gros la même chose.
Alors, bon, le Mac, c'est iBanal.
--
Ma coiffeuse est formidable - http://sonia.buvette.org/
tu na pas géré le swap de la mémoire dans _un_ processus multi threads
C'est pas à toi de gérer le swap, parce que c'est la mission de cette nice bloody awesome kernelle.
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
Pascal Hambourg
Salut,
JKB a écrit :
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.
Pourquoi en multitâche faut-il 2 Go par processus pour la carte ?
Salut,
JKB a écrit :
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.
Pourquoi en multitâche faut-il 2 Go par processus pour la carte ?
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.
Pourquoi en multitâche faut-il 2 Go par processus pour la carte ?
pehache-youplaboum
On 5 jan, 13:20, Pascal Hambourg wrote:
Salut,
JKB a crit :
> 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 para ll les
> 2/ En multithread : > 2 Go (carte) + n * 2 Go (calcul) => n = 7 threads parall les
> sans que a ne commence swapper.
Pourquoi en multit che faut-il 2 Go par processus pour la carte ?
Parce que des process différents ne partagent pas la même mémoire, donc chacun doit charger la carte.
Cela dit dans tout ce raisonnenment on fait comme si la mémoire était le seul facteur limitant du nombre de thread/process, alors qu'en pratique le nombre de CPU ou de cores l'est tout autant.
-- pehache
On 5 jan, 13:20, Pascal Hambourg <boite-a-s...@plouf.fr.eu.org> wrote:
Salut,
JKB a crit :
> 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 para ll les
> 2/ En multithread :
> 2 Go (carte) + n * 2 Go (calcul) => n = 7 threads parall les
> sans que a ne commence swapper.
Pourquoi en multit che faut-il 2 Go par processus pour la carte ?
Parce que des process différents ne partagent pas la même mémoire,
donc chacun doit charger la carte.
Cela dit dans tout ce raisonnenment on fait comme si la mémoire était
le seul facteur limitant du nombre de thread/process, alors qu'en
pratique le nombre de CPU ou de cores l'est tout autant.
> 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 para ll les
> 2/ En multithread : > 2 Go (carte) + n * 2 Go (calcul) => n = 7 threads parall les
> sans que a ne commence swapper.
Pourquoi en multit che faut-il 2 Go par processus pour la carte ?
Parce que des process différents ne partagent pas la même mémoire, donc chacun doit charger la carte.
Cela dit dans tout ce raisonnenment on fait comme si la mémoire était le seul facteur limitant du nombre de thread/process, alors qu'en pratique le nombre de CPU ou de cores l'est tout autant.
