Discussion :

[yoloosis]

Bonjour tout le monde !
Pour ceux qui ne connaissent pas Shake, il s'agit d'un logiciel de compositing video qui fonctionne sous Mac OS et Linux. Brievement, ca fait du traitement d'image, une ligne a la fois (ce qui permet de traiter de tres lourdes images sans saturer la RAM). Note : une ligne est appele un scanline.

Dans la documentation du SDK de Shake, page 41, il est ecrit : "The number of scanlines in the block is set so that the image buffer fits into the CPU's L2 cache, which greatly enhances memory access times and rendering performance".

Surprise... On peut vraiment faire ca ? Comment peut-on forcer le contenu de la memoire cache du CPU ? Est-ce que ca ne perturbe pas le fonctionnement du microcode CPU ?

Merci de vos lumieres !

[Jean-Marc.Bourguet]

Comment peut-on forcer le contenu de la memoire cache du CPU?

En n'utilisant pas plus de memoire que ce qui tient dans le cache.

Est-ce que ca ne perturbe pas le fonctionnement du microcode CPU?

Je ne vois aucun rapport entre les deux.

[yoloosis]

Je pensais que le microcode du CPU etait entierement responsable du remplissage des caches L1 et L2, donc que forcer son contenu a partir d'un programme utilisateur n'etait pas une bonne chose.

Ils y a toujours plusieurs programmes qui fonctionnent en paralle, donc qui partagent le cache, non ? Comment faire en sorte que son buffer de traitement d'image soit inferieur a la taille du cache, comment etre certain qu'il tienne en entier ?

[harsh]

Utiliser un langage bas niveau je pense

Blague a part, si c'est possible, ce sera plutot au niveau des options du compilo que tu devrais trouver un truc pareil je pense (un petit man gcc ou man g++ sous unixoide)

[Jean-Marc.Bourguet]

Je pensais que le microcode du CPU etait entierement responsable du remplissage des caches L1 et L2, donc que forcer son contenu a partir d'un programme utilisateur n'etait pas une bonne chose.

On ne force pas le contenu, on se contente dans un programme utilisateur d'acceder a la memoire en faisant en sorte que la plupart des acces ont lieu dans de la memoire "recemment" utilisee, donc avec une forte probabilite d'etre en cache. Naturellement, ces techniques n'ont pas beaucoup d'effet si un changement de contexte a lieu au milieu et donc que le cache est invalide par un autre process.

(Au fait, depuis le milieu des annees 80, la tendance est a virer le micro-code. On peut s'amuser a decrire le mouvement RISC comme etant le remplacement de la memoire contenant le micro-code par de la memoire cache.)

[yoloosis]

Par curiosite, comment peut-on avoir acces de facon portable entre les plateformes aux informations telles que la taille des caches, la presence de ceux-ci, le nombre de coeurs d'un CPU ?

[Jean-Marc.Bourguet]

Blague a part, si c'est possible, ce sera plutot au niveau des options du compilo que tu devrais trouver un truc pareil je pense (un petit man gcc ou man g++ sous unixoide)

Les optimisations pour gerer correctement les caches sont plutot des optimisations de haut niveau. Certains compilateurs le font, mais je ne pense pas que gcc en fasse partie (mais je n'ai pas verifie).

Generalement, ca se fait a la main, en modifiant les algo pour travailler par bloc, comme ce que decrit le premier message.

[Charlemagne]

Par curiosite, comment peut-on avoir acces de facon portable entre les plateformes aux informations telles que la taille des caches, la presence de ceux-ci, le nombre de coeurs d'un CPU ?

Grace à l'instruction CPUID des P4. Je sais pas pour les autres.

[mat.M]

Surprise... On peut vraiment faire ca ? Comment peut-on forcer le contenu de la memoire cache du CPU ? Est-ce que ca ne perturbe pas le fonctionnement du microcode CPU ?

A moins de preuve du contraire ( et j'attends la démonstration ) tu ne peux pas ; le cache d'un CPU c'est une petite mémoire interne qui est gérée par le CPU.
Sauf s'il ya des instructions spécifiques et intrinséques assembleur du CPU qui permettent de gérer cette mémoire

La mémoire cache ne se force pas : elle est utilisée par le "pipeline" d'instructions du CPU

Si tu as : mov ax,10....inc ax ce qui donne en code i86
B81000 mov ax,10
40 inc ax
dans la mémoire cache tu auras d'abord B8..10..00 ( ou inverse selon Big endian little endian ) puis 40

[mat.M]

Bonjour tout le monde !
"The number of scanlines in the block is set so that the image buffer fits into the CPU's L2 cache, which greatly enhances memory access times and rendering performance".

Cela suppose que Shake alloue des blocs de mémoire d'une certaine granularité ou plus petit commun dénominateur ; la taille de la mémoire cache de niveau 2 est testée( sans doute avec CPUID de Charlemagne );
si tu as par exemple 32k alors les traitements sur l'image se font par + ou - 32k ( je dirais 16 ou 24 ) ceci comme ils le disent afin de limiter les cycles CPU et sauts en mémoire adressages de tableaux ASM avec pointeur ( toujours ASM pas pointeur C ).

[Jean-Marc.Bourguet]

Par curiosite, comment peut-on avoir acces de facon portable entre les plateformes aux informations telles que la taille des caches, la presence de ceux-ci,

Indirectement, tu peux mesurer précisément (ce qui n'est pas facile à faire de manière portable), le temps d'exécution d'une boucle comme

Code :

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

1
2
3
4
5
    for (off_t pos = 0; pos < maxBlockSize; pos += blockSize) {
        for (int i = 0; i < blockSize; ++i) {
            buffer[i] += 1;
        }
    }

pour différentes valeurs de blockSize. Tu devrais remarquer des sauts correspondant aux différents caches.

le nombre de coeurs d'un CPU ?

Je ne vois pas.

[Charlemagne]

Indirectement, tu peux mesurer précisément (ce qui n'est pas facile à faire de manière portable), le temps d'exécution d'une boucle comme

La librairie ATLAS utilise (je crois) une méthode dans le genre. Il est surement possible de prélever de la source le bout de code correspondant;

A moins de preuve du contraire ( et j'attends la démonstration ) tu ne peux pas ; le cache d'un CPU c'est une petite mémoire interne qui est gérée par le CPU.
Sauf s'il ya des instructions spécifiques et intrinséques assembleur du CPU qui permettent de gérer cette mémoire

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
--SSE1--
void _mm_prefetch(char * p , int i );
PREFETCH
Loads one cache line of data from address p to a location closer to the processor. The value i specifies the type of prefetch operation: the constants _MM_HINT_T0, _MM_HINT_T1, _MM_HINT_T2, and _MM_HINT_NTA, corresponding to the type of prefetch instruction, should be used.
 
void _mm_stream_pi(__m64 * p , __m64 a );
MOVNTQ
Stores the data in a to the address p without polluting the caches. This intrinsic requires you to empty the multimedia state for the MMX register. See Understanding the EMMS Instruction section.
 
void _mm_stream_ps(float * p , __m128 a );
MOVNTPS
Stores the data in a to the address p without polluting the caches. The address must be 16-byte aligned.
 
void _mm_sfence(void);
SFENCE
Guarantees that every preceding store is globally visible before any subsequent store.
 
--SSE2--
void _mm_stream_pd (double *p, __m128d a);
MOVLPD
Stores the data in a to the address p without polluting caches. The address p must be 16-byte aligned. If the cache line containing address p is already in the cache, the cache will be updated.
p[0] := a0
p[1] := a1

voir surtout le prefetch

[mat.M]

Ok merci Charlemagne pour ces indications