Re: Nehalem et innovations
C'est deja le cas d'une certaine maniere tu stock une addresse virtuelle dans le cache et tu fais la traduction d'adresse dans une TLB.
De maniere generale il n'y a plus aucun gain visible au dela d'une associativite de 16 et les gains sont mineurs au dela de 8 (en considerant 1 seul thread), obtenir une associativite "complete" apporterait qq chose de minime aux microprocesseurs modernes (quelques pourcents en moyenne si la latence et le debit restaient les memes).
Le probleme de la solution de virtualiser une fois de plus l'espace d'adressage et que tu es force d'avoir une TLB plus complexe, en effet chaque acces au cache doit etre verifie par les TLB comme accedant a une page dans laquelle il a les droits de lecture ou d'ecriture appropries. Le traffic de coherence arrive aux caches en adresses physiques et aurait besoin d'etre traduit aussi afin de pouvoir verifier sa presence dans le cache, ralentissant de facto tout les snoops et les autres processeurs.
Une TLB plus compliquee implique une augmentationde la latence d'acces a moins que le cache soit completement virtuel (ce qui n'est plus le cas a ma connaissance depuis que les CPUs supportent le SMP pour des problemes de coherence).
Re : Nehalem et innovations
Je ne pensais pas à utiliser une table de correspondance mais de substituer directement au niveau de l'instruction l'adresse d'origine par l'adresse physique en cache.
Cette adresse serait allouée lors du prefetch instruction ou du decode par le controleur de cache en fonction des disponibilités et des instructions déja chargées dans le pipe.
Le chargement de la donnée en cache a l'adresse allouée aurait lieu alors que l'instruction descend le pipe de manière à être disponible lorsque la lecture doit être faite.
La donnée ne pourrait être évincée du cache tant qu'une instruction l'utilisant serait présente dans le pipe.
Re: Nehalem et innovations
Les adresses ne sont pas connues avant l'etage d'execution (sauf un cas eventuel ou tu aurais une bonne partie de l'addresse en immediat dans l'instruction) ou tu calcule l'adresse (en lisant un/des registres), c'est donc quasi impossible: tu peux bien entendu essayer de predire ce genre de choses tres en amont mais le taux de bonnes predictions est faible, tres faible.
Le plus tot pour faire la substitution c'est dans l'AGU et il faudrait que ta fonction de hashage ne prenne pas plus longtemps que l'add que tu dois deja faire pour calculer l'addresse.
Meme une analyse complexe du code a du mal a determiner si une instruction est utilisee pour produire une adresse ou une donnee etant donne qu'ils utilisent les memes instructions (certains utilisent meme lea pour des donnees). Et meme savoir si une instruction appartient au flot de calcul d'adresse ne permet pas de determiner l'adresse finale en avance.
Si on pouvait avoir une bonne idee de l'adresse aussi en avance que tu le dis l'ensemble des caches de donnees des CPU actuels auraient 0 cycles de latence, on prefetcherai directement les donnees dans les registres juste avant de les utiliser.
Il y a des techniques qui essayent de predire les adresses et de transferer les donnees par des registres plutot que par le cache entre des instructions dependantes, ca s'appelle "memory renaming" et c'est a peu pres la seule technique que je connaisse qui reussisse dans certains cas particuliers a deviner une adresse a l'avance. Ca ne peut pas s'appliquer a une traduction systematique des adresses.
Re : Nehalem et innovations
OK, merci pour l'explication.
Pour tenter de résumer, c'est parce que les adresses des données sont le résultat de calculs et non pas écrites en dur dans le code x86 que le problème de prédiction se pose.
un mov eax, [eax] est problématique, pas un mov eax, 00FF00EEh.
Citation:
Si on pouvait avoir une bonne idee de l'adresse aussi en avance que tu le dis l'ensemble des caches de donnees des CPU actuels auraient 0 cycles de latence, on prefetcherai directement les donnees dans les registres juste avant de les utiliser.
On ne peut pas dans ce cas générer un code x86 n'utilisant que des adresses (relatives ?) écrites en dur ? (je ne me rends pas bien compte de ce que ca implique, désolé si c'est une aberration...)
Re: Nehalem et innovations
Ca rendrait au moins le code enorme et diminurait les performances de maniere tres importante a moins de changer tout le cache d instruction et les decodeurs.
Je suppose que ca ne plairait pas non plus aux compilos.