Le 01/10/2010 16:54, pehache-tolai a écrit :On 1 oct, 14:25, JKB wrote:Comme tu l'écris, si le truc est bien programmé !
Est-ce les programmeurs sous x86, savent bien programmer en multicœur ?
La réponse est clairement non pour l'immense majorité des
développeurs.
Autrement dit, tous des cons, sauf JKB...
je ne vois pas pourquoi tu dis cela.
JKB a un point vu plutôt interessant je trouve.
Il ne se contente pas de regarder l'amélioration des performances des
processeurs, mais de voir comment ils y arrivent.
Je suis assez convaincu par JKB, même si je suis de plus en plus
désappointé par le réactivité de Intel et de son x86.
Enfin, bon, je garde espoir, le Toshiba AC100 ferait tourner enfin une
Ubuntu 10.10, ce qui est je pense un évenement majeur!
imaginez la logithèque linux, accessible à un netbook de ce genre ...
ET même si ARM tegra2 c'est 32bits c'est pas bien, au moins c'est
différent et certainement mieux en terme d'héritage technologique !
Et des rustines façon openmp ne sont pas là pour
arranger les choses quand on voit les aberrations générées.
OpenMP fonctionne très bien quand on l'utilise correctement et à ce
pour quoi il est fait.
ouai le genre de fonction des processeurs dont les publications sont
discrètes au point que personne ne les utilisent parce que personne ne
sait comment ça marche sauf son copain Microsoft !
Comme je disais sur un autre forum, le brevet ne doit pas être dans
l'instruction, mais dans la façon de la cabler !
C'est trop facile de dire, telle instruction, se code comme cela, pour
faire cela, et surtout faut payer pour la cabler !
Le 01/10/2010 16:54, pehache-tolai a écrit :
On 1 oct, 14:25, JKB<j...@koenigsberg.invalid> wrote:
Comme tu l'écris, si le truc est bien programmé !
Est-ce les programmeurs sous x86, savent bien programmer en multicœur ?
La réponse est clairement non pour l'immense majorité des
développeurs.
Autrement dit, tous des cons, sauf JKB...
je ne vois pas pourquoi tu dis cela.
JKB a un point vu plutôt interessant je trouve.
Il ne se contente pas de regarder l'amélioration des performances des
processeurs, mais de voir comment ils y arrivent.
Je suis assez convaincu par JKB, même si je suis de plus en plus
désappointé par le réactivité de Intel et de son x86.
Enfin, bon, je garde espoir, le Toshiba AC100 ferait tourner enfin une
Ubuntu 10.10, ce qui est je pense un évenement majeur!
imaginez la logithèque linux, accessible à un netbook de ce genre ...
ET même si ARM tegra2 c'est 32bits c'est pas bien, au moins c'est
différent et certainement mieux en terme d'héritage technologique !
Et des rustines façon openmp ne sont pas là pour
arranger les choses quand on voit les aberrations générées.
OpenMP fonctionne très bien quand on l'utilise correctement et à ce
pour quoi il est fait.
ouai le genre de fonction des processeurs dont les publications sont
discrètes au point que personne ne les utilisent parce que personne ne
sait comment ça marche sauf son copain Microsoft !
Comme je disais sur un autre forum, le brevet ne doit pas être dans
l'instruction, mais dans la façon de la cabler !
C'est trop facile de dire, telle instruction, se code comme cela, pour
faire cela, et surtout faut payer pour la cabler !
Le 01/10/2010 16:54, pehache-tolai a écrit :On 1 oct, 14:25, JKB wrote:Comme tu l'écris, si le truc est bien programmé !
Est-ce les programmeurs sous x86, savent bien programmer en multicœur ?
La réponse est clairement non pour l'immense majorité des
développeurs.
Autrement dit, tous des cons, sauf JKB...
je ne vois pas pourquoi tu dis cela.
JKB a un point vu plutôt interessant je trouve.
Il ne se contente pas de regarder l'amélioration des performances des
processeurs, mais de voir comment ils y arrivent.
Je suis assez convaincu par JKB, même si je suis de plus en plus
désappointé par le réactivité de Intel et de son x86.
Enfin, bon, je garde espoir, le Toshiba AC100 ferait tourner enfin une
Ubuntu 10.10, ce qui est je pense un évenement majeur!
imaginez la logithèque linux, accessible à un netbook de ce genre ...
ET même si ARM tegra2 c'est 32bits c'est pas bien, au moins c'est
différent et certainement mieux en terme d'héritage technologique !
Et des rustines façon openmp ne sont pas là pour
arranger les choses quand on voit les aberrations générées.
OpenMP fonctionne très bien quand on l'utilise correctement et à ce
pour quoi il est fait.
ouai le genre de fonction des processeurs dont les publications sont
discrètes au point que personne ne les utilisent parce que personne ne
sait comment ça marche sauf son copain Microsoft !
Comme je disais sur un autre forum, le brevet ne doit pas être dans
l'instruction, mais dans la façon de la cabler !
C'est trop facile de dire, telle instruction, se code comme cela, pour
faire cela, et surtout faut payer pour la cabler !
Le 30/09/2010 09:11, JKB a écrit :Maintenant tout ça a un coût en consommation, c'est
certain, mais ce coût on le réduit en améliorant les processeurs.
Permets-moi d'en douter. L'évolution du x86 ne se fait pas en
optimisant la circuiterie, mais en rajoutant des tas de rustines
pour contourner les problèmes de l'architecture. Au final, tu as un
processeur qui consomme de plus en plus et qui doit être le pire en
terme de rapport entre la puissance consommée et le puissance de
calcul. La seule chose qui le sauve encore, c'est la finesse de
gravure qui le rend moins consommateur, mais cette course à une
limite : non seulement les circuits rajoutés atteindront très
rapidement leur limites, mais les autres fondeur qui font du vrai
RISC vont aussi atteindre ses performances avec des consommations
largement moindres.
Je crois comme Michel Talon que l'avantage du RISC sur le CISC est
aujourd'hui nul. Le gros des transistors d'un CPU actuel, ce sont les
mémoires caches. Le surplus de circuiterie pour traduire les
instructions CISC en micro-instruction RISC est complétement négligeable.
J'ai même ouï dire que, les instructions CISC étant plus courtes que les
RISC, leur lecture en mémoire est plus efficace que sur un processeur RISC.
Le débat RISC contre CISC est même sans doute dépassé. Aujourd'hui c'est
plus la comparaison GPU/CPU qui est en vogue.
Le 30/09/2010 09:11, JKB a écrit :
Maintenant tout ça a un coût en consommation, c'est
certain, mais ce coût on le réduit en améliorant les processeurs.
Permets-moi d'en douter. L'évolution du x86 ne se fait pas en
optimisant la circuiterie, mais en rajoutant des tas de rustines
pour contourner les problèmes de l'architecture. Au final, tu as un
processeur qui consomme de plus en plus et qui doit être le pire en
terme de rapport entre la puissance consommée et le puissance de
calcul. La seule chose qui le sauve encore, c'est la finesse de
gravure qui le rend moins consommateur, mais cette course à une
limite : non seulement les circuits rajoutés atteindront très
rapidement leur limites, mais les autres fondeur qui font du vrai
RISC vont aussi atteindre ses performances avec des consommations
largement moindres.
Je crois comme Michel Talon que l'avantage du RISC sur le CISC est
aujourd'hui nul. Le gros des transistors d'un CPU actuel, ce sont les
mémoires caches. Le surplus de circuiterie pour traduire les
instructions CISC en micro-instruction RISC est complétement négligeable.
J'ai même ouï dire que, les instructions CISC étant plus courtes que les
RISC, leur lecture en mémoire est plus efficace que sur un processeur RISC.
Le débat RISC contre CISC est même sans doute dépassé. Aujourd'hui c'est
plus la comparaison GPU/CPU qui est en vogue.
Le 30/09/2010 09:11, JKB a écrit :Maintenant tout ça a un coût en consommation, c'est
certain, mais ce coût on le réduit en améliorant les processeurs.
Permets-moi d'en douter. L'évolution du x86 ne se fait pas en
optimisant la circuiterie, mais en rajoutant des tas de rustines
pour contourner les problèmes de l'architecture. Au final, tu as un
processeur qui consomme de plus en plus et qui doit être le pire en
terme de rapport entre la puissance consommée et le puissance de
calcul. La seule chose qui le sauve encore, c'est la finesse de
gravure qui le rend moins consommateur, mais cette course à une
limite : non seulement les circuits rajoutés atteindront très
rapidement leur limites, mais les autres fondeur qui font du vrai
RISC vont aussi atteindre ses performances avec des consommations
largement moindres.
Je crois comme Michel Talon que l'avantage du RISC sur le CISC est
aujourd'hui nul. Le gros des transistors d'un CPU actuel, ce sont les
mémoires caches. Le surplus de circuiterie pour traduire les
instructions CISC en micro-instruction RISC est complétement négligeable.
J'ai même ouï dire que, les instructions CISC étant plus courtes que les
RISC, leur lecture en mémoire est plus efficace que sur un processeur RISC.
Le débat RISC contre CISC est même sans doute dépassé. Aujourd'hui c'est
plus la comparaison GPU/CPU qui est en vogue.
Enfin, bon, je garde espoir, le Toshiba AC100 ferait tourner enfin une
Ubuntu 10.10, ce qui est je pense un évenement majeur!
imaginez la logithèque linux, accessible à un netbook de ce genre ...
ET même si ARM tegra2 c'est 32bits c'est pas bien, au moins c'est
différent et certainement mieux en terme d'héritage technologique !
Enfin, bon, je garde espoir, le Toshiba AC100 ferait tourner enfin une
Ubuntu 10.10, ce qui est je pense un évenement majeur!
imaginez la logithèque linux, accessible à un netbook de ce genre ...
ET même si ARM tegra2 c'est 32bits c'est pas bien, au moins c'est
différent et certainement mieux en terme d'héritage technologique !
Enfin, bon, je garde espoir, le Toshiba AC100 ferait tourner enfin une
Ubuntu 10.10, ce qui est je pense un évenement majeur!
imaginez la logithèque linux, accessible à un netbook de ce genre ...
ET même si ARM tegra2 c'est 32bits c'est pas bien, au moins c'est
différent et certainement mieux en terme d'héritage technologique !
Si
là-dedans, ton bout de code utilise des signaux et que tu dois
utiliser des mutexes dans des gestionnaires de signaux (donc de
manière asunchrones), je te souhaite bien du plaisir.
Pourquoi un processeur 32 bits, ce ne serait pas bien ? Parce qu'on
ne peut pas adresser plus de 4 Go de mémoire ? Encore une légende
urbaine. On ne peut pas adresser plus de 4 Go de mémoire parce qu'on
mélange la taille de l'unité arithmétique et celle des registres. Il
y a quinze ans, j'ai développé des cartes avec un 6809 dans un FPGA
et ce 6809 adressait 64 Mo de mémoire ! Il y a trente ans, le Goupil
G3 avec un 6809 pouvait embarquer plus d'un mégaoctet de mémoire.
Pour un processeur 8/16 bits, c'était bien. Avec le raisonnement
actuel, le truc n'aurait pu adresser que 64 Ko de mémoire !
Je vais aussi tordre le cou à une autre idée. Un code 64 bits est
plus lent et plus gros qu'un code 32 bits.
Si
là-dedans, ton bout de code utilise des signaux et que tu dois
utiliser des mutexes dans des gestionnaires de signaux (donc de
manière asunchrones), je te souhaite bien du plaisir.
Pourquoi un processeur 32 bits, ce ne serait pas bien ? Parce qu'on
ne peut pas adresser plus de 4 Go de mémoire ? Encore une légende
urbaine. On ne peut pas adresser plus de 4 Go de mémoire parce qu'on
mélange la taille de l'unité arithmétique et celle des registres. Il
y a quinze ans, j'ai développé des cartes avec un 6809 dans un FPGA
et ce 6809 adressait 64 Mo de mémoire ! Il y a trente ans, le Goupil
G3 avec un 6809 pouvait embarquer plus d'un mégaoctet de mémoire.
Pour un processeur 8/16 bits, c'était bien. Avec le raisonnement
actuel, le truc n'aurait pu adresser que 64 Ko de mémoire !
Je vais aussi tordre le cou à une autre idée. Un code 64 bits est
plus lent et plus gros qu'un code 32 bits.
Si
là-dedans, ton bout de code utilise des signaux et que tu dois
utiliser des mutexes dans des gestionnaires de signaux (donc de
manière asunchrones), je te souhaite bien du plaisir.
Pourquoi un processeur 32 bits, ce ne serait pas bien ? Parce qu'on
ne peut pas adresser plus de 4 Go de mémoire ? Encore une légende
urbaine. On ne peut pas adresser plus de 4 Go de mémoire parce qu'on
mélange la taille de l'unité arithmétique et celle des registres. Il
y a quinze ans, j'ai développé des cartes avec un 6809 dans un FPGA
et ce 6809 adressait 64 Mo de mémoire ! Il y a trente ans, le Goupil
G3 avec un 6809 pouvait embarquer plus d'un mégaoctet de mémoire.
Pour un processeur 8/16 bits, c'était bien. Avec le raisonnement
actuel, le truc n'aurait pu adresser que 64 Ko de mémoire !
Je vais aussi tordre le cou à une autre idée. Un code 64 bits est
plus lent et plus gros qu'un code 32 bits.
Le 01/10/2010 16:54, pehache-tolai a écrit :On 1 oct, 14:25, JKB wrote:Comme tu l'écris, si le truc est bien programmé !
Est-ce les programmeurs sous x86, savent bien programmer en
multicœur ?
La réponse est clairement non pour l'immense majorité des
développeurs.
Autrement dit, tous des cons, sauf JKB...
je ne vois pas pourquoi tu dis cela.
JKB a un point vu plutôt interessant je trouve.
Il ne se contente pas de regarder l'amélioration des performances des
processeurs, mais de voir comment ils y arrivent.
Je suis assez convaincu par JKB, même si je suis de plus en plus
désappointé par le réactivité de Intel et de son x86.
Enfin, bon, je garde espoir, le Toshiba AC100 ferait tourner enfin une
Ubuntu 10.10, ce qui est je pense un évenement majeur!
imaginez la logithèque linux, accessible à un netbook de ce genre ...
Et des rustines façon openmp ne sont pas là pour
arranger les choses quand on voit les aberrations générées.
OpenMP fonctionne très bien quand on l'utilise correctement et à ce
pour quoi il est fait.
ouai le genre de fonction des processeurs dont les publications sont
discrètes au point que personne ne les utilisent parce que personne ne
sait comment ça marche sauf son copain Microsoft !
Comme je disais sur un autre forum, le brevet ne doit pas être dans
l'instruction, mais dans la façon de la cabler !
C'est trop facile de dire, telle instruction, se code comme cela, pour
faire cela, et surtout faut payer pour la cabler !
Le 01/10/2010 16:54, pehache-tolai a écrit :
On 1 oct, 14:25, JKB<j...@koenigsberg.invalid> wrote:
Comme tu l'écris, si le truc est bien programmé !
Est-ce les programmeurs sous x86, savent bien programmer en
multicœur ?
La réponse est clairement non pour l'immense majorité des
développeurs.
Autrement dit, tous des cons, sauf JKB...
je ne vois pas pourquoi tu dis cela.
JKB a un point vu plutôt interessant je trouve.
Il ne se contente pas de regarder l'amélioration des performances des
processeurs, mais de voir comment ils y arrivent.
Je suis assez convaincu par JKB, même si je suis de plus en plus
désappointé par le réactivité de Intel et de son x86.
Enfin, bon, je garde espoir, le Toshiba AC100 ferait tourner enfin une
Ubuntu 10.10, ce qui est je pense un évenement majeur!
imaginez la logithèque linux, accessible à un netbook de ce genre ...
Et des rustines façon openmp ne sont pas là pour
arranger les choses quand on voit les aberrations générées.
OpenMP fonctionne très bien quand on l'utilise correctement et à ce
pour quoi il est fait.
ouai le genre de fonction des processeurs dont les publications sont
discrètes au point que personne ne les utilisent parce que personne ne
sait comment ça marche sauf son copain Microsoft !
Comme je disais sur un autre forum, le brevet ne doit pas être dans
l'instruction, mais dans la façon de la cabler !
C'est trop facile de dire, telle instruction, se code comme cela, pour
faire cela, et surtout faut payer pour la cabler !
Le 01/10/2010 16:54, pehache-tolai a écrit :On 1 oct, 14:25, JKB wrote:Comme tu l'écris, si le truc est bien programmé !
Est-ce les programmeurs sous x86, savent bien programmer en
multicœur ?
La réponse est clairement non pour l'immense majorité des
développeurs.
Autrement dit, tous des cons, sauf JKB...
je ne vois pas pourquoi tu dis cela.
JKB a un point vu plutôt interessant je trouve.
Il ne se contente pas de regarder l'amélioration des performances des
processeurs, mais de voir comment ils y arrivent.
Je suis assez convaincu par JKB, même si je suis de plus en plus
désappointé par le réactivité de Intel et de son x86.
Enfin, bon, je garde espoir, le Toshiba AC100 ferait tourner enfin une
Ubuntu 10.10, ce qui est je pense un évenement majeur!
imaginez la logithèque linux, accessible à un netbook de ce genre ...
Et des rustines façon openmp ne sont pas là pour
arranger les choses quand on voit les aberrations générées.
OpenMP fonctionne très bien quand on l'utilise correctement et à ce
pour quoi il est fait.
ouai le genre de fonction des processeurs dont les publications sont
discrètes au point que personne ne les utilisent parce que personne ne
sait comment ça marche sauf son copain Microsoft !
Comme je disais sur un autre forum, le brevet ne doit pas être dans
l'instruction, mais dans la façon de la cabler !
C'est trop facile de dire, telle instruction, se code comme cela, pour
faire cela, et surtout faut payer pour la cabler !
JKB , dans le message , a
écrit :Si
là-dedans, ton bout de code utilise des signaux et que tu dois
utiliser des mutexes dans des gestionnaires de signaux (donc de
manière asunchrones), je te souhaite bien du plaisir.
Utiliser des signaux dans une application moderne non triviale, 'faut être
un peu taré. Si en plus elle est multithreadée, ce n'est plus un peu, c'est
complètement.
S'il y a des informations qui ne parviennent _que_ comme signaux au
processus, la seule manière saine de gérer ça, c'est de les transformer
immédiatement en une information synchrone manipulable normalement (paquet
sur une socket ou dans un pipe, à la rigueur message dans une file de
messages synchronisée). Pour ça, Linux a le bon goût de proposer signalfd ;
pour les Unix moins modernes, on aura recours à un thread dédié à la capture
de signaux.
Pourquoi un processeur 32 bits, ce ne serait pas bien ? Parce qu'on
ne peut pas adresser plus de 4 Go de mémoire ? Encore une légende
urbaine. On ne peut pas adresser plus de 4 Go de mémoire parce qu'on
mélange la taille de l'unité arithmétique et celle des registres. Il
y a quinze ans, j'ai développé des cartes avec un 6809 dans un FPGA
et ce 6809 adressait 64 Mo de mémoire ! Il y a trente ans, le Goupil
G3 avec un 6809 pouvait embarquer plus d'un mégaoctet de mémoire.
Pour un processeur 8/16 bits, c'était bien. Avec le raisonnement
actuel, le truc n'aurait pu adresser que 64 Ko de mémoire !
Conneries. Tout le monde sait qu'on n'a pas attendu les processeurs 32 bits
pour avoir plus de 64 ko de RAM. N'empêche que pour manipuler des données de
plus de 64 ko pour sur un processeur 16 bits, c'est abominablement pénible,
parce qu'il faut faire des contorsions pour saucissonner ses données en
blocs qui rentrent dans 64 ko. Toute l'arithmétique correspondant a un coût
considérable aussi bien en termes de vitesse qu'en termes de complexité du
code, donc de bugs.
Je vais aussi tordre le cou à une autre idée. Un code 64 bits est
plus lent et plus gros qu'un code 32 bits.
Pas qu'un code capable de faire la même chose : ton code 32 bits, il devra
faire à la main toutes les opérations 64 bits indispensables pour manipuler
de grosses quantités de données : code plus gros et plus lent.
JKB , dans le message <slrniadq5b.dv8.jkb@rayleigh.systella.fr>, a
écrit :
Si
là-dedans, ton bout de code utilise des signaux et que tu dois
utiliser des mutexes dans des gestionnaires de signaux (donc de
manière asunchrones), je te souhaite bien du plaisir.
Utiliser des signaux dans une application moderne non triviale, 'faut être
un peu taré. Si en plus elle est multithreadée, ce n'est plus un peu, c'est
complètement.
S'il y a des informations qui ne parviennent _que_ comme signaux au
processus, la seule manière saine de gérer ça, c'est de les transformer
immédiatement en une information synchrone manipulable normalement (paquet
sur une socket ou dans un pipe, à la rigueur message dans une file de
messages synchronisée). Pour ça, Linux a le bon goût de proposer signalfd ;
pour les Unix moins modernes, on aura recours à un thread dédié à la capture
de signaux.
Pourquoi un processeur 32 bits, ce ne serait pas bien ? Parce qu'on
ne peut pas adresser plus de 4 Go de mémoire ? Encore une légende
urbaine. On ne peut pas adresser plus de 4 Go de mémoire parce qu'on
mélange la taille de l'unité arithmétique et celle des registres. Il
y a quinze ans, j'ai développé des cartes avec un 6809 dans un FPGA
et ce 6809 adressait 64 Mo de mémoire ! Il y a trente ans, le Goupil
G3 avec un 6809 pouvait embarquer plus d'un mégaoctet de mémoire.
Pour un processeur 8/16 bits, c'était bien. Avec le raisonnement
actuel, le truc n'aurait pu adresser que 64 Ko de mémoire !
Conneries. Tout le monde sait qu'on n'a pas attendu les processeurs 32 bits
pour avoir plus de 64 ko de RAM. N'empêche que pour manipuler des données de
plus de 64 ko pour sur un processeur 16 bits, c'est abominablement pénible,
parce qu'il faut faire des contorsions pour saucissonner ses données en
blocs qui rentrent dans 64 ko. Toute l'arithmétique correspondant a un coût
considérable aussi bien en termes de vitesse qu'en termes de complexité du
code, donc de bugs.
Je vais aussi tordre le cou à une autre idée. Un code 64 bits est
plus lent et plus gros qu'un code 32 bits.
Pas qu'un code capable de faire la même chose : ton code 32 bits, il devra
faire à la main toutes les opérations 64 bits indispensables pour manipuler
de grosses quantités de données : code plus gros et plus lent.
JKB , dans le message , a
écrit :Si
là-dedans, ton bout de code utilise des signaux et que tu dois
utiliser des mutexes dans des gestionnaires de signaux (donc de
manière asunchrones), je te souhaite bien du plaisir.
Utiliser des signaux dans une application moderne non triviale, 'faut être
un peu taré. Si en plus elle est multithreadée, ce n'est plus un peu, c'est
complètement.
S'il y a des informations qui ne parviennent _que_ comme signaux au
processus, la seule manière saine de gérer ça, c'est de les transformer
immédiatement en une information synchrone manipulable normalement (paquet
sur une socket ou dans un pipe, à la rigueur message dans une file de
messages synchronisée). Pour ça, Linux a le bon goût de proposer signalfd ;
pour les Unix moins modernes, on aura recours à un thread dédié à la capture
de signaux.
Pourquoi un processeur 32 bits, ce ne serait pas bien ? Parce qu'on
ne peut pas adresser plus de 4 Go de mémoire ? Encore une légende
urbaine. On ne peut pas adresser plus de 4 Go de mémoire parce qu'on
mélange la taille de l'unité arithmétique et celle des registres. Il
y a quinze ans, j'ai développé des cartes avec un 6809 dans un FPGA
et ce 6809 adressait 64 Mo de mémoire ! Il y a trente ans, le Goupil
G3 avec un 6809 pouvait embarquer plus d'un mégaoctet de mémoire.
Pour un processeur 8/16 bits, c'était bien. Avec le raisonnement
actuel, le truc n'aurait pu adresser que 64 Ko de mémoire !
Conneries. Tout le monde sait qu'on n'a pas attendu les processeurs 32 bits
pour avoir plus de 64 ko de RAM. N'empêche que pour manipuler des données de
plus de 64 ko pour sur un processeur 16 bits, c'est abominablement pénible,
parce qu'il faut faire des contorsions pour saucissonner ses données en
blocs qui rentrent dans 64 ko. Toute l'arithmétique correspondant a un coût
considérable aussi bien en termes de vitesse qu'en termes de complexité du
code, donc de bugs.
Je vais aussi tordre le cou à une autre idée. Un code 64 bits est
plus lent et plus gros qu'un code 32 bits.
Pas qu'un code capable de faire la même chose : ton code 32 bits, il devra
faire à la main toutes les opérations 64 bits indispensables pour manipuler
de grosses quantités de données : code plus gros et plus lent.
Le Fri, 01 Oct 2010 23:41:51 +0200,
PP écrivait :Le 01/10/2010 16:54, pehache-tolai a écrit :On 1 oct, 14:25, JKB wrote:Comme tu l'écris, si le truc est bien programmé !
Est-ce les programmeurs sous x86, savent bien programmer en
multicœur ?
La réponse est clairement non pour l'immense majorité des
développeurs.
Autrement dit, tous des cons, sauf JKB...
Je n'ai jamais dit ça et je ne prétends pas être meilleur que les
autres. Sauf que programmer une application multithreadée, ça ne
s'improvise pas et ça se fait à la main. Tous les outils qui
prétendent faire ça automatiquement le font _mal_. Il suffit de
regarder un code généré par OpenMP pour s'en convaincre (une
multiplication de matrice par exemple).
La programmation
multithreadée, ça se fait pour être efficace à grands coups de
pthread_*() ou équivalent. Des codes vraiment efficaces sur des
processeurs multicoeurs, je n'en connais pas beaucoup parce que
c'est chiant à écrire.
ouai le genre de fonction des processeurs dont les publications sont
discrètes au point que personne ne les utilisent parce que personne
ne sait comment ça marche sauf son copain Microsoft !
OpenMP est une bibliothèque qui est capable de paralléliser des
calculs. Elle est utilisable si on sait exactement ce qu'elle fait
et comment elle le fait. Tant qu'on fait des choses simples, cela ne
marche pas si mal que ça, mais lorsqu'on commence à attaquer le
calcul parallèle, ce n'est pas bon
parce qu'on arrive à des dérives
numériques très facilement.
Le Fri, 01 Oct 2010 23:41:51 +0200,
PP <000pipantal@free.fr000> écrivait :
Le 01/10/2010 16:54, pehache-tolai a écrit :
On 1 oct, 14:25, JKB<j...@koenigsberg.invalid> wrote:
Comme tu l'écris, si le truc est bien programmé !
Est-ce les programmeurs sous x86, savent bien programmer en
multicœur ?
La réponse est clairement non pour l'immense majorité des
développeurs.
Autrement dit, tous des cons, sauf JKB...
Je n'ai jamais dit ça et je ne prétends pas être meilleur que les
autres. Sauf que programmer une application multithreadée, ça ne
s'improvise pas et ça se fait à la main. Tous les outils qui
prétendent faire ça automatiquement le font _mal_. Il suffit de
regarder un code généré par OpenMP pour s'en convaincre (une
multiplication de matrice par exemple).
La programmation
multithreadée, ça se fait pour être efficace à grands coups de
pthread_*() ou équivalent. Des codes vraiment efficaces sur des
processeurs multicoeurs, je n'en connais pas beaucoup parce que
c'est chiant à écrire.
ouai le genre de fonction des processeurs dont les publications sont
discrètes au point que personne ne les utilisent parce que personne
ne sait comment ça marche sauf son copain Microsoft !
OpenMP est une bibliothèque qui est capable de paralléliser des
calculs. Elle est utilisable si on sait exactement ce qu'elle fait
et comment elle le fait. Tant qu'on fait des choses simples, cela ne
marche pas si mal que ça, mais lorsqu'on commence à attaquer le
calcul parallèle, ce n'est pas bon
parce qu'on arrive à des dérives
numériques très facilement.
Le Fri, 01 Oct 2010 23:41:51 +0200,
PP écrivait :Le 01/10/2010 16:54, pehache-tolai a écrit :On 1 oct, 14:25, JKB wrote:Comme tu l'écris, si le truc est bien programmé !
Est-ce les programmeurs sous x86, savent bien programmer en
multicœur ?
La réponse est clairement non pour l'immense majorité des
développeurs.
Autrement dit, tous des cons, sauf JKB...
Je n'ai jamais dit ça et je ne prétends pas être meilleur que les
autres. Sauf que programmer une application multithreadée, ça ne
s'improvise pas et ça se fait à la main. Tous les outils qui
prétendent faire ça automatiquement le font _mal_. Il suffit de
regarder un code généré par OpenMP pour s'en convaincre (une
multiplication de matrice par exemple).
La programmation
multithreadée, ça se fait pour être efficace à grands coups de
pthread_*() ou équivalent. Des codes vraiment efficaces sur des
processeurs multicoeurs, je n'en connais pas beaucoup parce que
c'est chiant à écrire.
ouai le genre de fonction des processeurs dont les publications sont
discrètes au point que personne ne les utilisent parce que personne
ne sait comment ça marche sauf son copain Microsoft !
OpenMP est une bibliothèque qui est capable de paralléliser des
calculs. Elle est utilisable si on sait exactement ce qu'elle fait
et comment elle le fait. Tant qu'on fait des choses simples, cela ne
marche pas si mal que ça, mais lorsqu'on commence à attaquer le
calcul parallèle, ce n'est pas bon
parce qu'on arrive à des dérives
numériques très facilement.
Tu n'as pas forcément le _choix_, surtout lorsque la chose doit être
_portable_.
Par ailleurs, un thread dédié, ce n'est pas forcément
optimal du point de vue du CPU.
Et tu peux aussi être contraint d'utiliser des signaux par thread.
Il y a d'ailleurs tout un tas de mécanismes dans POSIX 2001 pour
faire ça.
Quant à signalfd, c'est une hérésie linuxienne qui devrait tomber
dans les oubliettes de l'histoire informatique !
Là encore, tu ne retiens que ce que tu veux bien retenir. J'ai pris
un _exemple_, mais tu ne dois pas savoir ce que c'est. La plupart
des ALU des processeurs 32 bits tournent sur plus de 32 bits (réels
ou émulés). Pour le i386, le bus d'adresse interne est de 48 bits,
ce qui permet de sortir le fameux PAE. Les calculs internes
d'adresses se font sur 48 bits même si le bus externe s'arrête à 4
Go de mémoire adressable. Toute la circuiterie est là
Tu n'as pas forcément le _choix_, surtout lorsque la chose doit être
_portable_.
Par ailleurs, un thread dédié, ce n'est pas forcément
optimal du point de vue du CPU.
Et tu peux aussi être contraint d'utiliser des signaux par thread.
Il y a d'ailleurs tout un tas de mécanismes dans POSIX 2001 pour
faire ça.
Quant à signalfd, c'est une hérésie linuxienne qui devrait tomber
dans les oubliettes de l'histoire informatique !
Là encore, tu ne retiens que ce que tu veux bien retenir. J'ai pris
un _exemple_, mais tu ne dois pas savoir ce que c'est. La plupart
des ALU des processeurs 32 bits tournent sur plus de 32 bits (réels
ou émulés). Pour le i386, le bus d'adresse interne est de 48 bits,
ce qui permet de sortir le fameux PAE. Les calculs internes
d'adresses se font sur 48 bits même si le bus externe s'arrête à 4
Go de mémoire adressable. Toute la circuiterie est là
Tu n'as pas forcément le _choix_, surtout lorsque la chose doit être
_portable_.
Par ailleurs, un thread dédié, ce n'est pas forcément
optimal du point de vue du CPU.
Et tu peux aussi être contraint d'utiliser des signaux par thread.
Il y a d'ailleurs tout un tas de mécanismes dans POSIX 2001 pour
faire ça.
Quant à signalfd, c'est une hérésie linuxienne qui devrait tomber
dans les oubliettes de l'histoire informatique !
Là encore, tu ne retiens que ce que tu veux bien retenir. J'ai pris
un _exemple_, mais tu ne dois pas savoir ce que c'est. La plupart
des ALU des processeurs 32 bits tournent sur plus de 32 bits (réels
ou émulés). Pour le i386, le bus d'adresse interne est de 48 bits,
ce qui permet de sortir le fameux PAE. Les calculs internes
d'adresses se font sur 48 bits même si le bus externe s'arrête à 4
Go de mémoire adressable. Toute la circuiterie est là
On 10/1/10 10:54 PM, pehache-tolai wrote:Autrement dit, tous des cons, sauf JKB...
Ben comment ! tu savais pas ?
OpenMP fonctionne très bien quand on l'utilise correctement et à ce
pour quoi il est fait.
Alors OpenMP aurait été écrit par JKB !
On 10/1/10 10:54 PM, pehache-tolai wrote:
Autrement dit, tous des cons, sauf JKB...
Ben comment ! tu savais pas ?
OpenMP fonctionne très bien quand on l'utilise correctement et à ce
pour quoi il est fait.
Alors OpenMP aurait été écrit par JKB !
On 10/1/10 10:54 PM, pehache-tolai wrote:Autrement dit, tous des cons, sauf JKB...
Ben comment ! tu savais pas ?
OpenMP fonctionne très bien quand on l'utilise correctement et à ce
pour quoi il est fait.
Alors OpenMP aurait été écrit par JKB !
J'ai même ouï dire que, les instructions CISC étant plus courtes que les
RISC, leur lecture en mémoire est plus efficace que sur un processeur RISC.
J'ai même ouï dire que, les instructions CISC étant plus courtes que les
RISC, leur lecture en mémoire est plus efficace que sur un processeur RISC.
J'ai même ouï dire que, les instructions CISC étant plus courtes que les
RISC, leur lecture en mémoire est plus efficace que sur un processeur RISC.