Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2847 connectés 

  FORUM HardWare.fr
  Hardware
  Carte mère

  [technique] Proco 32 bits, memoire 64 bits, variables 64 bits... ???

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[technique] Proco 32 bits, memoire 64 bits, variables 64 bits... ???

n°1822322
Tetedeienc​h
Head Of God
Posté le 19-09-2002 à 18:35:44  profilanswer
 

C'est la question que je me pose.
 
Les registres actuels de nos procos sont en 32 bits ( %eax, %ebx ... ).
 
Pourtant, la SDram est en 64 bits.
 
Donc si on fait une operation en lecture, on lira 64 bits d'un coup... vu la largeur du bus.
 
Donc de deux choses l'une :
 
-Soit on utilise que 32 bits sur les 64 qui arrivent, auquel cas, comme la memoire ne supporte qu'une operation a la fois, il ne sert a rien d'avoir un bus 64 bits, un 32 bits aurai suffit .
 
-Soit on mets le contenu des 64 bits dans deux registres en meme temps, et ainsi on peux recuperer deux fois 32 bits en une seule lecture.
 
De plus, on bosse sur des variables 64 bits ( les flottants version double). Donc autant je comprends qu;en plusieurs passages dans l'ALU 32 bits on puisse faire des caculs 64 bits, lents, mais on les faits, mais je comprends tjs pas comment ecrire dans deux registres en meme temps...
 
Si une telle instruction existe, vous pouvez me filer son nom ? Juste pour ma culture personelle...
 
Bref, le probleme est interessant ;)
 
Merci ;)
 


---------------
L'ingénieur chipset nortiaux : Une iFricandelle svp ! "Spa du pâté, hin!" ©®Janfynette | "La plus grosse collec vivante de bans abusifs sur pattes" | OCCT v12 OUT !
mood
Publicité
Posté le 19-09-2002 à 18:35:44  profilanswer
 

n°1822350
jesus_chri​st
votre nouveau dieu
Posté le 19-09-2002 à 18:40:58  profilanswer
 

le CPU gère 4 octets par cycles (32 bits)
 
or un octet a une addresse 32-bits, donc il faudrait 4*32=128 bits comme largeur de bus
 
pour l'instant on utilise 64, avec la cache du CPU ça marche correctement


---------------
Envie de backuper un DVD en DivX mais vous y connaissez rien ? essayez dvd-ripp : le site de Maxime
n°1822380
Tetedeienc​h
Head Of God
Posté le 19-09-2002 à 18:47:06  profilanswer
 

jesus_christ a écrit a écrit :

le CPU gère 4 octets par cycles (32 bits)
 
or un octet a une addresse 32-bits, donc il faudrait 4*32=128 bits comme largeur de bus
 
pour l'instant on utilise 64, avec la cache du CPU ça marche correctement




 
Heink ?
 
Et si tu dis : " je veux un lecture a partir de l'adresse 10", il te renvoie 8 octets a partir de la ( largeur de bus 64 bits oblige ) donc tu as ton info 64 bits, de laquelle tu n'utilisera que 32 bits au cas ou.
 
Ton coup d'adressage je capte pas jesus...
 
Je vois pas ce que tu veux dire...
 
Tu va pas lire 4 octets differents dans la memoire hein, tu lis 4 octets contigus quoiqu'il arrive...


---------------
L'ingénieur chipset nortiaux : Une iFricandelle svp ! "Spa du pâté, hin!" ©®Janfynette | "La plus grosse collec vivante de bans abusifs sur pattes" | OCCT v12 OUT !
n°1822634
mrbebert
Posté le 19-09-2002 à 19:32:15  profilanswer
 

Tetedeiench a écrit a écrit :

...
-Soit on mets le contenu des 64 bits dans deux registres en meme temps, et ainsi on peux recuperer deux fois 32 bits en une seule lecture.
...


Les données ne passent pas de la mémoire vers les registres, mais de la mémoire vers le cache L2.
Le cache L2 est organisé en "lignes" d'une longueur définie. Si celle-ci font 128 bits, ca signifie que le processeur aura dans son cache L2 un ensemble de blocs de longueur 128 bits.
Mais ensuite, il peut ne prendre qu'une partie de ces lignes pour les mettre en L1 puis vers les registres.
 
Un article sur le L2 du P4 :
http://www.x86-secret.com/articles/cpu/p4/p4-11.htm
 
La longueur des lignes de cache du L2 est de 128 octets. Donc, le proc lit des blocs de 128 octets depuis la RAM. Chacune de ces lignes correspond à 2 blocs de 64 octets pour le L1.
 
Faut lire ici aussi :
http://www.onversity.com/cgi-bin/p [...] ts&P=a0900


Message édité par mrbebert le 19-09-2002 à 19:54:14
n°1822651
MinouX
Le miaou-miaou du web
Posté le 19-09-2002 à 19:38:17  profilanswer
 

