JKB , dans le message , a
écrit :Tu n'as pas cherché bien loin. Je ne vais pas m'abaisser à te
fournir des URL.
Non, surtout pas, ça risquerait de rendre ton discours vaguement crédible.
Qu'est-ce qu'il ne faut pas lire. C'est au contraire très bien fichu
dès qu'on utilise siginfo_t et sigaction() à la place des
semantiques anciennes.
Ce n'est pas utiliser sigaction qui te permettra de faire un malloc dans un
signal handler.
Et ne me dis pas que c'est un problème de
design
Ben si, je le dis.
Les signaux peuvent donc tout à fait être utilisés à l'intérieur
d'un même processus entre les différents threads.
Oui, ils peuvent. Et ceux qui utilisent cette possibilité sont des tarés.
C'est un des principes d'Unix : on te donne toujours assez de corde pour te
pendre.Non, parce que ces API sont _synchrones_ alors que les signaux sont
_asynchrones_. Le fait d'utiliser des API _synchrones_ te contraint
à utiliser des attentes actives ou du polling. Dans quelle langue
faut-il que je te le dise ?
Tu peux le traduire dans la langue que tu veux, ça ne le rendra pas vrai.
Notification qui devient synchrone vis à vis du thread normalement
signalé.
Oui. C'est le but : synchrone => plus simple, donc moins de bugs.Et on retombe dans le polling.
Non.
Tu es bouché à l'émeri parce que tu pars du principe que les deux
approches sont équivalentes, ce qui est faux. Les signaux ne servent
pas qu'à cela et ne peuvent être remplacés par un système synchrone.
Tous les appels systèmes dits lents peuvent échouer sur un EINTR, et
ton approche revient à faire du polling _dans_ ces appels systèmes
si tu veux que les deux approches soient équivalentes.
man poll
Sans commentaire. Est-ce que tu crois que les concepteurs d'Unix (je
ne parle même pas des specs POSIX, BSD ou SyV) aient imposé un truc
inutile ?
Il y a plein de trucs inutiles dans Unix.
D'autre part, lorsque tu commences à utiliser les signaux, la
moindre des choses est de savoir ce que tu fais.
Je sais ce que je fais, et c'est pour ça que j'évite d'utiliser des signaux.
sem_wait(&sem);
Ben déjà, les sémaphores, c'est aussi une API de merde, alors bon...
polling(&mysignalfd);
Tu veux prouver quoi ? Que tu sais faire des programmes grotesques qui ne
marchent pas ? Je le savais déjà.
Si ça, ce n'est pas une attente active, j'aimerais bien que tu me
définisses ce qu'est pour toi une attente active !
Oh, quand on veut faire une attente active, on peut toujours. Même avec des
signaux, d'ailleurs.
Que tu sois manifestement une tanche pour programmer avec autre chose que
des signaux, ça dit des choses sur toi, pas sur les signaux.
Qu'ils crèvent. Ce genre de merde est typique du monde Linux. Sous
prétexte que les programmeurs ne savent pas programmer,
Ouais. D'ailleurs, Linux ne marche pas.
Mais qu'est-ce qu'il ne faut pas lire. L'overhead introduit est
_négligeable_ vis à vis de toutes les autres opérations faites par
l'OS. Si ce n'est pas le cas, c'est juste que ton OS a été écrit pas
un pied.
L'overhead dont il est question, c'est diviser par trois la vitesse de
toutes les opérations arithmétiques entières. Mais à part ça, c'est
négligeable. Ben voyons.
JKB , dans le message <slrniaec4s.glp.jkb@rayleigh.systella.fr>, a
écrit :
Tu n'as pas cherché bien loin. Je ne vais pas m'abaisser à te
fournir des URL.
Non, surtout pas, ça risquerait de rendre ton discours vaguement crédible.
Qu'est-ce qu'il ne faut pas lire. C'est au contraire très bien fichu
dès qu'on utilise siginfo_t et sigaction() à la place des
semantiques anciennes.
Ce n'est pas utiliser sigaction qui te permettra de faire un malloc dans un
signal handler.
Et ne me dis pas que c'est un problème de
design
Ben si, je le dis.
Les signaux peuvent donc tout à fait être utilisés à l'intérieur
d'un même processus entre les différents threads.
Oui, ils peuvent. Et ceux qui utilisent cette possibilité sont des tarés.
C'est un des principes d'Unix : on te donne toujours assez de corde pour te
pendre.
Non, parce que ces API sont _synchrones_ alors que les signaux sont
_asynchrones_. Le fait d'utiliser des API _synchrones_ te contraint
à utiliser des attentes actives ou du polling. Dans quelle langue
faut-il que je te le dise ?
Tu peux le traduire dans la langue que tu veux, ça ne le rendra pas vrai.
Notification qui devient synchrone vis à vis du thread normalement
signalé.
Oui. C'est le but : synchrone => plus simple, donc moins de bugs.
Et on retombe dans le polling.
Non.
Tu es bouché à l'émeri parce que tu pars du principe que les deux
approches sont équivalentes, ce qui est faux. Les signaux ne servent
pas qu'à cela et ne peuvent être remplacés par un système synchrone.
Tous les appels systèmes dits lents peuvent échouer sur un EINTR, et
ton approche revient à faire du polling _dans_ ces appels systèmes
si tu veux que les deux approches soient équivalentes.
man poll
Sans commentaire. Est-ce que tu crois que les concepteurs d'Unix (je
ne parle même pas des specs POSIX, BSD ou SyV) aient imposé un truc
inutile ?
Il y a plein de trucs inutiles dans Unix.
D'autre part, lorsque tu commences à utiliser les signaux, la
moindre des choses est de savoir ce que tu fais.
Je sais ce que je fais, et c'est pour ça que j'évite d'utiliser des signaux.
sem_wait(&sem);
Ben déjà, les sémaphores, c'est aussi une API de merde, alors bon...
polling(&mysignalfd);
Tu veux prouver quoi ? Que tu sais faire des programmes grotesques qui ne
marchent pas ? Je le savais déjà.
Si ça, ce n'est pas une attente active, j'aimerais bien que tu me
définisses ce qu'est pour toi une attente active !
Oh, quand on veut faire une attente active, on peut toujours. Même avec des
signaux, d'ailleurs.
Que tu sois manifestement une tanche pour programmer avec autre chose que
des signaux, ça dit des choses sur toi, pas sur les signaux.
Qu'ils crèvent. Ce genre de merde est typique du monde Linux. Sous
prétexte que les programmeurs ne savent pas programmer,
Ouais. D'ailleurs, Linux ne marche pas.
Mais qu'est-ce qu'il ne faut pas lire. L'overhead introduit est
_négligeable_ vis à vis de toutes les autres opérations faites par
l'OS. Si ce n'est pas le cas, c'est juste que ton OS a été écrit pas
un pied.
L'overhead dont il est question, c'est diviser par trois la vitesse de
toutes les opérations arithmétiques entières. Mais à part ça, c'est
négligeable. Ben voyons.
JKB , dans le message , a
écrit :Tu n'as pas cherché bien loin. Je ne vais pas m'abaisser à te
fournir des URL.
Non, surtout pas, ça risquerait de rendre ton discours vaguement crédible.
Qu'est-ce qu'il ne faut pas lire. C'est au contraire très bien fichu
dès qu'on utilise siginfo_t et sigaction() à la place des
semantiques anciennes.
Ce n'est pas utiliser sigaction qui te permettra de faire un malloc dans un
signal handler.
Et ne me dis pas que c'est un problème de
design
Ben si, je le dis.
Les signaux peuvent donc tout à fait être utilisés à l'intérieur
d'un même processus entre les différents threads.
Oui, ils peuvent. Et ceux qui utilisent cette possibilité sont des tarés.
C'est un des principes d'Unix : on te donne toujours assez de corde pour te
pendre.Non, parce que ces API sont _synchrones_ alors que les signaux sont
_asynchrones_. Le fait d'utiliser des API _synchrones_ te contraint
à utiliser des attentes actives ou du polling. Dans quelle langue
faut-il que je te le dise ?
Tu peux le traduire dans la langue que tu veux, ça ne le rendra pas vrai.
Notification qui devient synchrone vis à vis du thread normalement
signalé.
Oui. C'est le but : synchrone => plus simple, donc moins de bugs.Et on retombe dans le polling.
Non.
Tu es bouché à l'émeri parce que tu pars du principe que les deux
approches sont équivalentes, ce qui est faux. Les signaux ne servent
pas qu'à cela et ne peuvent être remplacés par un système synchrone.
Tous les appels systèmes dits lents peuvent échouer sur un EINTR, et
ton approche revient à faire du polling _dans_ ces appels systèmes
si tu veux que les deux approches soient équivalentes.
man poll
Sans commentaire. Est-ce que tu crois que les concepteurs d'Unix (je
ne parle même pas des specs POSIX, BSD ou SyV) aient imposé un truc
inutile ?
Il y a plein de trucs inutiles dans Unix.
D'autre part, lorsque tu commences à utiliser les signaux, la
moindre des choses est de savoir ce que tu fais.
Je sais ce que je fais, et c'est pour ça que j'évite d'utiliser des signaux.
sem_wait(&sem);
Ben déjà, les sémaphores, c'est aussi une API de merde, alors bon...
polling(&mysignalfd);
Tu veux prouver quoi ? Que tu sais faire des programmes grotesques qui ne
marchent pas ? Je le savais déjà.
Si ça, ce n'est pas une attente active, j'aimerais bien que tu me
définisses ce qu'est pour toi une attente active !
Oh, quand on veut faire une attente active, on peut toujours. Même avec des
signaux, d'ailleurs.
Que tu sois manifestement une tanche pour programmer avec autre chose que
des signaux, ça dit des choses sur toi, pas sur les signaux.
Qu'ils crèvent. Ce genre de merde est typique du monde Linux. Sous
prétexte que les programmeurs ne savent pas programmer,
Ouais. D'ailleurs, Linux ne marche pas.
Mais qu'est-ce qu'il ne faut pas lire. L'overhead introduit est
_négligeable_ vis à vis de toutes les autres opérations faites par
l'OS. Si ce n'est pas le cas, c'est juste que ton OS a été écrit pas
un pied.
L'overhead dont il est question, c'est diviser par trois la vitesse de
toutes les opérations arithmétiques entières. Mais à part ça, c'est
négligeable. Ben voyons.
>> Oui, et non. Il me semble que les instructions à longueur
>> variable complexifient grandement le séquenceur d'accès et la
>> gestion du cache.
>
> Oui, mais seulement si tu négliges le vortex spatio-temporel
> d'improbabilité autour du vexin qui sur-courbe le scalaire
> gravitationnel et donc emprisonne le temps.
Le Vexin français ou le Vexin normand ?
Tu oublies que les années passées à l'Est comptent double, sinon plus,
jeune blanc-bec.
>> Oui, et non. Il me semble que les instructions à longueur
>> variable complexifient grandement le séquenceur d'accès et la
>> gestion du cache.
>
> Oui, mais seulement si tu négliges le vortex spatio-temporel
> d'improbabilité autour du vexin qui sur-courbe le scalaire
> gravitationnel et donc emprisonne le temps.
Le Vexin français ou le Vexin normand ?
Tu oublies que les années passées à l'Est comptent double, sinon plus,
jeune blanc-bec.
>> Oui, et non. Il me semble que les instructions à longueur
>> variable complexifient grandement le séquenceur d'accès et la
>> gestion du cache.
>
> Oui, mais seulement si tu négliges le vortex spatio-temporel
> d'improbabilité autour du vexin qui sur-courbe le scalaire
> gravitationnel et donc emprisonne le temps.
Le Vexin français ou le Vexin normand ?
Tu oublies que les années passées à l'Est comptent double, sinon plus,
jeune blanc-bec.
Tu es désappointé par le fait qu'Intel fasse beaucoup d'efforts de
développement sur les x86 ??
Je suis désappointé par le fait qu'on pourrait avoir des machines
peut-être encore plus puissante et meilleur marché, et surtout avoir
des machines plus petite, silencieuse, etc. si on ne se coltinait pas
la technologie x86, ou plutôt son héritage rustinique de 30 ans !
Heureusement qu'Intel fait des progrès, sinon, les concurrents
auraient depuis de nombreuses années pris la relève.
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
La logithèque Linux accessible sur les netbooks, ce n'est pas
franchement nouveau...
Netbooks autres que x86, bien sûr !
Mais qu'est-ce que tu racontes ???
OpenMP est une spécification décrivant des directives et des appels
de routines pour faire de la programmation parallèle en C ou en
Fortran. Rien à voir avec Microsoft, et ces spécifications sont
publiques.
je parle de certaines fonctions des processeurs Intel ou x86, ..
...qui sont
peu voire non décrite (d'après un truc que j'ai lu il y a quelques
jours sur le net). Je trouve cela vachement interessant le concept !!
Soit c'est faux, soit c'est vrai et c'est plus grave, car qui utilise
alors ces fonctions/instructions ?
Je ne parle pas de compilation, je parle des processeurs eux-même !
Tu es désappointé par le fait qu'Intel fasse beaucoup d'efforts de
développement sur les x86 ??
Je suis désappointé par le fait qu'on pourrait avoir des machines
peut-être encore plus puissante et meilleur marché, et surtout avoir
des machines plus petite, silencieuse, etc. si on ne se coltinait pas
la technologie x86, ou plutôt son héritage rustinique de 30 ans !
Heureusement qu'Intel fait des progrès, sinon, les concurrents
auraient depuis de nombreuses années pris la relève.
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
La logithèque Linux accessible sur les netbooks, ce n'est pas
franchement nouveau...
Netbooks autres que x86, bien sûr !
Mais qu'est-ce que tu racontes ???
OpenMP est une spécification décrivant des directives et des appels
de routines pour faire de la programmation parallèle en C ou en
Fortran. Rien à voir avec Microsoft, et ces spécifications sont
publiques.
je parle de certaines fonctions des processeurs Intel ou x86, ..
...qui sont
peu voire non décrite (d'après un truc que j'ai lu il y a quelques
jours sur le net). Je trouve cela vachement interessant le concept !!
Soit c'est faux, soit c'est vrai et c'est plus grave, car qui utilise
alors ces fonctions/instructions ?
Je ne parle pas de compilation, je parle des processeurs eux-même !
Tu es désappointé par le fait qu'Intel fasse beaucoup d'efforts de
développement sur les x86 ??
Je suis désappointé par le fait qu'on pourrait avoir des machines
peut-être encore plus puissante et meilleur marché, et surtout avoir
des machines plus petite, silencieuse, etc. si on ne se coltinait pas
la technologie x86, ou plutôt son héritage rustinique de 30 ans !
Heureusement qu'Intel fait des progrès, sinon, les concurrents
auraient depuis de nombreuses années pris la relève.
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
La logithèque Linux accessible sur les netbooks, ce n'est pas
franchement nouveau...
Netbooks autres que x86, bien sûr !
Mais qu'est-ce que tu racontes ???
OpenMP est une spécification décrivant des directives et des appels
de routines pour faire de la programmation parallèle en C ou en
Fortran. Rien à voir avec Microsoft, et ces spécifications sont
publiques.
je parle de certaines fonctions des processeurs Intel ou x86, ..
...qui sont
peu voire non décrite (d'après un truc que j'ai lu il y a quelques
jours sur le net). Je trouve cela vachement interessant le concept !!
Soit c'est faux, soit c'est vrai et c'est plus grave, car qui utilise
alors ces fonctions/instructions ?
Je ne parle pas de compilation, je parle des processeurs eux-même !
La réponse est quelques lignes plus haut.
En gros, tu considères que tous les programmeurs qui ne savent pas
bien programmer en multic?ur sont des cons ?
La réponse est quelques lignes plus haut.
En gros, tu considères que tous les programmeurs qui ne savent pas
bien programmer en multic?ur sont des cons ?
La réponse est quelques lignes plus haut.
En gros, tu considères que tous les programmeurs qui ne savent pas
bien programmer en multic?ur sont des cons ?
Je ne vois pas bien l'intérêt qu'aurait Intel à ne pas décrire certaines
fonctions de ses processeurs.
Je ne vois pas bien l'intérêt qu'aurait Intel à ne pas décrire certaines
fonctions de ses processeurs.
Je ne vois pas bien l'intérêt qu'aurait Intel à ne pas décrire certaines
fonctions de ses processeurs.
Le Sat, 02 Oct 2010 09:08:27 +0200,
Richard écrivait :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.
C'est là que je ne suis pas, mais alors pas du tout d'accord.
Si tu prends un RISC, tu n'as pas besoin de cette circuiterie et en
dehors de problèmes de synchronisation des unités d'exécution, tes
instructions sont exécutées dans l'ordre.
Si tu prends un CISC. Il faut que ton interprète CISC qui te
transforme ton CISC en RISC commence par voir quelles sont les
unités disponibles, réorganise les instructions, calcule les modes
d'adressages (dans un RISC, les modes d'adressages sont immédiat,
direct, les autres, tu les fais à la main). C'est cette circuiterie
qui fait qu'un CISC consomme à puissance équivalente plus qu'un
RISC. Et c'est cette circuiterie qui permet à un CISC de faire des
progrès.
Par ailleurs, je ne vois pas ce que vient faire le problème de la
mémoire cache.
Un RISC a généralement plus de mémoire cache qu'un
CISC de même fréquence et beaucoup plus de registres. L'HyperSPARC
de 1992 avait déjà 136 registres internes et 1 Mo de cache synchrone
alors qu'il ne tournait qu'à 90 MHz ! Sans compter le nombre de
contextes câblés...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.
Ça, permets-moi d'en douter. Les instructions (avec leurs opérandes)
font 32 ou 64 bits selon les modes sur un UltraSparc (soit un mot
mémoire). Sur Alpha, c'est 64 bits. Rien ne dépasse.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.
Objection : le débat est aujourd'hui entre RISC et VLIW.
Le CISC
est encore utilisé parce qu'il est bien implanté.
Le CISC pose tout
un tas de problèmes d'utilisation des ressources du processeur.
Le débat GPU/CPU, c'est juste un effet de mode pour gratter de la
puissance de calcul parce qu'on ne l'a pas ailleurs.
Le point de vu de la série T* Sparc est très intéressante. C'est
exactement le contraire de l'IA64. Tu as un processeur multicoeur et
multithread. Seul le RISC te permet de créer un processeur
multithreadé efficace (les instructions sont tellement élémentaires
que tu sais à l'avance comment les organiser et éviter les temps
morts dans les traitements par le processeur). Exemple : le P4 HT (à
deux threads) te permet de gagner entre 5 et 30% selon les programmes.
Sur un T1 (et par coeur à quatre threads), tu fais tourner par
_coeur_ quatre threads presque aussi vite que si tu avais quatre
systèmes indépendants.
Le Sat, 02 Oct 2010 09:08:27 +0200,
Richard<richard@nospam.fr> écrivait :
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.
C'est là que je ne suis pas, mais alors pas du tout d'accord.
Si tu prends un RISC, tu n'as pas besoin de cette circuiterie et en
dehors de problèmes de synchronisation des unités d'exécution, tes
instructions sont exécutées dans l'ordre.
Si tu prends un CISC. Il faut que ton interprète CISC qui te
transforme ton CISC en RISC commence par voir quelles sont les
unités disponibles, réorganise les instructions, calcule les modes
d'adressages (dans un RISC, les modes d'adressages sont immédiat,
direct, les autres, tu les fais à la main). C'est cette circuiterie
qui fait qu'un CISC consomme à puissance équivalente plus qu'un
RISC. Et c'est cette circuiterie qui permet à un CISC de faire des
progrès.
Par ailleurs, je ne vois pas ce que vient faire le problème de la
mémoire cache.
Un RISC a généralement plus de mémoire cache qu'un
CISC de même fréquence et beaucoup plus de registres. L'HyperSPARC
de 1992 avait déjà 136 registres internes et 1 Mo de cache synchrone
alors qu'il ne tournait qu'à 90 MHz ! Sans compter le nombre de
contextes câblés...
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.
Ça, permets-moi d'en douter. Les instructions (avec leurs opérandes)
font 32 ou 64 bits selon les modes sur un UltraSparc (soit un mot
mémoire). Sur Alpha, c'est 64 bits. Rien ne dépasse.
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.
Objection : le débat est aujourd'hui entre RISC et VLIW.
Le CISC
est encore utilisé parce qu'il est bien implanté.
Le CISC pose tout
un tas de problèmes d'utilisation des ressources du processeur.
Le débat GPU/CPU, c'est juste un effet de mode pour gratter de la
puissance de calcul parce qu'on ne l'a pas ailleurs.
Le point de vu de la série T* Sparc est très intéressante. C'est
exactement le contraire de l'IA64. Tu as un processeur multicoeur et
multithread. Seul le RISC te permet de créer un processeur
multithreadé efficace (les instructions sont tellement élémentaires
que tu sais à l'avance comment les organiser et éviter les temps
morts dans les traitements par le processeur). Exemple : le P4 HT (à
deux threads) te permet de gagner entre 5 et 30% selon les programmes.
Sur un T1 (et par coeur à quatre threads), tu fais tourner par
_coeur_ quatre threads presque aussi vite que si tu avais quatre
systèmes indépendants.
Le Sat, 02 Oct 2010 09:08:27 +0200,
Richard écrivait :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.
C'est là que je ne suis pas, mais alors pas du tout d'accord.
Si tu prends un RISC, tu n'as pas besoin de cette circuiterie et en
dehors de problèmes de synchronisation des unités d'exécution, tes
instructions sont exécutées dans l'ordre.
Si tu prends un CISC. Il faut que ton interprète CISC qui te
transforme ton CISC en RISC commence par voir quelles sont les
unités disponibles, réorganise les instructions, calcule les modes
d'adressages (dans un RISC, les modes d'adressages sont immédiat,
direct, les autres, tu les fais à la main). C'est cette circuiterie
qui fait qu'un CISC consomme à puissance équivalente plus qu'un
RISC. Et c'est cette circuiterie qui permet à un CISC de faire des
progrès.
Par ailleurs, je ne vois pas ce que vient faire le problème de la
mémoire cache.
Un RISC a généralement plus de mémoire cache qu'un
CISC de même fréquence et beaucoup plus de registres. L'HyperSPARC
de 1992 avait déjà 136 registres internes et 1 Mo de cache synchrone
alors qu'il ne tournait qu'à 90 MHz ! Sans compter le nombre de
contextes câblés...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.
Ça, permets-moi d'en douter. Les instructions (avec leurs opérandes)
font 32 ou 64 bits selon les modes sur un UltraSparc (soit un mot
mémoire). Sur Alpha, c'est 64 bits. Rien ne dépasse.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.
Objection : le débat est aujourd'hui entre RISC et VLIW.
Le CISC
est encore utilisé parce qu'il est bien implanté.
Le CISC pose tout
un tas de problèmes d'utilisation des ressources du processeur.
Le débat GPU/CPU, c'est juste un effet de mode pour gratter de la
puissance de calcul parce qu'on ne l'a pas ailleurs.
Le point de vu de la série T* Sparc est très intéressante. C'est
exactement le contraire de l'IA64. Tu as un processeur multicoeur et
multithread. Seul le RISC te permet de créer un processeur
multithreadé efficace (les instructions sont tellement élémentaires
que tu sais à l'avance comment les organiser et éviter les temps
morts dans les traitements par le processeur). Exemple : le P4 HT (à
deux threads) te permet de gagner entre 5 et 30% selon les programmes.
Sur un T1 (et par coeur à quatre threads), tu fais tourner par
_coeur_ quatre threads presque aussi vite que si tu avais quatre
systèmes indépendants.
Oui, et non. Il me semble que les instructions à longueur
variable complexifient grandement le séquenceur d'accès et la
gestion du cache.
Oui, mais seulement si tu négliges le vortex spatio-temporel
d'improbabilité autour du vexin qui sur-courbe le scalaire
gravitationnel et donc emprisonne le temps.
Oui, et non. Il me semble que les instructions à longueur
variable complexifient grandement le séquenceur d'accès et la
gestion du cache.
Oui, mais seulement si tu négliges le vortex spatio-temporel
d'improbabilité autour du vexin qui sur-courbe le scalaire
gravitationnel et donc emprisonne le temps.
Oui, et non. Il me semble que les instructions à longueur
variable complexifient grandement le séquenceur d'accès et la
gestion du cache.
Oui, mais seulement si tu négliges le vortex spatio-temporel
d'improbabilité autour du vexin qui sur-courbe le scalaire
gravitationnel et donc emprisonne le temps.
Le 02/10/2010 10:22, JKB a écrit :Le Sat, 02 Oct 2010 09:08:27 +0200,
Richard écrivait :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.
C'est là que je ne suis pas, mais alors pas du tout d'accord.
Si tu prends un RISC, tu n'as pas besoin de cette circuiterie et en
dehors de problèmes de synchronisation des unités d'exécution, tes
instructions sont exécutées dans l'ordre.
Je ne vois pas le rapport. Il existe des processeurs RISC (MIPS p.ex.)
qui exécutent les instructions dans le désordre et des processeurs CISC
(Atom) qui les exécutent dans l'ordre.
Si tu prends un CISC. Il faut que ton interprète CISC qui te
transforme ton CISC en RISC commence par voir quelles sont les
unités disponibles, réorganise les instructions, calcule les modes
d'adressages (dans un RISC, les modes d'adressages sont immédiat,
direct, les autres, tu les fais à la main). C'est cette circuiterie
qui fait qu'un CISC consomme à puissance équivalente plus qu'un
RISC. Et c'est cette circuiterie qui permet à un CISC de faire des
progrès.
Oui, mais cette circuiterie est complètement négligeable dans la
complexité globale d'un CPU actuel. C'est quelques millions de
transistors sur des centaines de millions, voire des milliards.
Par ailleurs, je ne vois pas ce que vient faire le problème de la
mémoire cache.
Parce que la mémoire cache fait partie du CPU aujourd'hui et que c'est
une grosse partie de la taille du CPU et de sa consommation d'énergie.Un RISC a généralement plus de mémoire cache qu'un
CISC de même fréquence et beaucoup plus de registres. L'HyperSPARC
de 1992 avait déjà 136 registres internes et 1 Mo de cache synchrone
alors qu'il ne tournait qu'à 90 MHz ! Sans compter le nombre de
contextes câblés...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.
Ça, permets-moi d'en douter. Les instructions (avec leurs opérandes)
font 32 ou 64 bits selon les modes sur un UltraSparc (soit un mot
mémoire). Sur Alpha, c'est 64 bits. Rien ne dépasse.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.
Objection : le débat est aujourd'hui entre RISC et VLIW.
Ce débat n'est pas mort ? Il me semblait que le processeur VLIW
(l'itanic) avait perdu la partie.
Le CISC
est encore utilisé parce qu'il est bien implanté.
Et qu'il conserve des performances tout-à-fait raisonnables.
Le CISC pose tout
un tas de problèmes d'utilisation des ressources du processeur.
Le débat GPU/CPU, c'est juste un effet de mode pour gratter de la
puissance de calcul parce qu'on ne l'a pas ailleurs.
Pas sûr que ce ne soit qu'un effet de mode. J'ai cru comprendre
que le futur serait l'intégration CPU-GPU, avec pour effet d'améliorer
le temps de communication entre les deux, le gros problème actuel des GPU.
Le point de vu de la série T* Sparc est très intéressante. C'est
exactement le contraire de l'IA64. Tu as un processeur multicoeur et
multithread. Seul le RISC te permet de créer un processeur
multithreadé efficace (les instructions sont tellement élémentaires
que tu sais à l'avance comment les organiser et éviter les temps
morts dans les traitements par le processeur). Exemple : le P4 HT (à
deux threads) te permet de gagner entre 5 et 30% selon les programmes.
Sur un T1 (et par coeur à quatre threads), tu fais tourner par
_coeur_ quatre threads presque aussi vite que si tu avais quatre
systèmes indépendants.
(L'IA64 c'est l'itanium pas le P4).
Si les processeurs IA32 ou EMT64
comme le P4HT ou l'iCore7 ne sont pas très bon en hyper-threading, c'est
surtout parce que les unités d'exécution sont déjà utilisées en
parallèle au sein de chaque thread, ce qui limite leur disponibilité.
Sur une application monothread, un core d'iCore7 va déjà presque 4 fois
plus vite, c'est donc difficile de l'accélérer beaucoup plus.
Ils s'agit donc de deux approches différentes et la meilleure dépend du
domaine d'application où l'on se place.
Le 02/10/2010 10:22, JKB a écrit :
Le Sat, 02 Oct 2010 09:08:27 +0200,
Richard<richard@nospam.fr> écrivait :
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.
C'est là que je ne suis pas, mais alors pas du tout d'accord.
Si tu prends un RISC, tu n'as pas besoin de cette circuiterie et en
dehors de problèmes de synchronisation des unités d'exécution, tes
instructions sont exécutées dans l'ordre.
Je ne vois pas le rapport. Il existe des processeurs RISC (MIPS p.ex.)
qui exécutent les instructions dans le désordre et des processeurs CISC
(Atom) qui les exécutent dans l'ordre.
Si tu prends un CISC. Il faut que ton interprète CISC qui te
transforme ton CISC en RISC commence par voir quelles sont les
unités disponibles, réorganise les instructions, calcule les modes
d'adressages (dans un RISC, les modes d'adressages sont immédiat,
direct, les autres, tu les fais à la main). C'est cette circuiterie
qui fait qu'un CISC consomme à puissance équivalente plus qu'un
RISC. Et c'est cette circuiterie qui permet à un CISC de faire des
progrès.
Oui, mais cette circuiterie est complètement négligeable dans la
complexité globale d'un CPU actuel. C'est quelques millions de
transistors sur des centaines de millions, voire des milliards.
Par ailleurs, je ne vois pas ce que vient faire le problème de la
mémoire cache.
Parce que la mémoire cache fait partie du CPU aujourd'hui et que c'est
une grosse partie de la taille du CPU et de sa consommation d'énergie.
Un RISC a généralement plus de mémoire cache qu'un
CISC de même fréquence et beaucoup plus de registres. L'HyperSPARC
de 1992 avait déjà 136 registres internes et 1 Mo de cache synchrone
alors qu'il ne tournait qu'à 90 MHz ! Sans compter le nombre de
contextes câblés...
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.
Ça, permets-moi d'en douter. Les instructions (avec leurs opérandes)
font 32 ou 64 bits selon les modes sur un UltraSparc (soit un mot
mémoire). Sur Alpha, c'est 64 bits. Rien ne dépasse.
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.
Objection : le débat est aujourd'hui entre RISC et VLIW.
Ce débat n'est pas mort ? Il me semblait que le processeur VLIW
(l'itanic) avait perdu la partie.
Le CISC
est encore utilisé parce qu'il est bien implanté.
Et qu'il conserve des performances tout-à-fait raisonnables.
Le CISC pose tout
un tas de problèmes d'utilisation des ressources du processeur.
Le débat GPU/CPU, c'est juste un effet de mode pour gratter de la
puissance de calcul parce qu'on ne l'a pas ailleurs.
Pas sûr que ce ne soit qu'un effet de mode. J'ai cru comprendre
que le futur serait l'intégration CPU-GPU, avec pour effet d'améliorer
le temps de communication entre les deux, le gros problème actuel des GPU.
Le point de vu de la série T* Sparc est très intéressante. C'est
exactement le contraire de l'IA64. Tu as un processeur multicoeur et
multithread. Seul le RISC te permet de créer un processeur
multithreadé efficace (les instructions sont tellement élémentaires
que tu sais à l'avance comment les organiser et éviter les temps
morts dans les traitements par le processeur). Exemple : le P4 HT (à
deux threads) te permet de gagner entre 5 et 30% selon les programmes.
Sur un T1 (et par coeur à quatre threads), tu fais tourner par
_coeur_ quatre threads presque aussi vite que si tu avais quatre
systèmes indépendants.
(L'IA64 c'est l'itanium pas le P4).
Si les processeurs IA32 ou EMT64
comme le P4HT ou l'iCore7 ne sont pas très bon en hyper-threading, c'est
surtout parce que les unités d'exécution sont déjà utilisées en
parallèle au sein de chaque thread, ce qui limite leur disponibilité.
Sur une application monothread, un core d'iCore7 va déjà presque 4 fois
plus vite, c'est donc difficile de l'accélérer beaucoup plus.
Ils s'agit donc de deux approches différentes et la meilleure dépend du
domaine d'application où l'on se place.
Le 02/10/2010 10:22, JKB a écrit :Le Sat, 02 Oct 2010 09:08:27 +0200,
Richard écrivait :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.
C'est là que je ne suis pas, mais alors pas du tout d'accord.
Si tu prends un RISC, tu n'as pas besoin de cette circuiterie et en
dehors de problèmes de synchronisation des unités d'exécution, tes
instructions sont exécutées dans l'ordre.
Je ne vois pas le rapport. Il existe des processeurs RISC (MIPS p.ex.)
qui exécutent les instructions dans le désordre et des processeurs CISC
(Atom) qui les exécutent dans l'ordre.
Si tu prends un CISC. Il faut que ton interprète CISC qui te
transforme ton CISC en RISC commence par voir quelles sont les
unités disponibles, réorganise les instructions, calcule les modes
d'adressages (dans un RISC, les modes d'adressages sont immédiat,
direct, les autres, tu les fais à la main). C'est cette circuiterie
qui fait qu'un CISC consomme à puissance équivalente plus qu'un
RISC. Et c'est cette circuiterie qui permet à un CISC de faire des
progrès.
Oui, mais cette circuiterie est complètement négligeable dans la
complexité globale d'un CPU actuel. C'est quelques millions de
transistors sur des centaines de millions, voire des milliards.
Par ailleurs, je ne vois pas ce que vient faire le problème de la
mémoire cache.
Parce que la mémoire cache fait partie du CPU aujourd'hui et que c'est
une grosse partie de la taille du CPU et de sa consommation d'énergie.Un RISC a généralement plus de mémoire cache qu'un
CISC de même fréquence et beaucoup plus de registres. L'HyperSPARC
de 1992 avait déjà 136 registres internes et 1 Mo de cache synchrone
alors qu'il ne tournait qu'à 90 MHz ! Sans compter le nombre de
contextes câblés...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.
Ça, permets-moi d'en douter. Les instructions (avec leurs opérandes)
font 32 ou 64 bits selon les modes sur un UltraSparc (soit un mot
mémoire). Sur Alpha, c'est 64 bits. Rien ne dépasse.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.
Objection : le débat est aujourd'hui entre RISC et VLIW.
Ce débat n'est pas mort ? Il me semblait que le processeur VLIW
(l'itanic) avait perdu la partie.
Le CISC
est encore utilisé parce qu'il est bien implanté.
Et qu'il conserve des performances tout-à-fait raisonnables.
Le CISC pose tout
un tas de problèmes d'utilisation des ressources du processeur.
Le débat GPU/CPU, c'est juste un effet de mode pour gratter de la
puissance de calcul parce qu'on ne l'a pas ailleurs.
Pas sûr que ce ne soit qu'un effet de mode. J'ai cru comprendre
que le futur serait l'intégration CPU-GPU, avec pour effet d'améliorer
le temps de communication entre les deux, le gros problème actuel des GPU.
Le point de vu de la série T* Sparc est très intéressante. C'est
exactement le contraire de l'IA64. Tu as un processeur multicoeur et
multithread. Seul le RISC te permet de créer un processeur
multithreadé efficace (les instructions sont tellement élémentaires
que tu sais à l'avance comment les organiser et éviter les temps
morts dans les traitements par le processeur). Exemple : le P4 HT (à
deux threads) te permet de gagner entre 5 et 30% selon les programmes.
Sur un T1 (et par coeur à quatre threads), tu fais tourner par
_coeur_ quatre threads presque aussi vite que si tu avais quatre
systèmes indépendants.
(L'IA64 c'est l'itanium pas le P4).
Si les processeurs IA32 ou EMT64
comme le P4HT ou l'iCore7 ne sont pas très bon en hyper-threading, c'est
surtout parce que les unités d'exécution sont déjà utilisées en
parallèle au sein de chaque thread, ce qui limite leur disponibilité.
Sur une application monothread, un core d'iCore7 va déjà presque 4 fois
plus vite, c'est donc difficile de l'accélérer beaucoup plus.
Ils s'agit donc de deux approches différentes et la meilleure dépend du
domaine d'application où l'on se place.
Je ne vois pas bien l'intérêt qu'aurait Intel à ne pas décrire
certaines fonctions de ses processeurs.
Pourtant, il faut montrer patte blanche si l'on veut en savoir
suffisamment. La documentation du Pentium premier du nom, par exemple,
contenait une «annexe H» de plusieurs dizaines de pages. Mais pour
l'obtenir, il fallait la demander explicitement à Intel, et prouver
que l'on travaillait pour un éditeur de systèmes d'exploitation...
Je ne vois pas bien l'intérêt qu'aurait Intel à ne pas décrire
certaines fonctions de ses processeurs.
Pourtant, il faut montrer patte blanche si l'on veut en savoir
suffisamment. La documentation du Pentium premier du nom, par exemple,
contenait une «annexe H» de plusieurs dizaines de pages. Mais pour
l'obtenir, il fallait la demander explicitement à Intel, et prouver
que l'on travaillait pour un éditeur de systèmes d'exploitation...
Je ne vois pas bien l'intérêt qu'aurait Intel à ne pas décrire
certaines fonctions de ses processeurs.
Pourtant, il faut montrer patte blanche si l'on veut en savoir
suffisamment. La documentation du Pentium premier du nom, par exemple,
contenait une «annexe H» de plusieurs dizaines de pages. Mais pour
l'obtenir, il fallait la demander explicitement à Intel, et prouver
que l'on travaillait pour un éditeur de systèmes d'exploitation...
OK. Donc elles ne sont pas "non décrites", simplement Intel sélectionne à
qui il diffuse l'information. Sur la base d'accords de confidentialité,
peut-être ?
OK. Donc elles ne sont pas "non décrites", simplement Intel sélectionne à
qui il diffuse l'information. Sur la base d'accords de confidentialité,
peut-être ?
OK. Donc elles ne sont pas "non décrites", simplement Intel sélectionne à
qui il diffuse l'information. Sur la base d'accords de confidentialité,
peut-être ?