Discussion :

[deeal]

Le 64 bits ne permet pas d'aller plus vite, generalement c'est plus lent ne fut-ce que parce que ca eleve la pression sur les caches.

pourquoi ca eleverait la pression sur les caches, sauf si mots de la cache sont en 64 bits , la oui, sinon ca serait plus rapide, et meme si ce n'est pas le cas, le goulet d'etranglement entre la processeur et la RAM c'est le Bus
donc ca permettra de prendre avantage de la vitesse du processeur qui est etait toujours reduire par la vitesse du Bus, car on pourra transferer le double ( si les mots sont en 32 bits dans la cache)

et meme au niveau du codage des instruction, meme si on ajoute pas dans la longueur des instruction on peut prendra avanta a coder deux instruction dans le meme

je ne connais pas en detail leur architecture complete car dire 64Bit , c'est pourquoi en fin ?
Bus, registres, caches, instruction?

[Jean-Marc.Bourguet]

pourquoi ca eleverait la pression sur les caches,

Dans un programme compile en 64 bits, un certain nombre de types ont besoin de plus de memoire (en particulier les pointeurs qui font maintenant 64 bits, traditionnellement les long aussi, mais MS a decide de ne pas suivre cette tradition). Donc pour representer la meme quantite de donnees, soit tu utilises une version speciale avec des structures plus compliquees, soit tu as besoin de plus de memoire.

sauf si mots de la cache sont en 64 bits , la oui, sinon ca serait plus rapide, et meme si ce n'est pas le cas, le goulet d'etranglement entre la processeur et la RAM c'est le Bus donc ca permettra de prendre avantage de la vitesse du processeur qui est etait toujours reduire par la vitesse du Bus, car on pourra transferer le double ( si les mots sont en 32 bits dans la cache)

et meme au niveau du codage des instruction, meme si on ajoute pas dans la longueur des instruction on peut prendra avanta a coder deux instruction dans le meme

Je ne comprends pas grand chose a ce que tu as ecrit ci-dessus.

Les caches ne sont pas divises en mots mais en ligne qui font plus que 32 ou 64 bits.

Quand tu parles "du" bus, je me demande de quel bus il s'agit.

La taille du bus sur lequel s'effectue des transferts entre les caches et la memoire n'a pas de rapport avec le nombre de bits du processeurs (pour preuve, cette taille ne change pas que les processeurs soient utilises en mode 32 ou 64 bits).

je ne connais pas en detail leur architecture complete car dire 64Bit , c'est pourquoi en fin ?
Bus, registres, caches, instruction?

Classiquement en architecture des ordinateurs il s'agit de la taille des registres a usage general. Ca devient plus confu dans les architectures ou il n'y a pas des registres a usage general (adresse, index, donnee entiere, donnee flotante) de longueurs differentes ou alors on a tendance a considerer les registres de donnees entieres. Certains ont utilises des considerations de micro-architectures (genre taille du bus interne) mais c'est loin d'etre la norme et ce n'est guere utile car ce n'est pas observable par le programmeur.

[deeal]

Dans un programme compile en 64 bits, un certain nombre de types ont besoin de plus de memoire (en particulier les pointeurs qui font maintenant 64 bits, traditionnellement les long aussi, mais MS a decide de ne pas suivre cette tradition). Donc pour representer la meme quantite de donnees, soit tu utilises une version speciale avec des structures plus compliquees, soit tu as besoin de plus de memoire.

mais en general la taille des lignes de la cache est egales au registres generaux

Je ne comprends pas grand chose a ce que tu as ecrit ci-dessus.

je voulais dire que le Bus de transfert entre le processeur et la RAM qui est toujours a 500 ou 433 Mhz represente le goulet d'etranglement pour le processeur, car meme a 4 GHZ et le bus qui travaille a 433Mhz le processeur sera toujours penalise par cela


Les caches ne sont pas divises en mots mais en ligne qui font plus que 32 ou 64 bits.

Quand tu parles "du" bus, je me demande de quel bus il s'agit.