j'aime bien les topcs de ce genre :)  
Continuer les gars :D

n°1822660
jesus_chri​st
votre nouveau dieu
Posté le 19-09-2002 à 19:40:45  profilanswer
 

Tetedeiench a écrit a écrit :

 
 
Heink ?
 
Et si tu dis : " je veux un lecture a partir de l'adresse 10", il te renvoie 8 octets a partir de la ( largeur de bus 64 bits oblige ) donc tu as ton info 64 bits, de laquelle tu n'utilisera que 32 bits au cas ou.
 
Ton coup d'adressage je capte pas jesus...
 
Je vois pas ce que tu veux dire...
 
Tu va pas lire 4 octets differents dans la memoire hein, tu lis 4 octets contigus quoiqu'il arrive...



un transfert ne se fait pas forcement à la largeur du bus, il est sencé y avoir des instructions de transfert 8, 16, 32 ou 64 bits au choix
 
enfin ça c'est qd j'ai appris l'assembleur, maintenant si ça a changé...
 
La taille du bus mémoire et celui du CPU en gestion mémoire est indépendante, sur pentium par exemple il y a eu 16-bits (SIMM 72 broches) 32 (FPM 72 broches) et 64 (EDO 72 broche en paires)


---------------
Envie de backuper un DVD en DivX mais vous y connaissez rien ? essayez dvd-ripp : le site de Maxime
n°1822711
wave
Posté le 19-09-2002 à 19:52:12  profilanswer
 

Tetedeiench a écrit a écrit :

C'est la question que je me pose.
 
Les registres actuels de nos procos sont en 32 bits ( %eax, %ebx ... ).
 
Pourtant, la SDram est en 64 bits.
 
Donc si on fait une operation en lecture, on lira 64 bits d'un coup... vu la largeur du bus.
 
Donc de deux choses l'une :
 
-Soit on utilise que 32 bits sur les 64 qui arrivent, auquel cas, comme la memoire ne supporte qu'une operation a la fois, il ne sert a rien d'avoir un bus 64 bits, un 32 bits aurai suffit .
 
-Soit on mets le contenu des 64 bits dans deux registres en meme temps, et ainsi on peux recuperer deux fois 32 bits en une seule lecture.
 
De plus, on bosse sur des variables 64 bits ( les flottants version double). Donc autant je comprends qu;en plusieurs passages dans l'ALU 32 bits on puisse faire des caculs 64 bits, lents, mais on les faits, mais je comprends tjs pas comment ecrire dans deux registres en meme temps...
 
Si une telle instruction existe, vous pouvez me filer son nom ? Juste pour ma culture personelle...
 
Bref, le probleme est interessant ;)
 
Merci ;)
 
 




écrire dans plusieurs registres en même temps je sais pas si c'est possible.
par contre le 'data prefetch' stocke plusieurs mots d'avance dans le cache L2 à chaque fois qu'on lit une donnée en RAM.
d'ailleurs la RAM, après un long temps d'accès, peut transférer plusieurs mots à la suite (8 je crois) et c'est grâce au cache qu'on peut exploiter ce débit. sinon ça serait catastrophique comme débit de mémoire.
en gros quand on lit un octet ou un mot, il faut attendre longtemps mais quand on lit le suivant il est souvent déjà dans le cache.
 
sinon avec MMX et 3dnow on peut stocker 2 nombre 32 bits dans un registre 64 bits. 4 avec SSE (registres 128 bits).
sinon pour la fpu x87 on n'écrit pas dans 2 registres en même temps puisque les registres font 80 bits.
d'ailleurs de bus des cpu actuels est 64 bits même si certains registres sont 32 bits.

n°1822974
Tetedeienc​h
Head Of God
Posté le 19-09-2002 à 21:38:25  profilanswer
 

jesus_christ a écrit a écrit :

un transfert ne se fait pas forcement à la largeur du bus, il est sencé y avoir des instructions de transfert 8, 16, 32 ou 64 bits au choix
 
enfin ça c'est qd j'ai appris l'assembleur, maintenant si ça a changé...
 
La taille du bus mémoire et celui du CPU en gestion mémoire est indépendante, sur pentium par exemple il y a eu 16-bits (SIMM 72 broches) 32 (FPM 72 broches) et 64 (EDO 72 broche en paires)




 
Ouai, mais tu les fait pas en meme temps.
 
Quand tu fait un movb, tu recuperes le resultat de suite.
 
Donc en gros, la memoire te fournit l'info que tu veux + de l'inutile et tu ne ranges que celle qui t'interesse.
 
Tu ne peux pas, par exemple, prendre un word de la memoire et un byte, sauf si ils sont dans la meme case memoire.
 
Tu va devoir les faire les uns apres les autres.
 
En assembleur c;est visible :
 
movb (%ebx),%al
movl (%ecx), %eax
 
