hier je suis tombé sur un truc affirmant que la gentoo par le fait
qu'elle compile les programmes sur mesure de son matériel est plus
performante que les distribution en paquet.
Certes, ça parait évident mais dans quelle mesure ? 5% ? 10% ? plus ?
Il me semble que BSD fait un peu pareil, mais je ne connais pas trop
Le 31/10/2010 11:12 dans fr.comp.os.linux.debats Nicolas George nous expliquait:
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 ?
N'est-ce pas typiquement le cas de Gentoo qui optimise la compilation en fonction de la variable USE définie par l'utilisateur ?
Ce n'est pas totalement automatisé (il faut défnir USE, et ça peut être long pour une définition précise), mais efficace.
Après, pour le gain réèl de performances Vs temps de comilation, man time ! -- @+ Doug - Linux user #307925 - Slackware64 roulaize ;-) Usenet-fr ? Mais qu'est-ce que c'est ? Pour en savoir plus : http://www.dougwise.org/wiki
Le 31/10/2010 11:12 dans fr.comp.os.linux.debats Nicolas George nous
expliquait:
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 ?
N'est-ce pas typiquement le cas de Gentoo qui optimise la compilation en
fonction de la variable USE définie par l'utilisateur ?
Ce n'est pas totalement automatisé (il faut défnir USE, et ça peut être
long pour une définition précise), mais efficace.
Après, pour le gain réèl de performances Vs temps de comilation, man
time !
--
@+
Doug - Linux user #307925 - Slackware64 roulaize ;-)
Usenet-fr ? Mais qu'est-ce que c'est ?
Pour en savoir plus : http://www.dougwise.org/wiki
Le 31/10/2010 11:12 dans fr.comp.os.linux.debats Nicolas George nous expliquait:
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 ?
N'est-ce pas typiquement le cas de Gentoo qui optimise la compilation en fonction de la variable USE définie par l'utilisateur ?
Ce n'est pas totalement automatisé (il faut défnir USE, et ça peut être long pour une définition précise), mais efficace.
Après, pour le gain réèl de performances Vs temps de comilation, man time ! -- @+ Doug - Linux user #307925 - Slackware64 roulaize ;-) Usenet-fr ? Mais qu'est-ce que c'est ? Pour en savoir plus : http://www.dougwise.org/wiki
stephane.carpentier
wrote:
Ce qui apporte des performances, c'est lorsque les logiciels utiisent des fonctions avancées des processeurs,
Non. C'est à l'OS de gérer le processeur. Que Windows soit trop nul pour faire son travail oblige les logiciels à faire ce qu'ils n'ont pas à faire.
Les logiciels multimédias et les jeux sont souvent optimisés pour tirer partis des nouvelles technologies, et avec raisons
Oui, la raison, c'est que Windows ne fait pas son travail. Il y a quelques années, c'était aux jeux sous DOS de gérer les cartes son, les joysticks et autres souris. C'était quand même une aberration.
Mais pour la plupart des programmes, ca n'a que peu de sens, voire pas de sens du tout
Voilà. Le programme, il n'a pas à connaître la marque de la carte graphique ou le nombre de processeurs de l'ordinateur sur lequel il tourne.
wrote:
Ce qui apporte des performances, c'est lorsque les logiciels utiisent
des fonctions avancées des processeurs,
Non. C'est à l'OS de gérer le processeur. Que Windows soit trop nul pour
faire son travail oblige les logiciels à faire ce qu'ils n'ont pas à faire.
Les logiciels multimédias et les jeux sont souvent optimisés pour tirer
partis des nouvelles technologies, et avec raisons
Oui, la raison, c'est que Windows ne fait pas son travail. Il y a quelques
années, c'était aux jeux sous DOS de gérer les cartes son, les joysticks et
autres souris. C'était quand même une aberration.
Mais pour la plupart des programmes, ca n'a que peu de sens, voire pas
de sens du tout
Voilà. Le programme, il n'a pas à connaître la marque de la carte graphique
ou le nombre de processeurs de l'ordinateur sur lequel il tourne.
Ce qui apporte des performances, c'est lorsque les logiciels utiisent des fonctions avancées des processeurs,
Non. C'est à l'OS de gérer le processeur. Que Windows soit trop nul pour faire son travail oblige les logiciels à faire ce qu'ils n'ont pas à faire.
Les logiciels multimédias et les jeux sont souvent optimisés pour tirer partis des nouvelles technologies, et avec raisons
Oui, la raison, c'est que Windows ne fait pas son travail. Il y a quelques années, c'était aux jeux sous DOS de gérer les cartes son, les joysticks et autres souris. C'était quand même une aberration.
Mais pour la plupart des programmes, ca n'a que peu de sens, voire pas de sens du tout
Voilà. Le programme, il n'a pas à connaître la marque de la carte graphique ou le nombre de processeurs de l'ordinateur sur lequel il tourne.
pehache-youplaboum
a écrit dans le message de news: 4ccd6a02$0$10234$
wrote:
Ce qui apporte des performances, c'est lorsque les logiciels utiisent des fonctions avancées des processeurs,
Non. C'est à l'OS de gérer le processeur. Que Windows soit trop nul pour faire son travail oblige les logiciels à faire ce qu'ils n'ont pas à faire.
L'OS ne peut pas remédier à tout ce qui n'a pas été prévu au moment du dévelopement.
Les logiciels multimédias et les jeux sont souvent optimisés pour tirer partis des nouvelles technologies, et avec raisons
Oui, la raison, c'est que Windows ne fait pas son travail. Il y a quelques années, c'était aux jeux sous DOS de gérer les cartes son, les joysticks et autres souris. C'était quand même une aberration.
Ils n'étaient pas /obligés/. Ils le faisaient parce que les développeurs considéraient, à tort ou raison, que les drivers inclus dans DOS n'étaient pas suffisamment bons pour les jeux.
Mais pour la plupart des programmes, ca n'a que peu de sens, voire pas de sens du tout
Voilà. Le programme, il n'a pas à connaître la marque de la carte graphique ou le nombre de processeurs de l'ordinateur sur lequel il tourne.
Pour la carte graphique, sans doute. A condition que le driver intégré au système soit suffisamment bon.
Pour le nombre de processeurs c'est faux. Il y a des cas où il vaut mieux que le programme sache combien de coeurs/CPU sont disponibles, et ça n'a rien à voir avec la qualité de l'OS.
-- pehache http://pehache.free.fr
<stephane.carpentier@free.fr> a écrit dans le message de news:
4ccd6a02$0$10234$426a74cc@news.free.fr
wrote:
Ce qui apporte des performances, c'est lorsque les logiciels utiisent
des fonctions avancées des processeurs,
Non. C'est à l'OS de gérer le processeur. Que Windows soit trop nul
pour faire son travail oblige les logiciels à faire ce qu'ils n'ont
pas à faire.
L'OS ne peut pas remédier à tout ce qui n'a pas été prévu au moment du
dévelopement.
Les logiciels multimédias et les jeux sont souvent optimisés pour
tirer partis des nouvelles technologies, et avec raisons
Oui, la raison, c'est que Windows ne fait pas son travail. Il y a
quelques années, c'était aux jeux sous DOS de gérer les cartes son,
les joysticks et autres souris. C'était quand même une aberration.
Ils n'étaient pas /obligés/. Ils le faisaient parce que les développeurs
considéraient, à tort ou raison, que les drivers inclus dans DOS n'étaient
pas suffisamment bons pour les jeux.
Mais pour la plupart des programmes, ca n'a que peu de sens, voire
pas de sens du tout
Voilà. Le programme, il n'a pas à connaître la marque de la carte
graphique ou le nombre de processeurs de l'ordinateur sur lequel il
tourne.
Pour la carte graphique, sans doute. A condition que le driver intégré au
système soit suffisamment bon.
Pour le nombre de processeurs c'est faux. Il y a des cas où il vaut mieux
que le programme sache combien de coeurs/CPU sont disponibles, et ça n'a
rien à voir avec la qualité de l'OS.
a écrit dans le message de news: 4ccd6a02$0$10234$
wrote:
Ce qui apporte des performances, c'est lorsque les logiciels utiisent des fonctions avancées des processeurs,
Non. C'est à l'OS de gérer le processeur. Que Windows soit trop nul pour faire son travail oblige les logiciels à faire ce qu'ils n'ont pas à faire.
L'OS ne peut pas remédier à tout ce qui n'a pas été prévu au moment du dévelopement.
Les logiciels multimédias et les jeux sont souvent optimisés pour tirer partis des nouvelles technologies, et avec raisons
Oui, la raison, c'est que Windows ne fait pas son travail. Il y a quelques années, c'était aux jeux sous DOS de gérer les cartes son, les joysticks et autres souris. C'était quand même une aberration.
Ils n'étaient pas /obligés/. Ils le faisaient parce que les développeurs considéraient, à tort ou raison, que les drivers inclus dans DOS n'étaient pas suffisamment bons pour les jeux.
Mais pour la plupart des programmes, ca n'a que peu de sens, voire pas de sens du tout
Voilà. Le programme, il n'a pas à connaître la marque de la carte graphique ou le nombre de processeurs de l'ordinateur sur lequel il tourne.
Pour la carte graphique, sans doute. A condition que le driver intégré au système soit suffisamment bon.
Pour le nombre de processeurs c'est faux. Il y a des cas où il vaut mieux que le programme sache combien de coeurs/CPU sont disponibles, et ça n'a rien à voir avec la qualité de l'OS.
-- pehache http://pehache.free.fr
ST
On 10/31/10 9:20 PM, pehache-youplaboum wrote:
L'OS ne peut pas remédier à tout ce qui n'a pas été prévu au moment du dévelopement.
En meme temps, si on a pas prevu un multi-coeur au niveau de l'OS ...
Ils n'étaient pas /obligés/. Ils le faisaient parce que les développeurs considéraient, à tort ou raison, que les drivers inclus dans DOS n'étaient pas suffisamment bons pour les jeux.
De mémoire, il me semble bien que si. D'ailleurs, le DOS n'etait pas un OS, c'etait juste une CLI pour lancer des trucs sur la machine.
On 10/31/10 9:20 PM, pehache-youplaboum wrote:
L'OS ne peut pas remédier à tout ce qui n'a pas été prévu au moment du
dévelopement.
En meme temps, si on a pas prevu un multi-coeur au niveau de l'OS ...
Ils n'étaient pas /obligés/. Ils le faisaient parce que les développeurs
considéraient, à tort ou raison, que les drivers inclus dans DOS
n'étaient pas suffisamment bons pour les jeux.
De mémoire, il me semble bien que si. D'ailleurs, le DOS n'etait pas un
OS, c'etait juste une CLI pour lancer des trucs sur la machine.
L'OS ne peut pas remédier à tout ce qui n'a pas été prévu au moment du dévelopement.
En meme temps, si on a pas prevu un multi-coeur au niveau de l'OS ...
Ils n'étaient pas /obligés/. Ils le faisaient parce que les développeurs considéraient, à tort ou raison, que les drivers inclus dans DOS n'étaient pas suffisamment bons pour les jeux.
De mémoire, il me semble bien que si. D'ailleurs, le DOS n'etait pas un OS, c'etait juste une CLI pour lancer des trucs sur la machine.
stephane.carpentier
pehache-youplaboum wrote:
a écrit dans le message de news: 4ccd6a02$0$10234$
wrote:
Ce qui apporte des performances, c'est lorsque les logiciels utiisent des fonctions avancées des processeurs,
Non. C'est à l'OS de gérer le processeur. Que Windows soit trop nul pour faire son travail oblige les logiciels à faire ce qu'ils n'ont pas à faire.
L'OS ne peut pas remédier à tout ce qui n'a pas été prévu au moment du dévelopement.
Si déjà Windows s'occupait correctement de ce qui existe au moment de son développement, ce serait une grande avancée.
Mais pour la plupart des programmes, ca n'a que peu de sens, voire pas de sens du tout
Voilà. Le programme, il n'a pas à connaître la marque de la carte graphique ou le nombre de processeurs de l'ordinateur sur lequel il tourne.
Pour la carte graphique, sans doute. A condition que le driver intégré au système soit suffisamment bon.
Pour le nombre de processeurs c'est faux. Il y a des cas où il vaut mieux que le programme sache combien de coeurs/CPU sont disponibles, et ça n'a rien à voir avec la qualité de l'OS.
Il doit le savoir quand ? Ça peut changer au cours de l'exécution du programme.
pehache-youplaboum wrote:
<stephane.carpentier@free.fr> a écrit dans le message de news:
4ccd6a02$0$10234$426a74cc@news.free.fr
wrote:
Ce qui apporte des performances, c'est lorsque les logiciels utiisent
des fonctions avancées des processeurs,
Non. C'est à l'OS de gérer le processeur. Que Windows soit trop nul
pour faire son travail oblige les logiciels à faire ce qu'ils n'ont
pas à faire.
L'OS ne peut pas remédier à tout ce qui n'a pas été prévu au moment du
dévelopement.
Si déjà Windows s'occupait correctement de ce qui existe au moment de son
développement, ce serait une grande avancée.
Mais pour la plupart des programmes, ca n'a que peu de sens, voire
pas de sens du tout
Voilà. Le programme, il n'a pas à connaître la marque de la carte
graphique ou le nombre de processeurs de l'ordinateur sur lequel il
tourne.
Pour la carte graphique, sans doute. A condition que le driver intégré au
système soit suffisamment bon.
Pour le nombre de processeurs c'est faux. Il y a des cas où il vaut mieux
que le programme sache combien de coeurs/CPU sont disponibles, et ça n'a
rien à voir avec la qualité de l'OS.
Il doit le savoir quand ? Ça peut changer au cours de l'exécution du
programme.
a écrit dans le message de news: 4ccd6a02$0$10234$
wrote:
Ce qui apporte des performances, c'est lorsque les logiciels utiisent des fonctions avancées des processeurs,
Non. C'est à l'OS de gérer le processeur. Que Windows soit trop nul pour faire son travail oblige les logiciels à faire ce qu'ils n'ont pas à faire.
L'OS ne peut pas remédier à tout ce qui n'a pas été prévu au moment du dévelopement.
Si déjà Windows s'occupait correctement de ce qui existe au moment de son développement, ce serait une grande avancée.
Mais pour la plupart des programmes, ca n'a que peu de sens, voire pas de sens du tout
Voilà. Le programme, il n'a pas à connaître la marque de la carte graphique ou le nombre de processeurs de l'ordinateur sur lequel il tourne.
Pour la carte graphique, sans doute. A condition que le driver intégré au système soit suffisamment bon.
Pour le nombre de processeurs c'est faux. Il y a des cas où il vaut mieux que le programme sache combien de coeurs/CPU sont disponibles, et ça n'a rien à voir avec la qualité de l'OS.
Il doit le savoir quand ? Ça peut changer au cours de l'exécution du programme.
Tonton Th
On 10/31/2010 10:44 AM, pehache-youplaboum wrote:
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.
Portnawak toi-même.
Les machines modernes utilisant des OS modernes (mais est-ce ton cas ?) font tourner plusieurs programmes quasi-simultanéments : un Tbird, un Xchat, un WM, un mocp, et que sais-je encore ?
Donc, il me semble qu'un multi-coeur ne peut être que profitable.
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
On 10/31/2010 10:44 AM, pehache-youplaboum wrote:
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.
Portnawak toi-même.
Les machines modernes utilisant des OS modernes (mais est-ce ton
cas ?) font tourner plusieurs programmes quasi-simultanéments :
un Tbird, un Xchat, un WM, un mocp, et que sais-je encore ?
Donc, il me semble qu'un multi-coeur ne peut être que profitable.
--
Ma coiffeuse est formidable - http://sonia.buvette.org/
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.
Portnawak toi-même.
Les machines modernes utilisant des OS modernes (mais est-ce ton cas ?) font tourner plusieurs programmes quasi-simultanéments : un Tbird, un Xchat, un WM, un mocp, et que sais-je encore ?
Donc, il me semble qu'un multi-coeur ne peut être que profitable.
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
Tonton Th
On 10/31/2010 12:47 PM, JKB wrote:
Ouaips, sauf que là, on peut lancer un troll multicoeurs du pauvre avec plusieurs coeur sur une même puce contre architecture numa...
Toi aussi, tu songes à ce que peuvent imaginer les chinois avec leurs MIPS à trois balles, et leur force d'innovation ?
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
On 10/31/2010 12:47 PM, JKB wrote:
Ouaips, sauf que là, on peut lancer un troll multicoeurs du pauvre
avec plusieurs coeur sur une même puce contre architecture numa...
Toi aussi, tu songes à ce que peuvent imaginer les chinois avec
leurs MIPS à trois balles, et leur force d'innovation ?
--
Ma coiffeuse est formidable - http://sonia.buvette.org/
Ouaips, sauf que là, on peut lancer un troll multicoeurs du pauvre avec plusieurs coeur sur une même puce contre architecture numa...
Pour un usage personnel ou uniquement pour un usage professionnel ?
Que pourrait m'apporter une architecture numa pour les traitement des mes très gros panoramas (qui mettent à genou ma configuration) ?
-- Stéphan Peccini Le blog : <URL:http://pyrenees.peccini.fr> Les photos : <URL:http://photonature.fr>
JKB
Le Sun, 31 Oct 2010 15:59:47 +0100, Tonton Th écrivait :
On 10/31/2010 12:47 PM, JKB wrote:
Ouaips, sauf que là, on peut lancer un troll multicoeurs du pauvre avec plusieurs coeur sur une même puce contre architecture numa...
Toi aussi, tu songes à ce que peuvent imaginer les chinois avec leurs MIPS à trois balles, et leur force d'innovation ?
Je pense que lorsqu'on sera dans le mur avec nos x86 et l'architecture toute moisie qui va avec eux, on verra apparaître comme par magie quelque chose de radicalement différent. Je ne sais pas si ce sera MIPS ou une résurection d'une autre architecture style alpha, Sparc ou ppc, mais l'avenir du multicoeur me semble plutôt du côté NUMA avec processeurs ridicules à un ou deux coeurs que du côté processeurs à 16 ou 32 coeurs. Bon, ça, c'est la technique, les marketteux vont bien réussir à faire accroire à madame michu qu'un i726 à 512 coeurs, ça lave vachement plus blanc que son i7 qu'elle n'utilise qu'à 2% de ses capacités.
Augmenter le nombre de coeurs sur la même puce est aberrant car il faut en même temps augmenter considérablement la taille des caches internes pour limiter les goulots d'étranglement vers la mémoire centrale. Tu rajoutes aussi un tas de défauts de pages à gérer et au final, ton processeur est un grille-pain pour des performances qui n'atteindront jamais un système NUMA classique (qui en terme de coût ne sera pas plus cher).
Et ça, les chinois l'ont bien compris puisque leur dernière création est un truc qui est en première approche une grappe de systèmes NUMA ridiculement simples.
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 Sun, 31 Oct 2010 15:59:47 +0100,
Tonton Th <tth@la.bas.invalid> écrivait :
On 10/31/2010 12:47 PM, JKB wrote:
Ouaips, sauf que là, on peut lancer un troll multicoeurs du pauvre
avec plusieurs coeur sur une même puce contre architecture numa...
Toi aussi, tu songes à ce que peuvent imaginer les chinois avec
leurs MIPS à trois balles, et leur force d'innovation ?
Je pense que lorsqu'on sera dans le mur avec nos x86 et
l'architecture toute moisie qui va avec eux, on verra apparaître
comme par magie quelque chose de radicalement différent. Je ne sais
pas si ce sera MIPS ou une résurection d'une autre architecture
style alpha, Sparc ou ppc, mais l'avenir du multicoeur me semble plutôt
du côté NUMA avec processeurs ridicules à un ou deux coeurs que du côté
processeurs à 16 ou 32 coeurs. Bon, ça, c'est la technique, les
marketteux vont bien réussir à faire accroire à madame michu qu'un
i726 à 512 coeurs, ça lave vachement plus blanc que son i7 qu'elle
n'utilise qu'à 2% de ses capacités.
Augmenter le nombre de coeurs sur la même puce est aberrant car il
faut en même temps augmenter considérablement la taille des caches
internes pour limiter les goulots d'étranglement vers la mémoire
centrale. Tu rajoutes aussi un tas de défauts de pages à gérer et au
final, ton processeur est un grille-pain pour des performances qui
n'atteindront jamais un système NUMA classique (qui en terme de coût
ne sera pas plus cher).
Et ça, les chinois l'ont bien compris puisque leur dernière création
est un truc qui est en première approche une grappe de systèmes NUMA
ridiculement simples.
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 Sun, 31 Oct 2010 15:59:47 +0100, Tonton Th écrivait :
On 10/31/2010 12:47 PM, JKB wrote:
Ouaips, sauf que là, on peut lancer un troll multicoeurs du pauvre avec plusieurs coeur sur une même puce contre architecture numa...
Toi aussi, tu songes à ce que peuvent imaginer les chinois avec leurs MIPS à trois balles, et leur force d'innovation ?
Je pense que lorsqu'on sera dans le mur avec nos x86 et l'architecture toute moisie qui va avec eux, on verra apparaître comme par magie quelque chose de radicalement différent. Je ne sais pas si ce sera MIPS ou une résurection d'une autre architecture style alpha, Sparc ou ppc, mais l'avenir du multicoeur me semble plutôt du côté NUMA avec processeurs ridicules à un ou deux coeurs que du côté processeurs à 16 ou 32 coeurs. Bon, ça, c'est la technique, les marketteux vont bien réussir à faire accroire à madame michu qu'un i726 à 512 coeurs, ça lave vachement plus blanc que son i7 qu'elle n'utilise qu'à 2% de ses capacités.
Augmenter le nombre de coeurs sur la même puce est aberrant car il faut en même temps augmenter considérablement la taille des caches internes pour limiter les goulots d'étranglement vers la mémoire centrale. Tu rajoutes aussi un tas de défauts de pages à gérer et au final, ton processeur est un grille-pain pour des performances qui n'atteindront jamais un système NUMA classique (qui en terme de coût ne sera pas plus cher).
Et ça, les chinois l'ont bien compris puisque leur dernière création est un truc qui est en première approche une grappe de systèmes NUMA ridiculement simples.
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
PP
Le 31/10/2010 13:24, JKB a écrit :
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 !
Certes, mais tu peux avoir une architecture NUMA sur une bête carte-mère ATX. Ça réduit d'autant les goulets d'étranglement.
Peut-être mais je parlais en terme d'image.
Le 31/10/2010 13:24, JKB a écrit :
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 !
Certes, mais tu peux avoir une architecture NUMA sur une bête
carte-mère ATX. Ça réduit d'autant les goulets d'étranglement.
