"Tonton Th" a écrit dans le message de news:
4ccd3625$0$1083$Pour faire encore plus simple : pas besoin de logiciel "optimisé"
pour le multi-coeur pour tirer pleinement parti des machines
multi-coeurs. Sauf pour les ancètres qui utilisent des OS
monotaches.
Portnawak.
Si un logiciel donné n'a pas été programmé pour faire du parallélisme (que
ce soit en multithreading ou en multiprocessing), il n'utilise qu'un coeur
quoi qu'il arrive.
"Tonton Th" <tth@la.bas.invalid> a écrit dans le message de news:
4ccd3625$0$1083$426a74cc@news.free.fr
Pour faire encore plus simple : pas besoin de logiciel "optimisé"
pour le multi-coeur pour tirer pleinement parti des machines
multi-coeurs. Sauf pour les ancètres qui utilisent des OS
monotaches.
Portnawak.
Si un logiciel donné n'a pas été programmé pour faire du parallélisme (que
ce soit en multithreading ou en multiprocessing), il n'utilise qu'un coeur
quoi qu'il arrive.
"Tonton Th" a écrit dans le message de news:
4ccd3625$0$1083$Pour faire encore plus simple : pas besoin de logiciel "optimisé"
pour le multi-coeur pour tirer pleinement parti des machines
multi-coeurs. Sauf pour les ancètres qui utilisent des OS
monotaches.
Portnawak.
Si un logiciel donné n'a pas été programmé pour faire du parallélisme (que
ce soit en multithreading ou en multiprocessing), il n'utilise qu'un coeur
quoi qu'il arrive.
Par contre, pour des applications pouvant utiliser des instruction plus
récentes (multimédia ou dé/compression ou encodage), y a-t-il des
distributions qui utiliseraient des systèmes de package pour compiler
peut-être une partie du code ? C'est juste une question pour savoir.
Il me semble que les .deb exécutent des scripts, ça doit-être dans le
domaine du possible, non ?
Par contre, pour des applications pouvant utiliser des instruction plus
récentes (multimédia ou dé/compression ou encodage), y a-t-il des
distributions qui utiliseraient des systèmes de package pour compiler
peut-être une partie du code ? C'est juste une question pour savoir.
Il me semble que les .deb exécutent des scripts, ça doit-être dans le
domaine du possible, non ?
Par contre, pour des applications pouvant utiliser des instruction plus
récentes (multimédia ou dé/compression ou encodage), y a-t-il des
distributions qui utiliseraient des systèmes de package pour compiler
peut-être une partie du code ? C'est juste une question pour savoir.
Il me semble que les .deb exécutent des scripts, ça doit-être dans le
domaine du possible, non ?
pehache-youplaboum wrote:"Tonton Th" a écrit dans le message de news:
4ccd3625$0$1083$Pour faire encore plus simple : pas besoin de logiciel "optimisé"
pour le multi-coeur pour tirer pleinement parti des machines
multi-coeurs. Sauf pour les ancètres qui utilisent des OS
monotaches.Portnawak.
Si un logiciel donné n'a pas été programmé pour faire du parallélisme (que
ce soit en multithreading ou en multiprocessing), il n'utilise qu'un coeur
quoi qu'il arrive.
J'ai des logiciels qui profitent de plusieurs coeurs et d'autres non. Mais
comme mon OS est multi-tâche (je ne suis pas un ancêtre qui utilise un OS
mono-tâche), je peux profiter tout le temps de mes 4 coeurs en lançant des
tâches en parallèle même si toutes celles que je lance ne sont pas
optimisées. Donc on peut très bien tirer parti de son multi-coeurs sans
avoir un seul logiciel optimisé pour le multi-coeur. Portnawak un peu rapide
à mon avis. Et comme j'ai de quoi avoir toujours mes 4 coeurs en fonction,
j'en tire pleinement profit.
pehache-youplaboum wrote:
"Tonton Th"<tth@la.bas.invalid> a écrit dans le message de news:
4ccd3625$0$1083$426a74cc@news.free.fr
Pour faire encore plus simple : pas besoin de logiciel "optimisé"
pour le multi-coeur pour tirer pleinement parti des machines
multi-coeurs. Sauf pour les ancètres qui utilisent des OS
monotaches.
Portnawak.
Si un logiciel donné n'a pas été programmé pour faire du parallélisme (que
ce soit en multithreading ou en multiprocessing), il n'utilise qu'un coeur
quoi qu'il arrive.
J'ai des logiciels qui profitent de plusieurs coeurs et d'autres non. Mais
comme mon OS est multi-tâche (je ne suis pas un ancêtre qui utilise un OS
mono-tâche), je peux profiter tout le temps de mes 4 coeurs en lançant des
tâches en parallèle même si toutes celles que je lance ne sont pas
optimisées. Donc on peut très bien tirer parti de son multi-coeurs sans
avoir un seul logiciel optimisé pour le multi-coeur. Portnawak un peu rapide
à mon avis. Et comme j'ai de quoi avoir toujours mes 4 coeurs en fonction,
j'en tire pleinement profit.
pehache-youplaboum wrote:"Tonton Th" a écrit dans le message de news:
4ccd3625$0$1083$Pour faire encore plus simple : pas besoin de logiciel "optimisé"
pour le multi-coeur pour tirer pleinement parti des machines
multi-coeurs. Sauf pour les ancètres qui utilisent des OS
monotaches.Portnawak.
Si un logiciel donné n'a pas été programmé pour faire du parallélisme (que
ce soit en multithreading ou en multiprocessing), il n'utilise qu'un coeur
quoi qu'il arrive.
J'ai des logiciels qui profitent de plusieurs coeurs et d'autres non. Mais
comme mon OS est multi-tâche (je ne suis pas un ancêtre qui utilise un OS
mono-tâche), je peux profiter tout le temps de mes 4 coeurs en lançant des
tâches en parallèle même si toutes celles que je lance ne sont pas
optimisées. Donc on peut très bien tirer parti de son multi-coeurs sans
avoir un seul logiciel optimisé pour le multi-coeur. Portnawak un peu rapide
à mon avis. Et comme j'ai de quoi avoir toujours mes 4 coeurs en fonction,
j'en tire pleinement profit.
PP , dans le message<4ccd3eed$0$3675$, a écrit :Par contre, pour des applications pouvant utiliser des instruction plus
récentes (multimédia ou dé/compression ou encodage), y a-t-il des
distributions qui utiliseraient des systèmes de package pour compiler
peut-être une partie du code ? C'est juste une question pour savoir.
Il me semble que les .deb exécutent des scripts, ça doit-être dans le
domaine du possible, non ?
Le chargeur dynamique de la glibc permet ce genre de choses pour les
bibliothèques partagées : avant d'aller chercher dans /usr/lib (ou
/usr/loal/lib, etc/), il va chercher dans des sous-répertoires qui dépendent
de l'architecture, du style /usr/lib/tls/i686/sse2/cmov.
Mais ce genre de possibilité est très rarement utile : il faut que les
optimisations existent et soient significatives. Ça arrive pour les
bibliothèques de crypto, par exemple :
~ $ dpkg -L libssl0.9.8
<snip>
/usr/lib/libcrypto.so.0.9.8
/usr/lib/i586/libcrypto.so.0.9.8
/usr/lib/i486/libcrypto.so.0.9.8
/usr/lib/i686/cmov/libcrypto.so.0.9.8
PP , dans le message<4ccd3eed$0$3675$426a34cc@news.free.fr>, a écrit :
Par contre, pour des applications pouvant utiliser des instruction plus
récentes (multimédia ou dé/compression ou encodage), y a-t-il des
distributions qui utiliseraient des systèmes de package pour compiler
peut-être une partie du code ? C'est juste une question pour savoir.
Il me semble que les .deb exécutent des scripts, ça doit-être dans le
domaine du possible, non ?
Le chargeur dynamique de la glibc permet ce genre de choses pour les
bibliothèques partagées : avant d'aller chercher dans /usr/lib (ou
/usr/loal/lib, etc/), il va chercher dans des sous-répertoires qui dépendent
de l'architecture, du style /usr/lib/tls/i686/sse2/cmov.
Mais ce genre de possibilité est très rarement utile : il faut que les
optimisations existent et soient significatives. Ça arrive pour les
bibliothèques de crypto, par exemple :
george@quatramaran ~ $ dpkg -L libssl0.9.8
<snip>
/usr/lib/libcrypto.so.0.9.8
/usr/lib/i586/libcrypto.so.0.9.8
/usr/lib/i486/libcrypto.so.0.9.8
/usr/lib/i686/cmov/libcrypto.so.0.9.8
PP , dans le message<4ccd3eed$0$3675$, a écrit :Par contre, pour des applications pouvant utiliser des instruction plus
récentes (multimédia ou dé/compression ou encodage), y a-t-il des
distributions qui utiliseraient des systèmes de package pour compiler
peut-être une partie du code ? C'est juste une question pour savoir.
Il me semble que les .deb exécutent des scripts, ça doit-être dans le
domaine du possible, non ?
Le chargeur dynamique de la glibc permet ce genre de choses pour les
bibliothèques partagées : avant d'aller chercher dans /usr/lib (ou
/usr/loal/lib, etc/), il va chercher dans des sous-répertoires qui dépendent
de l'architecture, du style /usr/lib/tls/i686/sse2/cmov.
Mais ce genre de possibilité est très rarement utile : il faut que les
optimisations existent et soient significatives. Ça arrive pour les
bibliothèques de crypto, par exemple :
~ $ dpkg -L libssl0.9.8
<snip>
/usr/lib/libcrypto.so.0.9.8
/usr/lib/i586/libcrypto.so.0.9.8
/usr/lib/i486/libcrypto.so.0.9.8
/usr/lib/i686/cmov/libcrypto.so.0.9.8
Je pense que pour des bibliothèques multimédias ou autres il y a ce
genre d'optimisation, non ?
Peut-on imaginer par excès, en reprenant ton exemple, des sous
répertoires des répertoire d'architecture pour se rapprocher au plus
près des instructions des processeurs récents.
Je pense que pour des bibliothèques multimédias ou autres il y a ce
genre d'optimisation, non ?
Peut-on imaginer par excès, en reprenant ton exemple, des sous
répertoires des répertoire d'architecture pour se rapprocher au plus
près des instructions des processeurs récents.
Je pense que pour des bibliothèques multimédias ou autres il y a ce
genre d'optimisation, non ?
Peut-on imaginer par excès, en reprenant ton exemple, des sous
répertoires des répertoire d'architecture pour se rapprocher au plus
près des instructions des processeurs récents.
Le 31/10/2010 11:04, Stéphan Peccini a écrit :pehache-youplaboum wrote:"Tonton Th" a écrit dans le message de news:
4ccd3625$0$1083$Pour faire encore plus simple : pas besoin de logiciel "optimisé"
pour le multi-coeur pour tirer pleinement parti des machines
multi-coeurs. Sauf pour les ancètres qui utilisent des OS
monotaches.Portnawak.
Si un logiciel donné n'a pas été programmé pour faire du parallélisme (que
ce soit en multithreading ou en multiprocessing), il n'utilise qu'un coeur
quoi qu'il arrive.
J'ai des logiciels qui profitent de plusieurs coeurs et d'autres non. Mais
comme mon OS est multi-tâche (je ne suis pas un ancêtre qui utilise un OS
mono-tâche), je peux profiter tout le temps de mes 4 coeurs en lançant des
tâches en parallèle même si toutes celles que je lance ne sont pas
optimisées. Donc on peut très bien tirer parti de son multi-coeurs sans
avoir un seul logiciel optimisé pour le multi-coeur. Portnawak un peu rapide
à mon avis. Et comme j'ai de quoi avoir toujours mes 4 coeurs en fonction,
j'en tire pleinement profit.
Sans être un spécialiste, je suis assez d'accord, quand on voit le
nombre de processus en cours sur un ordinateur, tant windows que Linux,
le multicœur est automatiquement utilisé pour accroitre la rapidité de
la machine car je pense que les processus sont répartis entre les cœurs.
À moins que les OS soient merdiques.
Le 31/10/2010 11:04, Stéphan Peccini a écrit :
pehache-youplaboum wrote:
"Tonton Th"<tth@la.bas.invalid> a écrit dans le message de news:
4ccd3625$0$1083$426a74cc@news.free.fr
Pour faire encore plus simple : pas besoin de logiciel "optimisé"
pour le multi-coeur pour tirer pleinement parti des machines
multi-coeurs. Sauf pour les ancètres qui utilisent des OS
monotaches.
Portnawak.
Si un logiciel donné n'a pas été programmé pour faire du parallélisme (que
ce soit en multithreading ou en multiprocessing), il n'utilise qu'un coeur
quoi qu'il arrive.
J'ai des logiciels qui profitent de plusieurs coeurs et d'autres non. Mais
comme mon OS est multi-tâche (je ne suis pas un ancêtre qui utilise un OS
mono-tâche), je peux profiter tout le temps de mes 4 coeurs en lançant des
tâches en parallèle même si toutes celles que je lance ne sont pas
optimisées. Donc on peut très bien tirer parti de son multi-coeurs sans
avoir un seul logiciel optimisé pour le multi-coeur. Portnawak un peu rapide
à mon avis. Et comme j'ai de quoi avoir toujours mes 4 coeurs en fonction,
j'en tire pleinement profit.
Sans être un spécialiste, je suis assez d'accord, quand on voit le
nombre de processus en cours sur un ordinateur, tant windows que Linux,
le multicœur est automatiquement utilisé pour accroitre la rapidité de
la machine car je pense que les processus sont répartis entre les cœurs.
À moins que les OS soient merdiques.
Le 31/10/2010 11:04, Stéphan Peccini a écrit :pehache-youplaboum wrote:"Tonton Th" a écrit dans le message de news:
4ccd3625$0$1083$Pour faire encore plus simple : pas besoin de logiciel "optimisé"
pour le multi-coeur pour tirer pleinement parti des machines
multi-coeurs. Sauf pour les ancètres qui utilisent des OS
monotaches.Portnawak.
Si un logiciel donné n'a pas été programmé pour faire du parallélisme (que
ce soit en multithreading ou en multiprocessing), il n'utilise qu'un coeur
quoi qu'il arrive.
J'ai des logiciels qui profitent de plusieurs coeurs et d'autres non. Mais
comme mon OS est multi-tâche (je ne suis pas un ancêtre qui utilise un OS
mono-tâche), je peux profiter tout le temps de mes 4 coeurs en lançant des
tâches en parallèle même si toutes celles que je lance ne sont pas
optimisées. Donc on peut très bien tirer parti de son multi-coeurs sans
avoir un seul logiciel optimisé pour le multi-coeur. Portnawak un peu rapide
à mon avis. Et comme j'ai de quoi avoir toujours mes 4 coeurs en fonction,
j'en tire pleinement profit.
Sans être un spécialiste, je suis assez d'accord, quand on voit le
nombre de processus en cours sur un ordinateur, tant windows que Linux,
le multicœur est automatiquement utilisé pour accroitre la rapidité de
la machine car je pense que les processus sont répartis entre les cœurs.
À moins que les OS soient merdiques.
PP , dans le message<4ccd43c2$0$672$, a écrit :Je pense que pour des bibliothèques multimédias ou autres il y a ce
genre d'optimisation, non ?
Oui.Peut-on imaginer par excès, en reprenant ton exemple, des sous
répertoires des répertoire d'architecture pour se rapprocher au plus
près des instructions des processeurs récents.
Les gains deviennent alors négligeables.
PP , dans le message<4ccd43c2$0$672$426a74cc@news.free.fr>, a écrit :
Je pense que pour des bibliothèques multimédias ou autres il y a ce
genre d'optimisation, non ?
Oui.
Peut-on imaginer par excès, en reprenant ton exemple, des sous
répertoires des répertoire d'architecture pour se rapprocher au plus
près des instructions des processeurs récents.
Les gains deviennent alors négligeables.
PP , dans le message<4ccd43c2$0$672$, a écrit :Je pense que pour des bibliothèques multimédias ou autres il y a ce
genre d'optimisation, non ?
Oui.Peut-on imaginer par excès, en reprenant ton exemple, des sous
répertoires des répertoire d'architecture pour se rapprocher au plus
près des instructions des processeurs récents.
Les gains deviennent alors négligeables.
Le Sun, 31 Oct 2010 11:13:37 +0100,
PP écrivait :Le 31/10/2010 11:04, Stéphan Peccini a écrit :pehache-youplaboum wrote:"Tonton Th" a écrit dans le message de news:
4ccd3625$0$1083$Pour faire encore plus simple : pas besoin de logiciel "optimisé"
pour le multi-coeur pour tirer pleinement parti des machines
multi-coeurs. Sauf pour les ancètres qui utilisent des OS
monotaches.Portnawak.
Si un logiciel donné n'a pas été programmé pour faire du parallélisme (que
ce soit en multithreading ou en multiprocessing), il n'utilise qu'un coeur
quoi qu'il arrive.
J'ai des logiciels qui profitent de plusieurs coeurs et d'autres non. Mais
comme mon OS est multi-tâche (je ne suis pas un ancêtre qui utilise un OS
mono-tâche), je peux profiter tout le temps de mes 4 coeurs en lançant des
tâches en parallèle même si toutes celles que je lance ne sont pas
optimisées. Donc on peut très bien tirer parti de son multi-coeurs sans
avoir un seul logiciel optimisé pour le multi-coeur. Portnawak un peu rapide
à mon avis. Et comme j'ai de quoi avoir toujours mes 4 coeurs en fonction,
j'en tire pleinement profit.
Sans être un spécialiste, je suis assez d'accord, quand on voit le
nombre de processus en cours sur un ordinateur, tant windows que Linux,
le multic½ur est automatiquement utilisé pour accroitre la rapidité de
la machine car je pense que les processus sont répartis entre les c½urs.
À moins que les OS soient merdiques.
Ouaips, sauf que là, on peut lancer un troll multicoeurs du pauvre
avec plusieurs coeur sur une même puce contre architecture numa...
Le Sun, 31 Oct 2010 11:13:37 +0100,
PP<000pipantal@free.fr000> écrivait :
Le 31/10/2010 11:04, Stéphan Peccini a écrit :
pehache-youplaboum wrote:
"Tonton Th"<tth@la.bas.invalid> a écrit dans le message de news:
4ccd3625$0$1083$426a74cc@news.free.fr
Pour faire encore plus simple : pas besoin de logiciel "optimisé"
pour le multi-coeur pour tirer pleinement parti des machines
multi-coeurs. Sauf pour les ancètres qui utilisent des OS
monotaches.
Portnawak.
Si un logiciel donné n'a pas été programmé pour faire du parallélisme (que
ce soit en multithreading ou en multiprocessing), il n'utilise qu'un coeur
quoi qu'il arrive.
J'ai des logiciels qui profitent de plusieurs coeurs et d'autres non. Mais
comme mon OS est multi-tâche (je ne suis pas un ancêtre qui utilise un OS
mono-tâche), je peux profiter tout le temps de mes 4 coeurs en lançant des
tâches en parallèle même si toutes celles que je lance ne sont pas
optimisées. Donc on peut très bien tirer parti de son multi-coeurs sans
avoir un seul logiciel optimisé pour le multi-coeur. Portnawak un peu rapide
à mon avis. Et comme j'ai de quoi avoir toujours mes 4 coeurs en fonction,
j'en tire pleinement profit.
Sans être un spécialiste, je suis assez d'accord, quand on voit le
nombre de processus en cours sur un ordinateur, tant windows que Linux,
le multic½ur est automatiquement utilisé pour accroitre la rapidité de
la machine car je pense que les processus sont répartis entre les c½urs.
À moins que les OS soient merdiques.
Ouaips, sauf que là, on peut lancer un troll multicoeurs du pauvre
avec plusieurs coeur sur une même puce contre architecture numa...
Le Sun, 31 Oct 2010 11:13:37 +0100,
PP écrivait :Le 31/10/2010 11:04, Stéphan Peccini a écrit :pehache-youplaboum wrote:"Tonton Th" a écrit dans le message de news:
4ccd3625$0$1083$Pour faire encore plus simple : pas besoin de logiciel "optimisé"
pour le multi-coeur pour tirer pleinement parti des machines
multi-coeurs. Sauf pour les ancètres qui utilisent des OS
monotaches.Portnawak.
Si un logiciel donné n'a pas été programmé pour faire du parallélisme (que
ce soit en multithreading ou en multiprocessing), il n'utilise qu'un coeur
quoi qu'il arrive.
J'ai des logiciels qui profitent de plusieurs coeurs et d'autres non. Mais
comme mon OS est multi-tâche (je ne suis pas un ancêtre qui utilise un OS
mono-tâche), je peux profiter tout le temps de mes 4 coeurs en lançant des
tâches en parallèle même si toutes celles que je lance ne sont pas
optimisées. Donc on peut très bien tirer parti de son multi-coeurs sans
avoir un seul logiciel optimisé pour le multi-coeur. Portnawak un peu rapide
à mon avis. Et comme j'ai de quoi avoir toujours mes 4 coeurs en fonction,
j'en tire pleinement profit.
Sans être un spécialiste, je suis assez d'accord, quand on voit le
nombre de processus en cours sur un ordinateur, tant windows que Linux,
le multic½ur est automatiquement utilisé pour accroitre la rapidité de
la machine car je pense que les processus sont répartis entre les c½urs.
À moins que les OS soient merdiques.
Ouaips, sauf que là, on peut lancer un troll multicoeurs du pauvre
avec plusieurs coeur sur une même puce contre architecture numa...
Le 31/10/2010 12:47, JKB a écrit :Le Sun, 31 Oct 2010 11:13:37 +0100,
PP écrivait :Le 31/10/2010 11:04, Stéphan Peccini a écrit :pehache-youplaboum wrote:"Tonton Th" a écrit dans le message de news:
4ccd3625$0$1083$Pour faire encore plus simple : pas besoin de logiciel "optimisé"
pour le multi-coeur pour tirer pleinement parti des machines
multi-coeurs. Sauf pour les ancètres qui utilisent des OS
monotaches.Portnawak.
Si un logiciel donné n'a pas été programmé pour faire du parallélisme (que
ce soit en multithreading ou en multiprocessing), il n'utilise qu'un coeur
quoi qu'il arrive.
J'ai des logiciels qui profitent de plusieurs coeurs et d'autres non. Mais
comme mon OS est multi-tâche (je ne suis pas un ancêtre qui utilise un OS
mono-tâche), je peux profiter tout le temps de mes 4 coeurs en lançant des
tâches en parallèle même si toutes celles que je lance ne sont pas
optimisées. Donc on peut très bien tirer parti de son multi-coeurs sans
avoir un seul logiciel optimisé pour le multi-coeur. Portnawak un peu rapide
à mon avis. Et comme j'ai de quoi avoir toujours mes 4 coeurs en fonction,
j'en tire pleinement profit.
Sans être un spécialiste, je suis assez d'accord, quand on voit le
nombre de processus en cours sur un ordinateur, tant windows que Linux,
le multicœur est automatiquement utilisé pour accroitre la rapidité de
la machine car je pense que les processus sont répartis entre les cœurs.
À moins que les OS soient merdiques.
Ouaips, sauf que là, on peut lancer un troll multicoeurs du pauvre
avec plusieurs coeur sur une même puce contre architecture numa...
Là on se rapproche de machines indépendantes reliées ensemble dans la
même boite, plus que le multicœeur !
Le 31/10/2010 12:47, JKB a écrit :
Le Sun, 31 Oct 2010 11:13:37 +0100,
PP<000pipantal@free.fr000> écrivait :
Le 31/10/2010 11:04, Stéphan Peccini a écrit :
pehache-youplaboum wrote:
"Tonton Th"<tth@la.bas.invalid> a écrit dans le message de news:
4ccd3625$0$1083$426a74cc@news.free.fr
Pour faire encore plus simple : pas besoin de logiciel "optimisé"
pour le multi-coeur pour tirer pleinement parti des machines
multi-coeurs. Sauf pour les ancètres qui utilisent des OS
monotaches.
Portnawak.
Si un logiciel donné n'a pas été programmé pour faire du parallélisme (que
ce soit en multithreading ou en multiprocessing), il n'utilise qu'un coeur
quoi qu'il arrive.
J'ai des logiciels qui profitent de plusieurs coeurs et d'autres non. Mais
comme mon OS est multi-tâche (je ne suis pas un ancêtre qui utilise un OS
mono-tâche), je peux profiter tout le temps de mes 4 coeurs en lançant des
tâches en parallèle même si toutes celles que je lance ne sont pas
optimisées. Donc on peut très bien tirer parti de son multi-coeurs sans
avoir un seul logiciel optimisé pour le multi-coeur. Portnawak un peu rapide
à mon avis. Et comme j'ai de quoi avoir toujours mes 4 coeurs en fonction,
j'en tire pleinement profit.
Sans être un spécialiste, je suis assez d'accord, quand on voit le
nombre de processus en cours sur un ordinateur, tant windows que Linux,
le multicœur est automatiquement utilisé pour accroitre la rapidité de
la machine car je pense que les processus sont répartis entre les cœurs.
À moins que les OS soient merdiques.
Ouaips, sauf que là, on peut lancer un troll multicoeurs du pauvre
avec plusieurs coeur sur une même puce contre architecture numa...
Là on se rapproche de machines indépendantes reliées ensemble dans la
même boite, plus que le multicœeur !
Le 31/10/2010 12:47, JKB a écrit :Le Sun, 31 Oct 2010 11:13:37 +0100,
PP écrivait :Le 31/10/2010 11:04, Stéphan Peccini a écrit :pehache-youplaboum wrote:"Tonton Th" a écrit dans le message de news:
4ccd3625$0$1083$Pour faire encore plus simple : pas besoin de logiciel "optimisé"
pour le multi-coeur pour tirer pleinement parti des machines
multi-coeurs. Sauf pour les ancètres qui utilisent des OS
monotaches.Portnawak.
Si un logiciel donné n'a pas été programmé pour faire du parallélisme (que
ce soit en multithreading ou en multiprocessing), il n'utilise qu'un coeur
quoi qu'il arrive.
J'ai des logiciels qui profitent de plusieurs coeurs et d'autres non. Mais
comme mon OS est multi-tâche (je ne suis pas un ancêtre qui utilise un OS
mono-tâche), je peux profiter tout le temps de mes 4 coeurs en lançant des
tâches en parallèle même si toutes celles que je lance ne sont pas
optimisées. Donc on peut très bien tirer parti de son multi-coeurs sans
avoir un seul logiciel optimisé pour le multi-coeur. Portnawak un peu rapide
à mon avis. Et comme j'ai de quoi avoir toujours mes 4 coeurs en fonction,
j'en tire pleinement profit.
Sans être un spécialiste, je suis assez d'accord, quand on voit le
nombre de processus en cours sur un ordinateur, tant windows que Linux,
le multicœur est automatiquement utilisé pour accroitre la rapidité de
la machine car je pense que les processus sont répartis entre les cœurs.
À moins que les OS soient merdiques.
Ouaips, sauf que là, on peut lancer un troll multicoeurs du pauvre
avec plusieurs coeur sur une même puce contre architecture numa...
Là on se rapproche de machines indépendantes reliées ensemble dans la
même boite, plus que le multicœeur !
Quand on voit les Intel et AMD "créer" de nouvelles instructions à
chaque génération on peut espérer que ce n'est pas "que" pour soulager
le compilateur !
Quand on voit les Intel et AMD "créer" de nouvelles instructions à
chaque génération on peut espérer que ce n'est pas "que" pour soulager
le compilateur !
Quand on voit les Intel et AMD "créer" de nouvelles instructions à
chaque génération on peut espérer que ce n'est pas "que" pour soulager
le compilateur !