Par exemple ( je suis pas sur de ma typo, mais l'idee est la, sur Pentium 1).


---------------
L'ingénieur chipset nortiaux : Une iFricandelle svp ! "Spa du pâté, hin!" ©®Janfynette | "La plus grosse collec vivante de bans abusifs sur pattes" | OCCT v12 OUT !
n°1822978
Tetedeienc​h
Head Of God
Posté le 19-09-2002 à 21:39:50  profilanswer
 

wave a écrit a écrit :

 
écrire dans plusieurs registres en même temps je sais pas si c'est possible.
par contre le 'data prefetch' stocke plusieurs mots d'avance dans le cache L2 à chaque fois qu'on lit une donnée en RAM.
d'ailleurs la RAM, après un long temps d'accès, peut transférer plusieurs mots à la suite (8 je crois) et c'est grâce au cache qu'on peut exploiter ce débit. sinon ça serait catastrophique comme débit de mémoire.
en gros quand on lit un octet ou un mot, il faut attendre longtemps mais quand on lit le suivant il est souvent déjà dans le cache.
 
sinon avec MMX et 3dnow on peut stocker 2 nombre 32 bits dans un registre 64 bits. 4 avec SSE (registres 128 bits).
sinon pour la fpu x87 on n'écrit pas dans 2 registres en même temps puisque les registres font 80 bits.
d'ailleurs de bus des cpu actuels est 64 bits même si certains registres sont 32 bits.
 




 
BINGO !
 
Merci :love:
 
ca correspond a ce que j'ai lu sur le pentium pro.
 
mais, ca ne correspond pas a ce que mon bouquin dit, vu qu'on etudie le pentium I ...


---------------
L'ingénieur chipset nortiaux : Une iFricandelle svp ! "Spa du pâté, hin!" ©®Janfynette | "La plus grosse collec vivante de bans abusifs sur pattes" | OCCT v12 OUT !
n°1822993
blazkowicz
Posté le 19-09-2002 à 21:50:34  profilanswer
 

jesus_christ a écrit a écrit :

La taille du bus mémoire et celui du CPU en gestion mémoire est indépendante, sur pentium par exemple il y a eu 16-bits (SIMM 72 broches) 32 (FPM 72 broches) et 64 (EDO 72 broche en paires)




 
 :heink:  :heink:  :heink:  
 
le fait que la ram soit standard, fpm, edo ou même sdram n'a rien à voir avec la largeur du bus mémoire  
 
et le pentium, c'est un bus mémoire 64bits, c'est tout

mood
Publicité
Posté le 19-09-2002 à 21:50:34  profilanswer
 

n°1823003
blazkowicz
Posté le 19-09-2002 à 21:52:35  profilanswer
 

mrbebert a écrit a écrit :

Les données ne passent pas de la mémoire vers les registres, mais de la mémoire vers le cache L2.
Le cache L2 est organisé en "lignes" d'une longueur définie. Si celle-ci font 128 bits, ca signifie que le processeur aura dans son cache L2 un ensemble de blocs de longueur 128 bits.
Mais ensuite, il peut ne prendre qu'une partie de ces lignes pour les mettre en L1 puis vers les registres.
 
Un article sur le L2 du P4 :
http://www.x86-secret.com/articles/cpu/p4/p4-11.htm
 
La longueur des lignes de cache du L2 est de 128 octets. Donc, le proc lit des blocs de 128 octets depuis la RAM. Chacune de ces lignes correspond à 2 blocs de 64 octets pour le L1.
 
Faut lire ici aussi :
http://www.onversity.com/cgi-bin/p [...] ts&P=a0900




 
précision : sur les K7, contrairement aux autres procs, les données du L1 ne proviennent pas du L2. c'est ainsi que les duron ont deux fois moins de L2 que de L1

n°1823021
jesus_chri​st
votre nouveau dieu
Posté le 19-09-2002 à 21:58:05  profilanswer
 

Tetedeiench a écrit a écrit :

 
Pourtant, la SDram est en 64 bits.



 
tetedeiench parle du bus dépendant de la technologie, ici la SDRAM, et elle est en 64-bits
 
maintenant le CPU lui-même accède à la mémoire en 32 ou 16 bits celon le CPU, et c'est 64 pour le pentium, même sur FPM, je suis d'accord


---------------
Envie de backuper un DVD en DivX mais vous y connaissez rien ? essayez dvd-ripp : le site de Maxime
n°1823030
wave
Posté le 19-09-2002 à 22:00:22  profilanswer
 

Tetedeiench a écrit a écrit :

 
 
BINGO !
 
Merci :love:
 
ca correspond a ce que j'ai lu sur le pentium pro.
 
mais, ca ne correspond pas a ce que mon bouquin dit, vu qu'on etudie le pentium I ...




ben en fait tout ça évolue lentement mais surement à chaque nouveau cpu. C'est ce qui permet de supporter les coefs monstrueux qu'on a actuellement entre le cpu et le FSB.

n°1823347
Tetedeienc​h
Head Of God
Posté le 19-09-2002 à 23:53:53  profilanswer
 

ouaip mais bon : Y a t'il des registres 64 bits pour la FPU en dehors des architectures x87 et autres :??:
 
C'est la question qui me tracasse :/


---------------
L'ingénieur chipset nortiaux : Une iFricandelle svp ! "Spa du pâté, hin!" ©®Janfynette | "La plus grosse collec vivante de bans abusifs sur pattes" | OCCT v12 OUT !
n°1823426
bjone
Insert booze to continue
Posté le 20-09-2002 à 00:25:56  profilanswer
 

le fpu des x87 est configurable jusqu'en 80 bits....
 
en fait le fpu est plus subtile...
 
quand tu stockes tes données en float en mémoire, suivant comment le fpu est configuré, ta précision va être étendu sur 64 bits (double) ou 80 bits (extended ?).
 
ce qui veux dire qu'un code qui utilise au maximum les regsitres du cpu en passant au minimum par la ram, maximizera la précision de calcul.
 
par contre il y a une petite subtilité au niveau du codage des flottans dans un fpu x87, en effet dans la norme ieee, les flottants sont codés avec signe+exposant+mantisse, et la mantisse consiste en juste la partie fractionnaire, le 1. est sous entendu.
 
par exemple 1.01111 sera 01111 dans la mantisse...
 
au niveau registre du fpu x87, un J contenant le 0 ou 1 de la partie entière est présent afin de pouvoir calculer avec des valeurs dénormalisées (valeurs ou le 1. est hors d'atteinte de l'exposant).
 
 
 

n°1823431
bjone
Insert booze to continue
Posté le 20-09-2002 à 00:29:27  profilanswer
 

il me semble que les processeurs alpha possèdent la posssibilité d'encoder les flottans sur 128 bits...

n°1823432
bjone
Insert booze to continue
Posté le 20-09-2002 à 00:30:32  profilanswer
 

tiens pour l'alpha:
http://www.tru64unix.compaq.com/do [...] CU0006.HTM
 
Tetedeiench >> c'est ce que tu voulais comme style d'info ou pas ?


Message édité par bjone le 20-09-2002 à 00:36:18
n°1823475
Tetedeienc​h
Head Of God
Posté le 20-09-2002 à 01:11:22  profilanswer
 

bjone a écrit a écrit :

tiens pour l'alpha:
http://www.tru64unix.compaq.com/do [...] CU0006.HTM
 
Tetedeiench >> c'est ce que tu voulais comme style d'info ou pas ?




 
Yaaaaaaaaaaa parfait, surtout l'explication au dessus.
 
Maintenant j'aimerai que tu me dises si j'ai bon.
 
J'ai besoin de lire deux variable 32 bits contigues dans la memoire, le bus proco fait que 32 bits, le bus memoire 64 bits, ok ?
 
Je lance mon instruction de lecture, il va lire 64 bits, les rapatrier quelque part.
 
Ensuite je veux les traiter dans les registres.
 
Va falloir que je face deux instructions CPU pour les rapatrier dans les registres, style %eax et %ebx.
 
J'ai bon ?
 
maintenant, le quelque part ou se trouve les 64 bits, comment ca s'apelle ;)
 
Et est-ce rellement comme ca qu'est utilise le bus 64 bits ? ( je suis en pleine cogitation, c'est pas dans mon quinbou et j'ai pas trouve sur google) est-ce ainsi qu'on lui file une utilite autre que pour les flottants sur 64 bits ?


---------------
L'ingénieur chipset nortiaux : Une iFricandelle svp ! "Spa du pâté, hin!" ©®Janfynette | "La plus grosse collec vivante de bans abusifs sur pattes" | OCCT v12 OUT !
n°1823489
bjone
Insert booze to continue
Posté le 20-09-2002 à 01:26:57  profilanswer
 

alors comme il a été expliqué plus haut, la mémoire cache est entre le core et la mémoire (et entre les caches du cpu et la mémoire y'a le chipset qui rajoute des couches..)
 
donc tu fait:
 
mov eax,[esi] ; [esi] pointes sur la mémoire....
 
le cache 1 est ballayé pour savoir si une ligne de cache contiens l'adresse...
si c'est pas trouvé on ballaye le L2 qui est -beaucoup- plus lent (idem on cherche une ligne du L2), si c'est pas trouvé on charge une ligne du L2 depuis la ram....
 
donc en fait le bus de donnée "externe" du cpu (le bus 64 bits), passe par "plusieurs" contrôleurs...
 
donc le bloc de 64 bits que tu cherches est au tout début de l'interface cpu<->chipset<->ram (coté cpu).
 
après le cache L1 est capable d'être accédé par plusieurs pipelines de manière concurrente....
 
donc en gros dès le pentium 1:
 
si tu fais un :
 
mov eax,[esi]
mov ebx,[esi+4]
 
les instructions sont éxécutées en parallèle dans le "MEME cycle d'horloge" car les deux pipelines accèdent en parrallèle au cache L1.
 
ça c'était pour le pentium 1...
 
évidemment depuis le temps, les optimisations internes des cpu font que c'est 3000x plus subtile...
 
mais en fait ce qui "voit" les 64 bits du bus externe, pour moi, c'est la logique de contrôle des caches L1/L2....


Message édité par bjone le 20-09-2002 à 01:27:56
n°1823495
bjone
Insert booze to continue
Posté le 20-09-2002 à 01:35:15  profilanswer
 

pour expliquer un peu mieux la cache...
 
tu fais un mov ou autre à l'adresse 68 (décimal on va pas se faire chier)...
 
mov esi,68
 
mov eax,DWORD PTR[esi]
.....
.....
 
si tes lignes de cache L1 (on va dire que y'a pas de L2) font 32 octets.
 
pour le cache ta mémoire est donc découpée en ligne de 32 octets, ce qui veut dire qu'en accèdant à la mémoire, le cache va charger les données de l'adresse 64 à 96 (octet à 64 inclus octet à @96 exclus pour avoir 32 octets)...
 
et l'instruction ne pourra être éxécutée que QUAND le DWORD de l'adresse 68 aura été chargé dans le cache (et pas avant).
 
ce qui veut dire que le pipeline est bloqué en attente que la ligne de cache soit chargé (suffisamment pour accédé au DWORD concerné)...
 
------------------------
 
Par contre tout l'espace mémoire n'est pas -cacheable-
comme la ram vidéo des cartes graphiques et les registres de configuration des périphériques qui peuvent être "mappés" en mémoire, et là tu passe par un système de buffers...


Message édité par bjone le 20-09-2002 à 01:36:13
n°1823497
bjone
Insert booze to continue
Posté le 20-09-2002 à 01:42:27  profilanswer
 

mais disons que tu as:
un contrôlleur au niveau bus de donnée qui accède au reste via le FSB de 64 bits...
un contrôlleur pour le cache L2 entre le L2 et le contrôlleur bus FSB...
un contrôlleur pour le cache L1 entre le L1 et le L2...
 
et une logique entre le "core" d'éxécution du cpu et le L1...
 
pour les accès non cacheables, le "core" s'adresse directement au contrôlleur FSB....
 
et y'a les cas particuliers.....
 
mais le BUS 64 bits du FSB est ........... "loin" du core et des pipelines, et le FSB du CPU est ........ "loin" de la ram, car le chipset peut cacher plein de choses (sdr,ddr,rambus(16bits à haute fréquence),double ddr, double rambus)...
 
----------------
 
après tu as le MMU et la pagination qui s'immice dans tout le bordel...
 
puisque les "applications" sont codées en adresses linéaires/virtuelles, et le MMU remets ça en adresse physique, et ensuite les caches L1/L2 & le bus externe sont consultés....

n°1823503
bjone
Insert booze to continue
Posté le 20-09-2002 à 01:57:24  profilanswer
 

ensuite pour subtiliser encore plus le bordel.....
 
tes instructions:
 
mov eax,...
mov ebx,...
 
elles-mêmes sont des accès mémoires  [:debeman]  
 
ce qui veut dire que phylosiphiquement, quand tu fais:
 
mov eax,DWORD PTR[68]
 
le cpu "doit" charge les instrucions, puis charge les données...
 
les vieux CPU sans caches (6809...), se tapaient les accès mémoires pour le code et les données demandés par le code...
 
 
en prenant ton code à l'adresse 10000
et le données à l'adresse 20000
 
sur les systèmes actuels à cache L1/L2...
 
le L2 est unifié: en gros quand le cpu demande le code ou les données y s'en fout y stoque.
 
le L1 est généralement à architecture HARVARD, ou on sépare le code et les données....
 
--------
 
le cache donnée:
 
est du point du vue "core" d'éxécution en lecture/écriture....
 
logique, sinon il sert à rien...  
 
Mais l'écriture ne se fait que si la ligne contenant la destination est contenue dans le cache (sinon ça part voir dans le cache inférieur =>L2).
 
Sauf à partir du pentium pro (donc valables pour le p2/p3/p4 & athlon) qui lors d'une écriture en ram, et que la ligne n'est pas chargé, charge automatiquement la ligne en cache pour les écritures ultérieures profitent de la bande-passante du cache.
 
------------
 
pour le cache code:
 
lecture uniquement !!!
 
en fait comme le core d'éxécution du cpu peut en général exécuter plusieures instructions en même temps, il faut pouvoir accéder de manière très "concurrente" au cache code...
 
on a donc "sacrifié" la possibilité d'écrire dans le cache code...
 
donc les "octets" du code peuvent monter du L2 au L1...
 
mais si le cpu écrit dans une zone mémoire correspondant à une ligne du cache code, la ligne est invalidée, l'écriture par dans le L2 ou la ram, puis le L1 re-lit la ligne depuis le L2 ou la ram...
 
 
expliquation:
 
si tu fait un (pour rigoler on sait jamais):
 
inc [@code polymorphique]
....
...
...
code polymorphique: cmp eax,ecx
 
la ligne de cache contenant la zone de code ou y'a l'écriture sera purement & simplement giclée pour être rechargée depuis le L2 ou la ram...


Message édité par bjone le 20-09-2002 à 02:02:10
n°1823509
bjone
Insert booze to continue
Posté le 20-09-2002 à 02:16:07  profilanswer
 

subtilité à connaitre si on programme sur un machine bi ou multi-processeur:
 
dans le cas ou tu veuilles pour accélérer le calcul d'un appli, faire ton calcul avec deux ou plusieurs threads qui tourneront donc sur deux ou plusieurs cpu qui accèdent à la même mémoire:
 
code en C:
/////////////////////
 
int état_thread1;
char bidul;
float frags_per_seconds;
int état_thread2;
 
 
// routine du thread1
start1(long param)
{
 for(.....) // boucle de traitement
 {
  utilisation de "état_thread1"
 }
}
 
// routine du thread2
start2(long param)
{
 for(....) // boucle de traitement
 {
  utilisation de "état_thread2"  
 }
}
 
////
donc si les variables (ici globales)
 
état_thread1, bidul, frags_per_seconds, état_thread2
 
sont déclarées avec une proximitée telle qu'elles sont dans la même ligne de cache....
 
et que start1 est éxécuté par le CPU0, et start2 est exécuté par le CPU1...
 
si les routines utilisent les variables en lecture =>
ok pas de problème il y a une copie de la ligne dans chaque CACHE de chaque CPU.
 
si les routines utilisent les variables en lecture/écriture =>
[:sisicaivrai], les caches du CPU se jettent à la figure la ligne mémoire contenant les varibles, et les performances que l'on attendait à progresser s'écroulent misérablement....
 
parceque les cpu passent leur temps à:
 
cpu0 charge la ligne en cache depuis la ram
cpu1 idem
 
cpu0 la modifie et la garde  
 
cpu1 veut modifier la ligne
     beuh elle est plus à jour
 
cpu0 écrit la ligne en ram
 
cpu1 la lit
     la modifie
 
cpu0 à son tour refaire des trucs avec...
 
et blam t'explose les FSB de transferts....
 
resultat saturation & performances en multi-cpu inférieures à du mono-cpu....
 
///////
 
donc attention danger, en multi-thread répartis sur plusieurs cpu, à ne pas accéder des données se trouvant dans la même ligne de cache.... sinon caca les perfs...
 
//////////
//////////
 
ça va j'ai pas trop dérivé ?
 
désolé si je suis out ou que j'ai dit des conneries....


Message édité par bjone le 20-09-2002 à 02:19:00
n°1823515
barbarella
Posté le 20-09-2002 à 02:27:28  profilanswer
 

interessant ...
 
bjone, si un jour t'as envie d'écrire un truc sur onversity, fais moi signe :)

n°1823519
bjone
Insert booze to continue
Posté le 20-09-2002 à 02:36:04  profilanswer
 

là tout en bas l'histoire du cache code en lecture seule:
http://inp.cie.rpi.edu/~cmaier/phdthesis/Chapter1.html
(tiré de là: http://inp.cie.rpi.edu/~cmaier/phd [...] tion.html)

n°1823520
bjone
Insert booze to continue
Posté le 20-09-2002 à 02:36:23  profilanswer
 

barbarella a écrit a écrit :

interessant ...
 
bjone, si un jour t'as envie d'écrire un truc sur onversity, fais moi signe :)




 
merci  :jap:

n°1823530
bjone
Insert booze to continue
Posté le 20-09-2002 à 02:58:33  profilanswer
 

/mode je_me_fais_plaisir on
 
alors par contre détail drôle:
 
le:
 

Citation :


si tu fait un (pour rigoler on sait jamais):  
 
inc [@code polymorphique]  
....  
...  
...  
code polymorphique: cmp eax,ecx  


 
 
donc si la modification du code, entraine le giclage de la ligne conservée hors du cache code du L1...
la modification est donc prise en compte et le nouveau code sera éxécuté.
 
Mais, le pipelines & co, ont des buffers de partout etc,etc et pour le chargement des instructions, il y'a un système de prefetch qui faire des truc très drôle....
 
par exemple:
 
inc BYTE PTR[@yopla+6]
yopla: mov eax,[4654564564]
 
alors là on a un cas où une instruction modife sa suivante immédiate.
 
la ligne de cache va être trashée, et le code mis à jour.
 
MAIS l'instruction suivante, le "mov eax..." qui sera éxécuté sera l'ancienne et non la nouvelle...
 
pourquoi ? parce dans la queue de prefetch des instructions c'est toujours les octets de l'ancienne instruction qui reste... (malgré que la ligne de cache aye été invalidé).
 
je ne sais pas si c'est toujours valable pour les cpu actuels (en tant cas ça marchait pour les 286,386,486 c'était une technique de detection cpu, vu que chaque cpu avait une taille de queue de prefetch plus grande).
 
par exemple ça peut servir de technique anti-debugage...
 
faire un:
 
add [yopla+4],789 ; modification de l'adresse 00542354h
@yopla: call 00542354h
 
en effet dans la foulée le CPU exécute le "call 00542354h" non modifié, mais si avec un debugger logiciel on exécute le programme pas à pas, la queue de prefetch est "vidé" par le debugger logiciel, et c'est le call modifié que le cpu éxécutera :lol:
 
et on peu deviner ce que le call à l'autre adresse pourrait faire :D
 
/mode je_me_fais_plaisir off

n°1823538
bjone
Insert booze to continue
Posté le 20-09-2002 à 03:14:54  profilanswer
 

autre lien sur un "vieux" document (pentium 1, pentium pro, pentium 2):
 
http://www.agner.org/assem/pentopt.zip
 
y'a des explications sur les contraintes des caches, des unitées de prédilection de branchement, etc,etc...
 
mais attention retournement de cerveau assuré... :D

n°1823549
Tetedeienc​h
Head Of God
Posté le 20-09-2002 à 04:23:05  profilanswer
 

bjone, merci, j'ai tout capte :jap:
 
J'ai eu ma reponse :jap:


---------------
L'ingénieur chipset nortiaux : Une iFricandelle svp ! "Spa du pâté, hin!" ©®Janfynette | "La plus grosse collec vivante de bans abusifs sur pattes" | OCCT v12 OUT !
n°1823550
wave
Posté le 20-09-2002 à 04:24:16  profilanswer
 

Citation :

je ne sais pas si c'est toujours valable pour les cpu actuels (en tant cas ça marchait pour les 286,386,486 c'était une technique de detection cpu, vu que chaque cpu avait une taille de queue de prefetch plus grande).  
 