La taille du bus sur lequel s'effectue des transferts entre les caches et la memoire

je ne parle pas de taille mais de vitesse


je crois que l'architecture ne changera pas grand chose du point de vue software (developemment) mais permettra d'ameliorer les architectures hard et ainsi rendre l'execution plus rapide, je ne crois pas qu'on puisse voir cela a haut niveau, c'est comme les pipelines, dans nos programmes on ne specifie pas que ca doit tourner sur une architecture a pipeline ou pas, mais c'est plustot un truc d'optimisation hardware

[Matthieu Brucher]

Attention, même si le bus est à 400MHz, ça ne veut pas dire qu'il n'y a que 400 bits/sec qui sont transférés
Par exemple chez Intel, c'est un FSB à 200MHz QuadPumped, ce qui veut dire qu'il est équivalent à un bus de même taille à une fréquence de 800MHz qui ne fonctionne que sur front montant. Donc avec une largeur de bus de 32bits, on fait du 3.2Go/s, c'est lent, OK, mais c'est pas mal.
Chez AMD, c'est du même tonneau entre la mémoire et le CPU, c'est plus lent entre processeurs sur des puces différentes - opteron bi-processeurs par ex - car le bus Hyper-Transport à 1GHz est en 16bits, donc ça ne fait que 2Go/s. Mais bon, le goulot est avant
Donc on garde le même débit avec des données 2 fois plus longues. On a des risques de baisse de perf, c'est clair.

[Jean-Marc.Bourguet]

mais en general la taille des lignes de la cache est egales au registres generaux

Dans les caches que j'ai regardes que les lignes sont de 64 ou 128 octets. Pour une taille (en octets) de cache fixee, avoir des lignes plus courte est meilleur d'un point de vue frequence avec lequel les donnees se trouvent dans le cache, mais malheureusement il y a deux effets qui contrebalance cet avantage: il faut des memoires associatives avec plus de cles (donc des delais plus interessant), on profite moins des transferts en blocs (donc on pert de la bande passante avec le niveau de cache superieur, ou avec la memoire).

je voulais dire que le Bus de transfert entre le processeur et la RAM qui est toujours a 500 ou 433 Mhz represente le goulet d'etranglement pour le processeur, car meme a 4 GHZ et le bus qui travaille a 433Mhz le processeur sera toujours penalise par cela

Le processeur sera toujours ralenti quand il veut des donnees hors cache (ou meme dans le cache de niveau 2). On ne sait simplement pas faire des memoires de grande taille fonctionnant a cette vitesse, quelque soit le prix qu'on soit pret a mettre. On peut faire des memoires plus rapides que celles qu'on utilise, mais le prix est prohibitif.

je crois que l'architecture ne changera pas grand chose du point de vue software (developemment) mais permettra d'ameliorer les architectures hard et ainsi rendre l'execution plus rapide, je ne crois pas qu'on puisse voir cela a haut niveau, c'est comme les pipelines, dans nos programmes on ne specifie pas que ca doit tourner sur une architecture a pipeline ou pas, mais c'est plustot un truc d'optimisation hardware

Je ne comprends a nouveau pas ce que tu veux dire.

L'architecture, c'est en premiere approximation ce que voit le programmeur en assembleur (on ne tient pas compte de l'aspect temporel d'une part, de la configuration -- quantite de memoire installee, peripheriques presents, ...).

Les progres en possibilite d'integration d'une part, en techniques de micro-architecture (autrement dit, ce que voit le concepteur du processeur) d'autre part font que l'avantage architectural des RISC sur les CISC a quasiment disparu (en gros les CISC sont devenus des RISC qui interpretent le jeu d'instruction CISC avec un interpreteur hard, le cout de cet interpreteur est devenu negligeable; enfin, c'est vrai pour le x86; il y a des CISC -- le VAX par exemple -- ou les techniques connues ne suffiraient pas).

