La semaine dernière, pour cause de machine grillée par la chaleur,
je me suis trouvé devant la quasi obligation d'acheter un nouveau
portable. Samedi matin ? Oké, en roote. Direction la FNAC. Pfeeuuu.
Arrivé là-bas, je commence à mater les petites calculettes : Acer,
Asus, machins "netbooks". Mouais, rien vu qui me tente...
Je fais un tour chez Darty, je rematte les gadgets, toujours meeee.
Alors, je retourne à la FNAC, je re-regarde, et finalement, je vois
un truc (un HP, je crois) qui me plait un peu. Hop, je fonce vers un
"vendeur", et le lui débite : "M'sieur, j'veux acheter le truc, là,
pi j'veux un lecteur dévédé, pi une jolie souris, mais j'veux pas
windows, parce que ça pue le paté moisi". Client normale, je suis.
Ah ah ah mais non. Pour _avoir_ le droit de claquer 400E à la FNAC,
faut acheter (à un prix inconnaissable) un gros tas de code mal
branlé et inutile. Donc, /ME "Bande d'enculés !", et zeeeee...
Arrivé (de nouveau) chez Darty, je fais rapidement le tour du rayon
des twinkies, Je matte les détails qui comptent, et je choisis un
Acer inspire-one, dont l'étiquette promet "rembousement OS : oui".
Je clicke sur un vendeur, je lui sort le même discours, on arrive
vite à faire affaire, et je demande le reboursement de la taxe, en
esperant être par la même occasion rayé de la liste.
Fail : Chez Darty, pour se faire rembourser l'impot des merdes de
Redmont, il faut renvoyer la machine au SAV de Microsoft, qui va
la garder deux mois. Deux mois. DEUX MOIS !
Alors qu'une logique élémentaire semble dire que si tu va craquer une
fortune dans un "dinateur, c'est pour l'utiliser de suite. Mais non.
Il faut DEUX MOIS à Microsoft pour virer XP d'un aspire-one. C"est
vraiment des baltringues chez M$.
J'ai craqué, j'ai payé, j'ai une machine qui marche bien, qui me
permet d'essayer le dernier Gnome (ça, c'est un autre troll) et
de faire mes trucs indispensables, dont j'avais besion de suite.
Je suis confus, j'ai honte, mais si un jour je rencontre un employé
de <biiiip>, j'aurais un plaisir immense à lui claquer son clapet.
Le 18/7/2010 21:33 dans fr.comp.os.linux.debats Jerome Lambert nous expliquait:
Par contre tu peux tenter l'expérience en te disant qu'au cas où, il est très facile de remplacer Mac OS X par Linux.
Ce n'est pas ce que semblait dire récemment YBM ou PK (je ne sais plus).
Eux veulent installer Linux sur un disque externe au lieu de repartitionner le disque interne, donc forcément ils cumulent les difficultés. Par contre en dual-boot, ça fonctionne très bien: https://help.ubuntu.com/community/MacBook et plus précisément (pour moi): https://help.ubuntu.com/community/MacBook5-2/Lucid qui me dit que presque tout fonctionne "out-of-the-box"
Doug713705 a écrit :
Le 18/7/2010 21:33 dans fr.comp.os.linux.debats Jerome Lambert nous
expliquait:
Par contre tu peux tenter l'expérience en te disant qu'au cas où, il est
très facile de remplacer Mac OS X par Linux.
Ce n'est pas ce que semblait dire récemment YBM ou PK (je ne sais plus).
Eux veulent installer Linux sur un disque externe au lieu de
repartitionner le disque interne, donc forcément ils cumulent les
difficultés.
Par contre en dual-boot, ça fonctionne très bien:
https://help.ubuntu.com/community/MacBook
et plus précisément (pour moi):
https://help.ubuntu.com/community/MacBook5-2/Lucid
qui me dit que presque tout fonctionne "out-of-the-box"
Le 18/7/2010 21:33 dans fr.comp.os.linux.debats Jerome Lambert nous expliquait:
Par contre tu peux tenter l'expérience en te disant qu'au cas où, il est très facile de remplacer Mac OS X par Linux.
Ce n'est pas ce que semblait dire récemment YBM ou PK (je ne sais plus).
Eux veulent installer Linux sur un disque externe au lieu de repartitionner le disque interne, donc forcément ils cumulent les difficultés. Par contre en dual-boot, ça fonctionne très bien: https://help.ubuntu.com/community/MacBook et plus précisément (pour moi): https://help.ubuntu.com/community/MacBook5-2/Lucid qui me dit que presque tout fonctionne "out-of-the-box"
JKB
Le Mon, 19 Jul 2010 18:37:29 +0200, Jo Kerr écrivait :
JKB a utilisé son clavier pour écrire :
Le Mon, 19 Jul 2010 18:25:33 +0200, Jo Kerr écrivait :
JKB a couché sur son écran :
Le problème est d'avoir un code optimisé et massivement multithreadé, car si le T1 est mauvais en monothread, c'est un très bon processeur dès qu'on l'utilise correctement. Le facteur est d'à peu près deux entre un T1/1 GHz et un T7500 à 2,2 GHz. Le T2 est largement meilleur et tourne à 1,6 GHz sans consommer plus.
AMHA il doit être possible d'optimiser aussi pour x86. Peut-être avec les outils/compilateurs de chez Intel. Ils devraient savoir comment fonctionnent leurs bébés.
Pas possible. Lorsque tu optimises un code pour un T1, tu pars du principe qu'il y a 32 threads en parallèle. Et ce n'est pas avec un compilateur que tu obtiens le meilleur résultat, mais en utilisant des choses comme la libpthread. Explique-moi comment tu fais entrer 32 threads parallèles sur un x86 (je parle naturellement d'une génération identique, parce qu'un T2+, ça fait négligemment 256 threads).
JKB
Pour le moment je ne t'expliquerai rien. Je ne suis pas développeur professionnel. Mais pour les longues soirées d'hiver je m'informerai avec la littérature Intel: http://img.delivery.net/cm50content/intel/ProductLibrary/100407_Parallel_Programming_01.pdf http://img.delivery.net/cm50content/intel/ProductLibrary/100412_Parallel_Programming_02.pdf
Tu réponds à côté de la plaque. Je n'ai jamais dit qu'il n'était pas possible d'optimiser du code sur x86.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours. => http://grincheux.de-charybde-en-scylla.fr
Le Mon, 19 Jul 2010 18:37:29 +0200,
Jo Kerr <jo.kerr@jo.invalid> écrivait :
JKB a utilisé son clavier pour écrire :
Le Mon, 19 Jul 2010 18:25:33 +0200,
Jo Kerr <jo.kerr@jo.invalid> écrivait :
JKB a couché sur son écran :
Le problème est d'avoir un code optimisé et massivement
multithreadé, car si le T1 est mauvais en monothread, c'est un très
bon processeur dès qu'on l'utilise correctement. Le facteur est d'à
peu près deux entre un T1/1 GHz et un T7500 à 2,2 GHz. Le T2 est
largement meilleur et tourne à 1,6 GHz sans consommer plus.
AMHA il doit être possible d'optimiser aussi pour x86. Peut-être avec
les outils/compilateurs de chez Intel. Ils devraient savoir comment
fonctionnent leurs bébés.
Pas possible. Lorsque tu optimises un code pour un T1, tu pars du
principe qu'il y a 32 threads en parallèle. Et ce n'est pas avec un
compilateur que tu obtiens le meilleur résultat, mais en utilisant
des choses comme la libpthread. Explique-moi comment tu fais entrer
32 threads parallèles sur un x86 (je parle naturellement d'une
génération identique, parce qu'un T2+, ça fait négligemment 256
threads).
JKB
Pour le moment je ne t'expliquerai rien. Je ne suis pas développeur
professionnel. Mais pour les longues soirées d'hiver je m'informerai
avec la littérature Intel:
http://img.delivery.net/cm50content/intel/ProductLibrary/100407_Parallel_Programming_01.pdf
http://img.delivery.net/cm50content/intel/ProductLibrary/100412_Parallel_Programming_02.pdf
Tu réponds à côté de la plaque. Je n'ai jamais dit qu'il n'était pas
possible d'optimiser du code sur x86.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
=> http://grincheux.de-charybde-en-scylla.fr
Le Mon, 19 Jul 2010 18:37:29 +0200, Jo Kerr écrivait :
JKB a utilisé son clavier pour écrire :
Le Mon, 19 Jul 2010 18:25:33 +0200, Jo Kerr écrivait :
JKB a couché sur son écran :
Le problème est d'avoir un code optimisé et massivement multithreadé, car si le T1 est mauvais en monothread, c'est un très bon processeur dès qu'on l'utilise correctement. Le facteur est d'à peu près deux entre un T1/1 GHz et un T7500 à 2,2 GHz. Le T2 est largement meilleur et tourne à 1,6 GHz sans consommer plus.
AMHA il doit être possible d'optimiser aussi pour x86. Peut-être avec les outils/compilateurs de chez Intel. Ils devraient savoir comment fonctionnent leurs bébés.
Pas possible. Lorsque tu optimises un code pour un T1, tu pars du principe qu'il y a 32 threads en parallèle. Et ce n'est pas avec un compilateur que tu obtiens le meilleur résultat, mais en utilisant des choses comme la libpthread. Explique-moi comment tu fais entrer 32 threads parallèles sur un x86 (je parle naturellement d'une génération identique, parce qu'un T2+, ça fait négligemment 256 threads).
JKB
Pour le moment je ne t'expliquerai rien. Je ne suis pas développeur professionnel. Mais pour les longues soirées d'hiver je m'informerai avec la littérature Intel: http://img.delivery.net/cm50content/intel/ProductLibrary/100407_Parallel_Programming_01.pdf http://img.delivery.net/cm50content/intel/ProductLibrary/100412_Parallel_Programming_02.pdf
Tu réponds à côté de la plaque. Je n'ai jamais dit qu'il n'était pas possible d'optimiser du code sur x86.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours. => http://grincheux.de-charybde-en-scylla.fr
Jo Kerr
JKB a exprimé avec précision :
Le Mon, 19 Jul 2010 18:37:29 +0200, Jo Kerr écrivait :
JKB a utilisé son clavier pour écrire :
Le Mon, 19 Jul 2010 18:25:33 +0200, Jo Kerr écrivait :
JKB a couché sur son écran :
Le problème est d'avoir un code optimisé et massivement multithreadé, car si le T1 est mauvais en monothread, c'est un très bon processeur dès qu'on l'utilise correctement. Le facteur est d'à peu près deux entre un T1/1 GHz et un T7500 à 2,2 GHz. Le T2 est largement meilleur et tourne à 1,6 GHz sans consommer plus.
AMHA il doit être possible d'optimiser aussi pour x86. Peut-être avec les outils/compilateurs de chez Intel. Ils devraient savoir comment fonctionnent leurs bébés.
Pas possible. Lorsque tu optimises un code pour un T1, tu pars du principe qu'il y a 32 threads en parallèle. Et ce n'est pas avec un compilateur que tu obtiens le meilleur résultat, mais en utilisant des choses comme la libpthread. Explique-moi comment tu fais entrer 32 threads parallèles sur un x86 (je parle naturellement d'une génération identique, parce qu'un T2+, ça fait négligemment 256 threads).
JKB
Pour le moment je ne t'expliquerai rien. Je ne suis pas développeur professionnel. Mais pour les longues soirées d'hiver je m'informerai avec la littérature Intel: http://img.delivery.net/cm50content/intel/ProductLibrary/100407_Parallel_Programming_01.pdf http://img.delivery.net/cm50content/intel/ProductLibrary/100412_Parallel_Programming_02.pdf
Tu réponds à côté de la plaque. Je n'ai jamais dit qu'il n'était pas possible d'optimiser du code sur x86.
JKB
??? Tu réponds 'pas possible'. Dans ce cas 'pas possible' quoi ?? Tu me dis 'explique-moi', je réponds que je ne peux rien t'expliquer puisque je ne suis pas et ne me prétends pas pro de la programmation. Où est ma réponse à côté de la plaque ? J'avoue avoir un peu de mal à te comprendre.
-- In gold we trust (c)
JKB a exprimé avec précision :
Le Mon, 19 Jul 2010 18:37:29 +0200,
Jo Kerr <jo.kerr@jo.invalid> écrivait :
JKB a utilisé son clavier pour écrire :
Le Mon, 19 Jul 2010 18:25:33 +0200,
Jo Kerr <jo.kerr@jo.invalid> écrivait :
JKB a couché sur son écran :
Le problème est d'avoir un code optimisé et massivement
multithreadé, car si le T1 est mauvais en monothread, c'est un très
bon processeur dès qu'on l'utilise correctement. Le facteur est d'à
peu près deux entre un T1/1 GHz et un T7500 à 2,2 GHz. Le T2 est
largement meilleur et tourne à 1,6 GHz sans consommer plus.
AMHA il doit être possible d'optimiser aussi pour x86. Peut-être avec
les outils/compilateurs de chez Intel. Ils devraient savoir comment
fonctionnent leurs bébés.
Pas possible. Lorsque tu optimises un code pour un T1, tu pars du
principe qu'il y a 32 threads en parallèle. Et ce n'est pas avec un
compilateur que tu obtiens le meilleur résultat, mais en utilisant
des choses comme la libpthread. Explique-moi comment tu fais entrer
32 threads parallèles sur un x86 (je parle naturellement d'une
génération identique, parce qu'un T2+, ça fait négligemment 256
threads).
JKB
Pour le moment je ne t'expliquerai rien. Je ne suis pas développeur
professionnel. Mais pour les longues soirées d'hiver je m'informerai
avec la littérature Intel:
http://img.delivery.net/cm50content/intel/ProductLibrary/100407_Parallel_Programming_01.pdf
http://img.delivery.net/cm50content/intel/ProductLibrary/100412_Parallel_Programming_02.pdf
Tu réponds à côté de la plaque. Je n'ai jamais dit qu'il n'était pas
possible d'optimiser du code sur x86.
JKB
???
Tu réponds 'pas possible'. Dans ce cas 'pas possible' quoi ??
Tu me dis 'explique-moi', je réponds que je ne peux rien t'expliquer
puisque je ne suis pas et ne me prétends pas pro de la programmation.
Où est ma réponse à côté de la plaque ?
J'avoue avoir un peu de mal à te comprendre.
Le Mon, 19 Jul 2010 18:37:29 +0200, Jo Kerr écrivait :
JKB a utilisé son clavier pour écrire :
Le Mon, 19 Jul 2010 18:25:33 +0200, Jo Kerr écrivait :
JKB a couché sur son écran :
Le problème est d'avoir un code optimisé et massivement multithreadé, car si le T1 est mauvais en monothread, c'est un très bon processeur dès qu'on l'utilise correctement. Le facteur est d'à peu près deux entre un T1/1 GHz et un T7500 à 2,2 GHz. Le T2 est largement meilleur et tourne à 1,6 GHz sans consommer plus.
AMHA il doit être possible d'optimiser aussi pour x86. Peut-être avec les outils/compilateurs de chez Intel. Ils devraient savoir comment fonctionnent leurs bébés.
Pas possible. Lorsque tu optimises un code pour un T1, tu pars du principe qu'il y a 32 threads en parallèle. Et ce n'est pas avec un compilateur que tu obtiens le meilleur résultat, mais en utilisant des choses comme la libpthread. Explique-moi comment tu fais entrer 32 threads parallèles sur un x86 (je parle naturellement d'une génération identique, parce qu'un T2+, ça fait négligemment 256 threads).
JKB
Pour le moment je ne t'expliquerai rien. Je ne suis pas développeur professionnel. Mais pour les longues soirées d'hiver je m'informerai avec la littérature Intel: http://img.delivery.net/cm50content/intel/ProductLibrary/100407_Parallel_Programming_01.pdf http://img.delivery.net/cm50content/intel/ProductLibrary/100412_Parallel_Programming_02.pdf
Tu réponds à côté de la plaque. Je n'ai jamais dit qu'il n'était pas possible d'optimiser du code sur x86.
JKB
??? Tu réponds 'pas possible'. Dans ce cas 'pas possible' quoi ?? Tu me dis 'explique-moi', je réponds que je ne peux rien t'expliquer puisque je ne suis pas et ne me prétends pas pro de la programmation. Où est ma réponse à côté de la plaque ? J'avoue avoir un peu de mal à te comprendre.
-- In gold we trust (c)
JKB
Le Mon, 19 Jul 2010 19:51:34 +0200, Jo Kerr écrivait :
JKB a exprimé avec précision :
Le Mon, 19 Jul 2010 18:37:29 +0200, Jo Kerr écrivait :
JKB a utilisé son clavier pour écrire :
Le Mon, 19 Jul 2010 18:25:33 +0200, Jo Kerr écrivait :
JKB a couché sur son écran :
Le problème est d'avoir un code optimisé et massivement multithreadé, car si le T1 est mauvais en monothread, c'est un très bon processeur dès qu'on l'utilise correctement. Le facteur est d'à peu près deux entre un T1/1 GHz et un T7500 à 2,2 GHz. Le T2 est largement meilleur et tourne à 1,6 GHz sans consommer plus.
AMHA il doit être possible d'optimiser aussi pour x86. Peut-être avec les outils/compilateurs de chez Intel. Ils devraient savoir comment fonctionnent leurs bébés.
Pas possible. Lorsque tu optimises un code pour un T1, tu pars du principe qu'il y a 32 threads en parallèle. Et ce n'est pas avec un compilateur que tu obtiens le meilleur résultat, mais en utilisant des choses comme la libpthread. Explique-moi comment tu fais entrer 32 threads parallèles sur un x86 (je parle naturellement d'une génération identique, parce qu'un T2+, ça fait négligemment 256 threads).
JKB
Pour le moment je ne t'expliquerai rien. Je ne suis pas développeur professionnel. Mais pour les longues soirées d'hiver je m'informerai avec la littérature Intel: http://img.delivery.net/cm50content/intel/ProductLibrary/100407_Parallel_Programming_01.pdf http://img.delivery.net/cm50content/intel/ProductLibrary/100412_Parallel_Programming_02.pdf
Tu réponds à côté de la plaque. Je n'ai jamais dit qu'il n'était pas possible d'optimiser du code sur x86.
JKB
??? Tu réponds 'pas possible'. Dans ce cas 'pas possible' quoi ?? Tu me dis 'explique-moi', je réponds que je ne peux rien t'expliquer puisque je ne suis pas et ne me prétends pas pro de la programmation. Où est ma réponse à côté de la plaque ? J'avoue avoir un peu de mal à te comprendre.
Ce n'est pas possible parce que tu ne peux pas comparer un processeur qui fait nativement tourner 32 threads en parallèle à un processeur qui n'en fait tourner que deux (je parle à génération équivalente). Les compilos ne viennent rien faire là-dedans.
Et si tu prends maintenant un Xeon à huit coeurs vis à vis d'un T2+ tenant 256 threads, le Xeon est encore plus à la ramasse. Et c'est sans regarder le problème énergétique.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours. => http://grincheux.de-charybde-en-scylla.fr
Le Mon, 19 Jul 2010 19:51:34 +0200,
Jo Kerr <jo.kerr@jo.invalid> écrivait :
JKB a exprimé avec précision :
Le Mon, 19 Jul 2010 18:37:29 +0200,
Jo Kerr <jo.kerr@jo.invalid> écrivait :
JKB a utilisé son clavier pour écrire :
Le Mon, 19 Jul 2010 18:25:33 +0200,
Jo Kerr <jo.kerr@jo.invalid> écrivait :
JKB a couché sur son écran :
Le problème est d'avoir un code optimisé et massivement
multithreadé, car si le T1 est mauvais en monothread, c'est un très
bon processeur dès qu'on l'utilise correctement. Le facteur est d'à
peu près deux entre un T1/1 GHz et un T7500 à 2,2 GHz. Le T2 est
largement meilleur et tourne à 1,6 GHz sans consommer plus.
AMHA il doit être possible d'optimiser aussi pour x86. Peut-être avec
les outils/compilateurs de chez Intel. Ils devraient savoir comment
fonctionnent leurs bébés.
Pas possible. Lorsque tu optimises un code pour un T1, tu pars du
principe qu'il y a 32 threads en parallèle. Et ce n'est pas avec un
compilateur que tu obtiens le meilleur résultat, mais en utilisant
des choses comme la libpthread. Explique-moi comment tu fais entrer
32 threads parallèles sur un x86 (je parle naturellement d'une
génération identique, parce qu'un T2+, ça fait négligemment 256
threads).
JKB
Pour le moment je ne t'expliquerai rien. Je ne suis pas développeur
professionnel. Mais pour les longues soirées d'hiver je m'informerai
avec la littérature Intel:
http://img.delivery.net/cm50content/intel/ProductLibrary/100407_Parallel_Programming_01.pdf
http://img.delivery.net/cm50content/intel/ProductLibrary/100412_Parallel_Programming_02.pdf
Tu réponds à côté de la plaque. Je n'ai jamais dit qu'il n'était pas
possible d'optimiser du code sur x86.
JKB
???
Tu réponds 'pas possible'. Dans ce cas 'pas possible' quoi ??
Tu me dis 'explique-moi', je réponds que je ne peux rien t'expliquer
puisque je ne suis pas et ne me prétends pas pro de la programmation.
Où est ma réponse à côté de la plaque ?
J'avoue avoir un peu de mal à te comprendre.
Ce n'est pas possible parce que tu ne peux pas comparer un
processeur qui fait nativement tourner 32 threads en parallèle à un
processeur qui n'en fait tourner que deux (je parle à génération
équivalente). Les compilos ne viennent rien faire là-dedans.
Et si tu prends maintenant un Xeon à huit coeurs vis à vis d'un T2+
tenant 256 threads, le Xeon est encore plus à la ramasse. Et c'est
sans regarder le problème énergétique.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
=> http://grincheux.de-charybde-en-scylla.fr
Le Mon, 19 Jul 2010 19:51:34 +0200, Jo Kerr écrivait :
JKB a exprimé avec précision :
Le Mon, 19 Jul 2010 18:37:29 +0200, Jo Kerr écrivait :
JKB a utilisé son clavier pour écrire :
Le Mon, 19 Jul 2010 18:25:33 +0200, Jo Kerr écrivait :
JKB a couché sur son écran :
Le problème est d'avoir un code optimisé et massivement multithreadé, car si le T1 est mauvais en monothread, c'est un très bon processeur dès qu'on l'utilise correctement. Le facteur est d'à peu près deux entre un T1/1 GHz et un T7500 à 2,2 GHz. Le T2 est largement meilleur et tourne à 1,6 GHz sans consommer plus.
AMHA il doit être possible d'optimiser aussi pour x86. Peut-être avec les outils/compilateurs de chez Intel. Ils devraient savoir comment fonctionnent leurs bébés.
Pas possible. Lorsque tu optimises un code pour un T1, tu pars du principe qu'il y a 32 threads en parallèle. Et ce n'est pas avec un compilateur que tu obtiens le meilleur résultat, mais en utilisant des choses comme la libpthread. Explique-moi comment tu fais entrer 32 threads parallèles sur un x86 (je parle naturellement d'une génération identique, parce qu'un T2+, ça fait négligemment 256 threads).
JKB
Pour le moment je ne t'expliquerai rien. Je ne suis pas développeur professionnel. Mais pour les longues soirées d'hiver je m'informerai avec la littérature Intel: http://img.delivery.net/cm50content/intel/ProductLibrary/100407_Parallel_Programming_01.pdf http://img.delivery.net/cm50content/intel/ProductLibrary/100412_Parallel_Programming_02.pdf
Tu réponds à côté de la plaque. Je n'ai jamais dit qu'il n'était pas possible d'optimiser du code sur x86.
JKB
??? Tu réponds 'pas possible'. Dans ce cas 'pas possible' quoi ?? Tu me dis 'explique-moi', je réponds que je ne peux rien t'expliquer puisque je ne suis pas et ne me prétends pas pro de la programmation. Où est ma réponse à côté de la plaque ? J'avoue avoir un peu de mal à te comprendre.
Ce n'est pas possible parce que tu ne peux pas comparer un processeur qui fait nativement tourner 32 threads en parallèle à un processeur qui n'en fait tourner que deux (je parle à génération équivalente). Les compilos ne viennent rien faire là-dedans.
Et si tu prends maintenant un Xeon à huit coeurs vis à vis d'un T2+ tenant 256 threads, le Xeon est encore plus à la ramasse. Et c'est sans regarder le problème énergétique.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours. => http://grincheux.de-charybde-en-scylla.fr
Jo Kerr
Dans son message précédent, JKB a écrit :
Le Mon, 19 Jul 2010 19:51:34 +0200, Jo Kerr écrivait :
JKB a exprimé avec précision :
Le Mon, 19 Jul 2010 18:37:29 +0200, Jo Kerr écrivait :
JKB a utilisé son clavier pour écrire :
Le Mon, 19 Jul 2010 18:25:33 +0200, Jo Kerr écrivait :
JKB a couché sur son écran :
Le problème est d'avoir un code optimisé et massivement multithreadé, car si le T1 est mauvais en monothread, c'est un très bon processeur dès qu'on l'utilise correctement. Le facteur est d'à peu près deux entre un T1/1 GHz et un T7500 à 2,2 GHz. Le T2 est largement meilleur et tourne à 1,6 GHz sans consommer plus.
AMHA il doit être possible d'optimiser aussi pour x86. Peut-être avec les outils/compilateurs de chez Intel. Ils devraient savoir comment fonctionnent leurs bébés.
Pas possible. Lorsque tu optimises un code pour un T1, tu pars du principe qu'il y a 32 threads en parallèle. Et ce n'est pas avec un compilateur que tu obtiens le meilleur résultat, mais en utilisant des choses comme la libpthread. Explique-moi comment tu fais entrer 32 threads parallèles sur un x86 (je parle naturellement d'une génération identique, parce qu'un T2+, ça fait négligemment 256 threads).
JKB
Pour le moment je ne t'expliquerai rien. Je ne suis pas développeur professionnel. Mais pour les longues soirées d'hiver je m'informerai avec la littérature Intel: http://img.delivery.net/cm50content/intel/ProductLibrary/100407_Parallel_Programming_01.pdf http://img.delivery.net/cm50content/intel/ProductLibrary/100412_Parallel_Programming_02.pdf
Tu réponds à côté de la plaque. Je n'ai jamais dit qu'il n'était pas possible d'optimiser du code sur x86.
JKB
??? Tu réponds 'pas possible'. Dans ce cas 'pas possible' quoi ?? Tu me dis 'explique-moi', je réponds que je ne peux rien t'expliquer puisque je ne suis pas et ne me prétends pas pro de la programmation. Où est ma réponse à côté de la plaque ? J'avoue avoir un peu de mal à te comprendre.
Ce n'est pas possible parce que tu ne peux pas comparer un processeur qui fait nativement tourner 32 threads en parallèle à un processeur qui n'en fait tourner que deux (je parle à génération équivalente). Les compilos ne viennent rien faire là-dedans.
Et si tu prends maintenant un Xeon à huit coeurs vis à vis d'un T2+ tenant 256 threads, le Xeon est encore plus à la ramasse. Et c'est sans regarder le problème énergétique.
JKB
D'après ce que j'ai trouvé sur le net, le T2+ fait 8 cores * 8 threads, soit 64 threads. Ceci dit, je ne pense pas que la gamme de prix soit comparable. Le x86 est un processeur grand public au départ. Le reproche qu'on pourrait faire à Intel, c'est d'utiliser cette architecture pour des débouchés plus professionnels. Et là où je suis d'accord pour dire que M$ est un frein à l'innovation, c'est que son monopole impose cette base x86 pour des raisons (officielles) de compatibilité. Le seul avantage à cette situation, c'est qu'on a des processeurs avec un bon rapport prix/performance. Enfin, je pense....
-- In gold we trust (c)
Dans son message précédent, JKB a écrit :
Le Mon, 19 Jul 2010 19:51:34 +0200,
Jo Kerr <jo.kerr@jo.invalid> écrivait :
JKB a exprimé avec précision :
Le Mon, 19 Jul 2010 18:37:29 +0200,
Jo Kerr <jo.kerr@jo.invalid> écrivait :
JKB a utilisé son clavier pour écrire :
Le Mon, 19 Jul 2010 18:25:33 +0200,
Jo Kerr <jo.kerr@jo.invalid> écrivait :
JKB a couché sur son écran :
Le problème est d'avoir un code optimisé et massivement
multithreadé, car si le T1 est mauvais en monothread, c'est un très
bon processeur dès qu'on l'utilise correctement. Le facteur est d'à
peu près deux entre un T1/1 GHz et un T7500 à 2,2 GHz. Le T2 est
largement meilleur et tourne à 1,6 GHz sans consommer plus.
AMHA il doit être possible d'optimiser aussi pour x86. Peut-être avec
les outils/compilateurs de chez Intel. Ils devraient savoir comment
fonctionnent leurs bébés.
Pas possible. Lorsque tu optimises un code pour un T1, tu pars du
principe qu'il y a 32 threads en parallèle. Et ce n'est pas avec un
compilateur que tu obtiens le meilleur résultat, mais en utilisant
des choses comme la libpthread. Explique-moi comment tu fais entrer
32 threads parallèles sur un x86 (je parle naturellement d'une
génération identique, parce qu'un T2+, ça fait négligemment 256
threads).
JKB
Pour le moment je ne t'expliquerai rien. Je ne suis pas développeur
professionnel. Mais pour les longues soirées d'hiver je m'informerai
avec la littérature Intel:
http://img.delivery.net/cm50content/intel/ProductLibrary/100407_Parallel_Programming_01.pdf
http://img.delivery.net/cm50content/intel/ProductLibrary/100412_Parallel_Programming_02.pdf
Tu réponds à côté de la plaque. Je n'ai jamais dit qu'il n'était pas
possible d'optimiser du code sur x86.
JKB
???
Tu réponds 'pas possible'. Dans ce cas 'pas possible' quoi ??
Tu me dis 'explique-moi', je réponds que je ne peux rien t'expliquer
puisque je ne suis pas et ne me prétends pas pro de la programmation.
Où est ma réponse à côté de la plaque ?
J'avoue avoir un peu de mal à te comprendre.
Ce n'est pas possible parce que tu ne peux pas comparer un
processeur qui fait nativement tourner 32 threads en parallèle à un
processeur qui n'en fait tourner que deux (je parle à génération
équivalente). Les compilos ne viennent rien faire là-dedans.
Et si tu prends maintenant un Xeon à huit coeurs vis à vis d'un T2+
tenant 256 threads, le Xeon est encore plus à la ramasse. Et c'est
sans regarder le problème énergétique.
JKB
D'après ce que j'ai trouvé sur le net, le T2+ fait 8 cores * 8 threads,
soit 64 threads. Ceci dit, je ne pense pas que la gamme de prix soit
comparable.
Le x86 est un processeur grand public au départ. Le reproche qu'on
pourrait faire à Intel, c'est d'utiliser cette architecture pour des
débouchés plus professionnels. Et là où je suis d'accord pour dire que
M$ est un frein à l'innovation, c'est que son monopole impose cette
base x86 pour des raisons (officielles) de compatibilité. Le seul
avantage à cette situation, c'est qu'on a des processeurs avec un bon
rapport prix/performance. Enfin, je pense....
Le Mon, 19 Jul 2010 19:51:34 +0200, Jo Kerr écrivait :
JKB a exprimé avec précision :
Le Mon, 19 Jul 2010 18:37:29 +0200, Jo Kerr écrivait :
JKB a utilisé son clavier pour écrire :
Le Mon, 19 Jul 2010 18:25:33 +0200, Jo Kerr écrivait :
JKB a couché sur son écran :
Le problème est d'avoir un code optimisé et massivement multithreadé, car si le T1 est mauvais en monothread, c'est un très bon processeur dès qu'on l'utilise correctement. Le facteur est d'à peu près deux entre un T1/1 GHz et un T7500 à 2,2 GHz. Le T2 est largement meilleur et tourne à 1,6 GHz sans consommer plus.
AMHA il doit être possible d'optimiser aussi pour x86. Peut-être avec les outils/compilateurs de chez Intel. Ils devraient savoir comment fonctionnent leurs bébés.
Pas possible. Lorsque tu optimises un code pour un T1, tu pars du principe qu'il y a 32 threads en parallèle. Et ce n'est pas avec un compilateur que tu obtiens le meilleur résultat, mais en utilisant des choses comme la libpthread. Explique-moi comment tu fais entrer 32 threads parallèles sur un x86 (je parle naturellement d'une génération identique, parce qu'un T2+, ça fait négligemment 256 threads).
JKB
Pour le moment je ne t'expliquerai rien. Je ne suis pas développeur professionnel. Mais pour les longues soirées d'hiver je m'informerai avec la littérature Intel: http://img.delivery.net/cm50content/intel/ProductLibrary/100407_Parallel_Programming_01.pdf http://img.delivery.net/cm50content/intel/ProductLibrary/100412_Parallel_Programming_02.pdf
Tu réponds à côté de la plaque. Je n'ai jamais dit qu'il n'était pas possible d'optimiser du code sur x86.
JKB
??? Tu réponds 'pas possible'. Dans ce cas 'pas possible' quoi ?? Tu me dis 'explique-moi', je réponds que je ne peux rien t'expliquer puisque je ne suis pas et ne me prétends pas pro de la programmation. Où est ma réponse à côté de la plaque ? J'avoue avoir un peu de mal à te comprendre.
Ce n'est pas possible parce que tu ne peux pas comparer un processeur qui fait nativement tourner 32 threads en parallèle à un processeur qui n'en fait tourner que deux (je parle à génération équivalente). Les compilos ne viennent rien faire là-dedans.
Et si tu prends maintenant un Xeon à huit coeurs vis à vis d'un T2+ tenant 256 threads, le Xeon est encore plus à la ramasse. Et c'est sans regarder le problème énergétique.
JKB
D'après ce que j'ai trouvé sur le net, le T2+ fait 8 cores * 8 threads, soit 64 threads. Ceci dit, je ne pense pas que la gamme de prix soit comparable. Le x86 est un processeur grand public au départ. Le reproche qu'on pourrait faire à Intel, c'est d'utiliser cette architecture pour des débouchés plus professionnels. Et là où je suis d'accord pour dire que M$ est un frein à l'innovation, c'est que son monopole impose cette base x86 pour des raisons (officielles) de compatibilité. Le seul avantage à cette situation, c'est qu'on a des processeurs avec un bon rapport prix/performance. Enfin, je pense....
-- In gold we trust (c)
JKB
Le Mon, 19 Jul 2010 21:02:06 +0200, Jo Kerr écrivait :
D'après ce que j'ai trouvé sur le net, le T2+ fait 8 cores * 8 threads, soit 64 threads. Ceci dit, je ne pense pas que la gamme de prix soit comparable.
À puissance équivalente, à peu près. Compare les prix chez Fujitsu/Oracle à du matériel PC par exemple chez Dell. Tu auras des surprises.
Le x86 est un processeur grand public au départ. Le reproche qu'on pourrait faire à Intel, c'est d'utiliser cette architecture pour des débouchés plus professionnels. Et là où je suis d'accord pour dire que M$ est un frein à l'innovation, c'est que son monopole impose cette base x86 pour des raisons (officielles) de compatibilité.
Non, il n'y a techniquement aucune raison. On pourrait très bien combler les lacunes du x86 sans casser la compatibilité, ne serait-ce qu'en rajoutant des opcodes à trois arguments qui font cruellement défaut.
Le seul avantage à cette situation, c'est qu'on a des processeurs avec un bon rapport prix/performance. Enfin, je pense....
Et c'est une erreur trop souvent partagée. J'ai passé pas mal de temps à faire des benchs sur différentes architectures. Le PC, c'est bien dès qu'on arrive à rester en mémoire et qu'on est monothread. Dès qu'on essaye de faire mieux, les performances ne sont plus à la hauteur. Donc pour l'immense majorité des utilisations des postes de travail, c'est pas mal. Pour le reste, c'est une fumisterie chère.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours. => http://grincheux.de-charybde-en-scylla.fr
Le Mon, 19 Jul 2010 21:02:06 +0200,
Jo Kerr <jo.kerr@jo.invalid> écrivait :
D'après ce que j'ai trouvé sur le net, le T2+ fait 8 cores * 8 threads,
soit 64 threads. Ceci dit, je ne pense pas que la gamme de prix soit
comparable.
À puissance équivalente, à peu près. Compare les prix chez
Fujitsu/Oracle à du matériel PC par exemple chez Dell. Tu auras des
surprises.
Le x86 est un processeur grand public au départ. Le reproche qu'on
pourrait faire à Intel, c'est d'utiliser cette architecture pour des
débouchés plus professionnels. Et là où je suis d'accord pour dire que
M$ est un frein à l'innovation, c'est que son monopole impose cette
base x86 pour des raisons (officielles) de compatibilité.
Non, il n'y a techniquement aucune raison. On pourrait très bien
combler les lacunes du x86 sans casser la compatibilité, ne
serait-ce qu'en rajoutant des opcodes à trois arguments qui font
cruellement défaut.
Le seul
avantage à cette situation, c'est qu'on a des processeurs avec un bon
rapport prix/performance. Enfin, je pense....
Et c'est une erreur trop souvent partagée. J'ai passé pas mal de
temps à faire des benchs sur différentes architectures. Le PC, c'est
bien dès qu'on arrive à rester en mémoire et qu'on est monothread.
Dès qu'on essaye de faire mieux, les performances ne sont plus à la
hauteur. Donc pour l'immense majorité des utilisations des postes de
travail, c'est pas mal. Pour le reste, c'est une fumisterie chère.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
=> http://grincheux.de-charybde-en-scylla.fr
Le Mon, 19 Jul 2010 21:02:06 +0200, Jo Kerr écrivait :
D'après ce que j'ai trouvé sur le net, le T2+ fait 8 cores * 8 threads, soit 64 threads. Ceci dit, je ne pense pas que la gamme de prix soit comparable.
À puissance équivalente, à peu près. Compare les prix chez Fujitsu/Oracle à du matériel PC par exemple chez Dell. Tu auras des surprises.
Le x86 est un processeur grand public au départ. Le reproche qu'on pourrait faire à Intel, c'est d'utiliser cette architecture pour des débouchés plus professionnels. Et là où je suis d'accord pour dire que M$ est un frein à l'innovation, c'est que son monopole impose cette base x86 pour des raisons (officielles) de compatibilité.
Non, il n'y a techniquement aucune raison. On pourrait très bien combler les lacunes du x86 sans casser la compatibilité, ne serait-ce qu'en rajoutant des opcodes à trois arguments qui font cruellement défaut.
Le seul avantage à cette situation, c'est qu'on a des processeurs avec un bon rapport prix/performance. Enfin, je pense....
Et c'est une erreur trop souvent partagée. J'ai passé pas mal de temps à faire des benchs sur différentes architectures. Le PC, c'est bien dès qu'on arrive à rester en mémoire et qu'on est monothread. Dès qu'on essaye de faire mieux, les performances ne sont plus à la hauteur. Donc pour l'immense majorité des utilisations des postes de travail, c'est pas mal. Pour le reste, c'est une fumisterie chère.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours. => http://grincheux.de-charybde-en-scylla.fr
Stephane CARPENTIER
Tonton Th wrote:
On 07/19/2010 11:36 AM, Amandine Parmesan wrote:
j'ai testé mandriva, suse, pcoslinux, fedora rien de stable ou mat os
Tu devrais regarder Slackware. Sérieusement.
J'ai donné. J'aimais bien, mais la gestion des mises à jour, des dé pendances, comment dire... Bref, debian puis ubuntu, pour ça, c'est vraiment app réciable.
Je ne crois pas revenir en arrière un jour.
Tonton Th wrote:
On 07/19/2010 11:36 AM, Amandine Parmesan wrote:
j'ai testé mandriva, suse, pcoslinux, fedora rien de stable ou mat os
Tu devrais regarder Slackware. Sérieusement.
J'ai donné. J'aimais bien, mais la gestion des mises à jour, des dé pendances,
comment dire... Bref, debian puis ubuntu, pour ça, c'est vraiment app réciable.
j'ai testé mandriva, suse, pcoslinux, fedora rien de stable ou mat os
Tu devrais regarder Slackware. Sérieusement.
J'ai donné. J'aimais bien, mais la gestion des mises à jour, des dé pendances, comment dire... Bref, debian puis ubuntu, pour ça, c'est vraiment app réciable.
Je ne crois pas revenir en arrière un jour.
Stephane CARPENTIER
Amandine Parmesan wrote:
Un habitué, n'a rien a faire avec une ubuntu. Il fais sa propre installation. Se sera mon cas d'ici fin d'annee
Ouais, enfin, bon, sa propre installation, j'ai essayé. Installer une LFS, c'est super instructif, mais il faut vraiment avoir beaucoup de temps l ibre.
La différence entre debian et ubuntu, c'est surtout que ubuntu c'est plus au goût du jour, donc pour tout ce qui est multimédia c'est plus insta ble sous ubuntu.
Mais la stabilité debian/ubuntu, les debian m'ont claqué deux fois à la figure la première fois, j'ai réussit à corriger les paquets, la seconde fois, j'ai dû faire une réinstallation. Comme j'avais gouté au ge stionnaire de paquets debian, je n'avais pas envie de repasser à slackware, j'ai testé ubuntu et je n'ai jamais eu de problème avec depuis.
Ma ubuntu, je ne la reboote que lorsqu'il y a une mise à jour du noya u.
Amandine Parmesan wrote:
Un habitué, n'a rien a faire avec une ubuntu. Il fais sa propre
installation. Se sera mon cas d'ici fin d'annee
Ouais, enfin, bon, sa propre installation, j'ai essayé. Installer une LFS,
c'est super instructif, mais il faut vraiment avoir beaucoup de temps l ibre.
La différence entre debian et ubuntu, c'est surtout que ubuntu c'est plus au
goût du jour, donc pour tout ce qui est multimédia c'est plus insta ble sous
ubuntu.
Mais la stabilité debian/ubuntu, les debian m'ont claqué deux fois à la
figure la première fois, j'ai réussit à corriger les paquets, la seconde
fois, j'ai dû faire une réinstallation. Comme j'avais gouté au ge stionnaire
de paquets debian, je n'avais pas envie de repasser à slackware, j'ai
testé ubuntu et je n'ai jamais eu de problème avec depuis.
Ma ubuntu, je ne la reboote que lorsqu'il y a une mise à jour du noya u.
Un habitué, n'a rien a faire avec une ubuntu. Il fais sa propre installation. Se sera mon cas d'ici fin d'annee
Ouais, enfin, bon, sa propre installation, j'ai essayé. Installer une LFS, c'est super instructif, mais il faut vraiment avoir beaucoup de temps l ibre.
La différence entre debian et ubuntu, c'est surtout que ubuntu c'est plus au goût du jour, donc pour tout ce qui est multimédia c'est plus insta ble sous ubuntu.
Mais la stabilité debian/ubuntu, les debian m'ont claqué deux fois à la figure la première fois, j'ai réussit à corriger les paquets, la seconde fois, j'ai dû faire une réinstallation. Comme j'avais gouté au ge stionnaire de paquets debian, je n'avais pas envie de repasser à slackware, j'ai testé ubuntu et je n'ai jamais eu de problème avec depuis.
Ma ubuntu, je ne la reboote que lorsqu'il y a une mise à jour du noya u.
Dellara
Doug713705 a papoté sur Usenet le juillet 19, 2010 11:55 AM:
Tu ne comprends _vraiment_ rien à rien...
Et ce n'est même pas surprenant vu le temps qu'il haute icelui avec ses conneries et ses limitations mentales.
Doug713705 a papoté sur Usenet le juillet 19, 2010 11:55 AM:
Tu ne comprends _vraiment_ rien à rien...
Et ce n'est même pas surprenant vu le temps qu'il haute icelui avec ses
conneries et ses limitations mentales.