par exemple ça peut servir de technique anti-debugage...  
 
faire un:  
 
add [yopla+4],789 ; modification de l'adresse 00542354h  
@yopla: call 00542354h  
 
en effet dans la foulée le CPU exécute le "call 00542354h" non modifié, mais si avec un debugger logiciel on exécute le programme pas à pas, la queue de prefetch est "vidé" par le debugger logiciel, et c'est le call modifié que le cpu éxécutera    
 
et on peu deviner ce que le call à l'autre adresse pourrait faire    


:lol:
excellent comme méthode!

n°1824094
bjone
Insert booze to continue
Posté le 20-09-2002 à 12:29:08  profilanswer
 

tetedeiench>> tu veux des informations précises sur le Pentium 1 ?

n°1826041
Tetedeienc​h
Head Of God
Posté le 20-09-2002 à 23:49:50  profilanswer
 

bjone a écrit a écrit :

tetedeiench>> tu veux des informations précises sur le Pentium 1 ?




 
Ben je pense pas que ce soit la peine en fait ;)
 
Car bon c'est un peu ce que je vais apprendre pendant ce semestre... mais bon si tu en as sous la main pourquoi pas, mais te casses pas trop le cul non plus ;)
 
Disons que dans ma representation mentale dun truc j;ai legerement omis le cache, et surtout je pensais pas que le CPU ne faisait appel QU'AU cache.
 