La largeur de l'architecture n'a quasiment aucun rapport avec la largeur du bus de donnee vers la memoire externe; particulierement en presence d'un cache. On a vu toute les configurations possibles.

[Jean-Marc.Bourguet]

Petite note: il est plus facile de faire transiter rapidement des donnees en serie sur un seul fil qu'en parallele sur plusieurs pour des raisons de synchronisation et d'interference entre les fils (d'ou le remplacement du port parallele par des protocoles series). C'est vrai aussi pour les bus, et on remarque une tendance a la diminution de la largeur de ceux-ci.

[deeal]

je crois que l'architecture ne changera pas grand chose du point de vue software (developemment) mais permettra d'ameliorer les architectures hard et ainsi rendre l'execution plus rapide, je ne crois pas qu'on puisse voir cela a haut niveau, c'est comme les pipelines, dans nos programmes on ne specifie pas que ca doit tourner sur une architecture a pipeline ou pas, mais c'est plustot un truc d'optimisation hardware

Je ne comprends a nouveau pas ce que tu veux dire.

je ne suis pas d'accords que l'assembleur donne acces a toutes les primitives existantes sur le processeur , et loin de la comment faire fonctionner son processeur ( pipeline ou pas, ne pas utiliser la cache 2: juste des examples)
donc je me disais que pour un programmeur en C/C++ ou autre ca ne changera pas grand chose (mais ca se peut, et meme presque sur)
mais ca influera peut-etre les architecture des processeur , le codage des instructions ( deux instructions dans un mot de 64 bits au lieu de deux sur un mot de 32 bits separement, ce qui permettra d'executer deux fois plus d'instructions en une seule lecture, je ne sais pas si c'est faisable mais juste un exemple)

[Jean-Marc.Bourguet]

je ne suis pas d'accords que l'assembleur donne acces a toutes les primitives existantes sur le processeur,

Je n'ai pas l'impression d'avoir fait cette affirmation. Le plus proche dans ce que j'ai écrit, c'est peut-être la définition d'architecture que j'ai récupérée chez Blaauw qui le premier a discerné les trois domaines: l'architecture, l'implémentation que de nos jours on appelle plutôt micro-architecture et la réalisation.

et loin de la comment faire fonctionner son processeur (pipeline ou
pas, ne pas utiliser la cache 2: juste des examples)

Justement ce sont des aspects micro-architecturaux, qui n'influencent normalement pas le résultat d'un programme (ils influencent sa rapidité;
quand ils ont d'autres effets visibles, c'est plutôt dû à une mauvaise découpe entre architecture et micro-architecture...)

donc je me disais que pour un programmeur en C/C++ ou autre ca ne
changera pas grand chose

Quel est l'antécédant de "ca"?

(mais ca se peut, et meme presque sur) mais ca influera peut-etre les architecture des processeur, le codage des instructions (deux instructions dans un mot de 64 bits au lieu de deux sur un mot de 32 bits separement, ce qui permettra d'executer deux fois plus d'instructions en une seule lecture, je ne sais pas si c'est faisable mais juste un exemple)

A nouveau tu sembles considérer qu'il y a un lien entre la largeur du bus
et celle des registres. Ce n'est pas le cas.

Est-ce que je me trompe ou bien tu n'as pas de connaissances appronfondies
en architecture des ordinateurs? Si le sujet t'intéresse, je peux te
conseiller: Computer Architecture concepts and evolution de Blaauw et
Brooks et Computer Organization and Design: The Hardware/Software Interface de Patterson et Hennesy. Le premier est plus axé sur l'architecture même, le deuxième sur la micro-architecture.

[deeal]

je crois que tu as trouve le mot que j'ai perdu
Micro architecture : je disais que cela changerai la micro architecture , et ca ne sera pas visible

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
ustement ce sont des aspects micro-architecturaux, qui n'influencent normalement pas le résultat d'un programme (ils influencent sa rapidité;
quand ils ont d'autres effets visibles, c'est plutôt dû à une mauvaise découpe entre architecture et micro-architecture...)

+1 tu as resume ce que je voulais dire depuis 3 jours
Merci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
Est-ce que je me trompe ou bien tu n'as pas de connaissances appronfondies
en architecture des ordinateurs? Si le sujet t'intéresse, je peux te
conseiller: Computer Architecture concepts and evolution de Blaauw et
Brooks et Computer Organization and Design: The Hardware/Software Interface de Patterson et Hennesy. Le premier est plus axé sur l'architecture même, le deuxième sur la micro-architecture.

c'etait un domaine qui me passionne car vraiment pour les informaticiens
mais je n'ai jamais eu la chance de travailler sur cela

[Matthieu Brucher]

Ce sont des domaines que les électroniciens numériques voient tous les jours, c'est plus important encore pour eux

[t.b.p.]

Justement ce sont des aspects micro-architecturaux, qui n'influencent normalement pas le résultat d'un programme (ils influencent sa rapidité;
quand ils ont d'autres effets visibles, c'est plutôt dû à une mauvaise découpe entre architecture et micro-architecture...)

En pratique le temps d'execution pour arriver une réponse satisfaisante fait partie du cahier des charges et des details micro-architecturaux peuvent demander des implementations radicalement différentes.
Concretement l'obscolescence du x87 (avec son exotique précision à geometrie variable) en mode x86-64 et son remplacement par SSE demande qques amendements, sans parler du chapitre épineux de la vectorisation.
Ou encore la démocratisation de machine NUMA (en gros tous les k8 en multi-processeur) qui amene à réflechir à la localité des données et autres joyeux problèmes de parallelisme.

On ne peut pas toujours se permettre le luxe de s'abstraire dans une machine virtuelle stable et docile

Les caches ne sont pas divises en mots mais en ligne qui font plus que 32 ou 64 bits.

Pour ce qui est des x86, c'est plutôt 32 et 64 octets; en fait les athlons ont tjs eut une ligne de cache de 64 octets et dorénavant tous les processeurs Intel aussi.

Pour ce qui est de l'embonpoint du code en 64bit, c'était vrai du temps de l'Alpha, mais les x86 dans la plus pure tradition CISC utilisent un encodage plus byzantin; en gros cela coute 1 octet supplémentaire par instruction accédant aux registres r8-r15 (pareil pour xmm8-15). De plus bien que les registres soient étendus à 64bit, il y a une extension à zéro de toutes les instructions 32bit. En clair, on ne paie que lorsque l'on accede aux nouveaux registres (ou aux anciens étendus), à de plus grosses constantes, à l'adressage indexé sur le PC (rip) etc...
De plus vu que le nombre de registre double, il a moins de 'spilling', donc moins moins de code. Et c'est plus efficace.
Enfin l'adressage 64bit, en mode 64bit, est facultatif (meme si cela demande du support de la part de l'OS et du compilateur).

[Jean-Marc.Bourguet]

En pratique le temps d'execution pour arriver une réponse satisfaisante fait partie du cahier des charges et des details micro-architecturaux peuvent demander des implementations radicalement différentes.
Concretement l'obscolescence du x87 (avec son exotique précision à geometrie variable) en mode x86-64 et son remplacement par SSE demande qques amendements, sans parler du chapitre épineux de la vectorisation.
Ou encore la démocratisation de machine NUMA (en gros tous les k8 en multi-processeur) qui amene à réflechir à la localité des données et autres joyeux problèmes de parallelisme.

On ne peut pas toujours se permettre le luxe de s'abstraire dans une machine virtuelle stable et docile

Je ne sais pas très bien quel point tu veux mettre en évidence. Nous discuttions de l'influence du 64 bits sur la vitesse, tu viens avec une série d'autres facteurs indépendants du choix 32 ou 64 bits, même si leur démocratisation est simultanée (et encore pour le SSE...)

Pour ce qui est des x86, c'est plutôt 32 et 64 octets

Je n'ai rien écrit d'autre (en fait les tailles que j'ai citées étaient de 64 et 128 octets).

Pour ce qui est de l'embonpoint du code en 64bit

Je n'ai pas parlé d'augmentation de taille du code -- de toute façon qu'il y ait ou non augmentation de la taille, le code n'est pas une proportion importante de la taille des process qui ont besoin du 64 bits -- mais de la taille des données.

[t.b.p.]

Je n'ai rien écrit d'autre (en fait les tailles que j'ai citées étaient de 64 et 128 octets).

Pardon pour la mésatribution.

Je n'ai pas parlé d'augmentation de taille du code -- de toute façon qu'il y ait ou non augmentation de la taille, le code n'est pas une proportion importante de la taille des process qui ont besoin du 64 bits -- mais de la taille des données.

Vous avez parlé d'augmentation de la pression sur les caches. Si ce n'est pas le cache d'instruction, c'est donc le cache de donnée. Bien. Mais il se trouve que dans ce cas précis, la taille des operandes est naturellement 32bits (extension à 0 vers 64bits implicitement). Donc je ne vois pas bien.

Bien sur, généralement, le code ne représente pas une proportion importante de la taille des process mais la bande passante de décodage des x86 est très souvent un facteur limitant. C'est la le goulet d'étranglement, non pas la taille en soit.

Je ne discute que de l'x86-64, parce qu'il serait vain de glauser d'architecture 64bit 'cannonique' car à peu près toutes les variations envisageables, même les plus improbables, ont déjà vu le jour.

[Jean-Marc.Bourguet]

Bien sur, généralement, le code ne représente pas une proportion importante de la taille des process mais la bande passante de décodage des x86 est très souvent un facteur limitant. C'est la le goulet d'étranglement, non pas la taille en soit.

Nous devons travailler sur un genre d'apllications très différentes. Dans les miennes, ce sont les données qui posent problèmes, pas le code.

[t.b.p.]

Nous devons travailler sur un genre d'apllications très différentes. Dans les miennes, ce sont les données qui posent problèmes, pas le code.

Probable. En même temps on pourrait alors se demander pourquoi diable Intel et la moitié de l'industrie informatique se sont un jour embarqués à bord du VLIWesque Itanic. Par mégarde certainement.

[Jean-Marc.Bourguet]

Probable. En même temps on pourrait alors se demander pourquoi diable Intel et la moitié de l'industrie informatique se sont un jour embarqués à bord du VLIWesque Itanic. Par mégarde certainement.

Il va valoir que tu m'expliques pourquoi tu considères que l'Itanium cherche à résoudre un problème de BP du flux d'instructions. J'avais l'impression que son problème était justement dés que les instructions à exécuter n'étaient pas trop régulières...

[t.b.p.]

Il va valoir que tu m'expliques pourquoi tu considères que l'Itanium cherche à résoudre un problème de BP du flux d'instructions

Parce que c'est un VLIW et non un CISC? Le problème ce n'est pas l'obtention, mais le décodage (puis la distribution, puis...).
De même, on pourrait être amené à penser qu'Intel se serait dispensé d'une Trace Cache, pleine de µ-ops, sur son P4 s'il n'avait estimé que le jeu en valait la chandelle, n'est-il pas?
De son coté un k8 est censé soutenir 3 opérations par cycle, si tant est que l'on ne déborde sur une frontière de 16 octets, que le tout soit enrobé dans des bundle de 8 octets d'operation en Direct Path, que la densité de branchement soit idoine et qu'on ait un vent arriere favorable.

Mais je dois me faire des idées.

[Jean-Marc.Bourguet]

Parce que c'est un VLIW et non un CISC? Le problème ce n'est pas l'obtention, mais le décodage (puis la distribution, puis...).
De même, on pourrait être amené à penser qu'Intel se serait dispensé d'une Trace Cache, pleine de µ-ops, sur son P4 s'il n'avait estimé que le jeu en valait la chandelle, n'est-il pas?
De son coté un k8 est censé soutenir 3 opérations par cycle, si tant est que l'on ne déborde sur une frontière de 16 octets, que le tout soit enrobé dans des bundle de 8 octets d'operation en Direct Path, que la densité de branchement soit idoine et qu'on ait un vent arriere favorable.

Mais je dois me faire des idées.

J'ai toujours du mal à savoir pour ou contre quoi tu argues.

Je ne vois toujours pas en quoi du VLIW a un avantage en bande passante
pour les instructions par rapport à un CICS. A priori, je vois un
désavantage: on se retouve à spécifier des NOP en plus parce qu'il n'y a
rien à paralléliser. Mais avec un codage adéquat, ce ne doit pas être trop
génant.

D'une part les caches pour les instructions, ça sert moins à augmenter la
bande passante qu'à diminuer la latence (le trace cache en particulier sert
à diminuer la latence; si on le replacait par un cache d'instructions, on
pourrait en stocker plus -- et le décodage des instructions x86 pose
surtout un problème de latence: on ne peut commencer à décoder la suivante
que quand on sait où elle commence, ce n'est pas l'espace que prend un
décodeur qui pose problème). Et si je n'ai pas vu de problème de bande
passante pour les instructions, j'ai bien vu des problèmes de latence.

D'autre part, une affirmation du genre de celle que j'ai faite (on a plutôt
un problème de BP avec les données qu'avec les instructions, qui est
d'ailleurs à complèter avec "sur certaines charges on a même surtout un
problème de latence de données et d'instructions plutôt que de bande
passante" -- typique de l'influence de ce dernier point: le Niagara de Sun:
8 coeurs à 4 threads, c'est pas une technique qu'on utilise quand on a un
problème de BP), est toujours à prendre dans un contexte donné. Si on ne
traite pas les problèmes de transfert dans l'état de l'art -- donc en
utilisant des caches -- évidemment qu'ils dominent.

Le problème fondamental de la conception d'ordinateurs, c'est d'équilibrer
quatre capacités:
- le traitement
- de transfert de données
- de transfert des instructions
- de stockage (des données et des instructions)
Et comme je l'ai déjà écrit, des charges différentes ont des exigences
différentes en la matière, il n'y a pas de solution universelle et je
n'utiliserais pas un Niagara pour faire du calcul numérique (domaine
classique où la BP a plus d'importance que la latence, encore que la
latence commence à jouer un rôle plus important).

Pour le moment,
- on n'a pas de problème de capacité de traitement (on peut
faire des processeurs qui commencent à exécuter 20 instructions en même
temps -- on ne le fait pas pour d'autres raisons),
- on a un problème d'extraction du parallélisme présent -- mais on est
déjà au delà de ce que pourrait apporter une analyse statique, d'où les
problèmes de l'ia64 sauf sur du code très régulier -- on en est à faire de
l'exécution spéculative pour alimenter la capacité de traitement existente
- on a un problème de latence des données et du code (l'exécution
spéculative aide aussi).
- on a un problème de bande passante des données.

[t.b.p.]

Je ne vois toujours pas en quoi du VLIW a un avantage en bande passante
pour les instructions par rapport à un CICS. A priori, je vois un
désavantage: on se retouve à spécifier des NOP en plus parce qu'il n'y a
rien à paralléliser. Mais avec un codage adéquat, ce ne doit pas être trop
génant.

J'ai parlé de "bande passante de décodage", problème que traite specifiquement une trace cache. Ou encore une architecture VLIW, même si ce n'est pas le seul avantage putatif, qui pourrait être vue comme du RISC explicitement parallelisé: encodage très régulier, taille fixe etc...

Le reste de votre argumentaire est bien trop generique. A toutes fins utiles, un papier comme http://gcc.fyxm.net/summit/2003/Port...he%20amd64.pdf permet de chiffrer la réalité, du moins une, d'une transition 32/64.

[Jean-Marc.Bourguet]

Petite historique: http://www.acm.org/acmqueue/digital/...ctober2006.pdf
article de J. Mashey, pages 27 à 37.