Je pensais qu;au cas ou l'info etait pas dans le cache ce bon vieux CPU se tapait encore l'acces memoire...
 
;)
 


---------------
L'ingénieur chipset nortiaux : Une iFricandelle svp ! "Spa du pâté, hin!" ©®Janfynette | "La plus grosse collec vivante de bans abusifs sur pattes" | OCCT v12 OUT !
n°1826063
blazkowicz
Posté le 20-09-2002 à 23:58:30  profilanswer
 

je m'étais bien marré en désactivant le cache de mon P166 : duke3D qui ramait en 320x200 :lol:
 
tout de même... on lit partout que le cache contient les informations les plus fréquemment utilisées. ce serait inexact?
 
ou alors le fait que le CPU n'accède qu'au cache, est-ce vrai pour les deux types de cache (instructions et données) ou seulement pour le cache d'instructions?
(peut-être que la réponse est dans les écrits caballistiques de cette page mais bon... même Kant ou le bouquin de physique quantique que j'ai lu dernièrement sont plus compréhensibles ;))


Message édité par blazkowicz le 21-09-2002 à 00:06:08
n°1826637
mrbebert
Posté le 21-09-2002 à 11:23:45  profilanswer
 

Blazkowicz a écrit a écrit :

je m'étais bien marré en désactivant le cache de mon P166 : duke3D qui ramait en 320x200 :lol:
 
tout de même... on lit partout que le cache contient les informations les plus fréquemment utilisées. ce serait inexact?
 
ou alors le fait que le CPU n'accède qu'au cache, est-ce vrai pour les deux types de cache (instructions et données) ou seulement pour le cache d'instructions?
(peut-être que la réponse est dans les écrits caballistiques de cette page mais bon... même Kant ou le bouquin de physique quantique que j'ai lu dernièrement sont plus compréhensibles ;))



Je dirais plutôt : les dernières données utilisées. Et même un bloc contenant ces dernières données,avec celles qui sont à côté.
En règle générale, je pense que tout ce qui est traité par le CPU passe (et y est stocké) par le L2 puis le L1 (sauf AMD qui utilise les 2 de manière exclusive). Y a peut être des exceptions (les données pour les unités vectorielles ?).

n°1826759
bjone
Insert booze to continue
Posté le 21-09-2002 à 12:11:56  profilanswer
 

alors attention:
 
le cpu peut tourner sans le cache....
 
mais quand le cache est activé, dès que tu fais un accès mémoire sur un espace cacheable, le cache L2 et L1 sont automatiquement mis à jours, et les accès ram générés sont donc dépendants de la taille des lignes de mémoire cache (et ça influe aussi sur l'adresse de départ de "lecture" dans la ram, vu qu'il faut que ce soit aligné sur une ligne de cache).
 
et généralement tout est conçu pour coincider:
 
si tu prends un cpu qui des lignes de cache de 32 octets, ça fait 256 bits, le bus 64 bits du FSB et la ram feront donc en général une rafale de 4 accès 64 bits....
 
donc le donc cache influe sur l'ensemble dès que c'est un espace cacheable.... (mémoire)

n°1826778
bjone
Insert booze to continue
Posté le 21-09-2002 à 12:18:54  profilanswer
 

et la cache a deux fonctionnalitées:
 
1) ok il sert à redonner des informations déjà utilisées avant, ça c'est connu.
 
2) le moins connu mais souvant PLUS IMPORTANT:  
 
quand tu fais un accès mémoire avec un traitement "long" indépendant de la ram, comme le cache fontionne par ligne, pendant que les pipelines bossent, la ligne de cache du cpu continue à être pompée de la ram, et tu as donc un recouvrement de temps...
 
donc si tu prends un exemple ou tu fais un traitement sur tous les éléments d'un tableau, pendant que les pipelines bossent sur un élément, la ligne de cache continue a se charger indépendamment, et quand le traitement sur le premier élément sera terminé, l'accès mémoire sur le suivant sera ptet déjà terminé.
 
 

n°1826810
bjone
Insert booze to continue
Posté le 21-09-2002 à 12:29:59  profilanswer
 

et si tu fais un accès mémoire qui est à cheval sur deux lignes de cache, par exemple:
 
cpu avec ligne de cache de 32 octets..
 
tu fais un accès DWORD (32bits) à l'adresse 30 décimal...
(donc 30 à 33 inclus)
 
donc l'accès en mémoire se fera à "cheval" sur les lignes qui serait de 0000 à 0031 inclus et de 0032 à 0063 inclus...
 
(et les 2 lignes ne sont pas en mémoire cache)
 
le cpu (dumoins le pipeline) devra donc attendra que la ligne de cache 0000-0031 se soit complètement chargé de la ram, et la ligne de cache 0032-0063 commençe....
 
là on a un cas défavorable le cpu est bloqué (pour 4 octects à lire, il faudra attendre que 32(1ère ligne)+2(2ième ligne) soit lus de la ram pour que l'éxécution continue)....

n°1826860
bjone
Insert booze to continue
Posté le 21-09-2002 à 12:49:37  profilanswer
 

tetedeiench >> si tu veux des infos sur le Pentium 1, tu va chez intel > developer > literature > dans les manuals tu cherches un "Intel Architecture Optimization Manual" référence 242816-003.
 
beaucoup de choses sont décrites sur le Pentium 1 et le Pentium Pro.

mood
Publicité
Posté le   profilanswer
 


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Hardware
  Carte mère

  [technique] Proco 32 bits, memoire 64 bits, variables 64 bits... ???

 

Sujets relatifs
Ca vaut quoi la mémoire Dane Elec???Pourquoi les CG n'ont pas de slots pour mettre de la mémoire ???
[Trou de memoire] Une barrette mem PC133 sur mobo PC100 ?pb de libération d'espace mémoire sur DD
bizarre ... test mémoire au boot DDR DIm Clock: 266mhz ????memoire samsung est ce la bonne ?
radeon 9700 et le bi-ecran ?? memoire diviser par 2?Pb de vidage de la memoire Physique sous 2000
Problème de barettes de mémoire SDRAM !vidage memoire et reboot
Plus de sujets relatifs à : [technique] Proco 32 bits, memoire 64 bits, variables 64 bits... ???


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR