Routines en cache processeur - Page 1

Bonjour.
Ca fait un bon moment que ça me titille... je me demandais s'il y avait la possibilité de contrôler l'utilisation du cache sous Windows et d'y placer ses routines. Par exemple, sur GBA, il y a un attribut pour du code ou pour une fonction, et le compilo s'occupe de copier le code en IWRAM (cache) et le code exécuté là-dedans est environ exécuté 5 fois plus rapidement (ça a redonné des espoirs à mon moteur de Sonic tout pourri )
D'ailleurs, je pense bien que ça doit être beaucoup plus rapide, car selon memtest, j'ai un truc genre 1.3 Go/sec pour la RAM, et 19 Go/s pour le cache L2... (sur la GBA c'est de l'ordre de ~3.5 MHz pour la ROM et ~16 MHz pour le cache et la différence est déjà énorme)
Y'a-t-il un moyen de faire l'équivalent sous Windows? Si oui, comment? Si non, alors Windows n'utilise-t-il le cache que pour lui, ou bien comment s'y prend t-il pour coper les routines, que faire pour m'assurer que mes routines soient exécutées en cache, etc. (au cas où, j'ai un cache L2 de 512k et un L1 de 8k... y'a-t-il des procos qui ont moins que ça? Plus, je pense bien mais moins...)

19 Go/s pour le cache L2 ? Ca me paraît bcp, c quoi ton proc ?

A part ça, le processeur gère tout seul comme un grand ce qu'il veut garder en cache ou pas : il suffit juste que tu t'assures que les petites boucle internes tiennent bien dans ton cache L1... Tu peux aussi faire un prefetch si tout ne tient pas dans le cache, que tu sais ce dont tu auras besoin dans peu de temps et que tu veux éviter que le bus RAM-processeur ne fasse rien, mais je pense que ça concerne plus les données que le code.

Et j'ajouterais que l'IWRAM de la GBA n'a rien à voir avec un cache... c'est de la RAM normalement accessible, mais reliée au CPU par un bus de 32-bit (contrairement à la RAM externe et au GamePak)... on peut donc utiliser le jeu d'instructions ARM, et forcement c'est plus rapide.

Ok, merci de me prévenir.
Pollux: comment faire un prefetch?
Et comment m'assurer que mes boucles tiennent dans 512k? Mon appli fait bien 40k au total. Par exemple, si je prends une routine de rotation, elle sera automatiquement "optimisée"?
Et selon memtest toujours le L1 est à 20 Go/sec (comparé au L2 qui va à 19, ça ne change rien donc je m'en fous). Mais comme j'ai fait ces tests il y a quelques temps, j'ai pu me gourrer...
Y'a-t-il un document qui explique comment Windows s'y prend pour savoir que mettre en cache?
Par exemple: ma boucle fait 3k, elle utilise ma routine de rotation qui fait 4k et ma routine de dessin de sprites qui prend 2k (j'exagère). Il n'y a pas assez pour les 8k -> que va faire Windows?
Même scénario pour le L2...
[Edit]: Je me suis effectivement gourré pour les vitesses, c'est 22.9 pour le L1 et 19.5 pour le L2 (pour ce que ça change...)

c pas Windows qui gère ça, c'est le processeur lui-même... (enfin p-ê que y a qques interactions avec l'OS, mais je ne les connais pas et elles doivent avoir un effet négligeable)

Si ta routine de rotation + ta routine de dessin de sprites font plus de 8k, alors il vaudra mieux éviter d'alterner les appels aux deux routines, mais tout dépend de leurs temps d'exécution respectifs, du nombre d'alternances par seconde que tu veux faire, etc... En plus je ne crois pas que le cache L1 du P4 contienne du code x86, mais plutôt des µops, donc c possible que le seuil soit un peu en dessous de 8k.

Pour ce qui est des vitesses, je n'y crois pas vraiment... Sur mon Athlon 2600+ je peux faire du memset à 8 Go/s (1 cycle / 4 octets) en L1 et à 4 Go/s (2 cycles / 4 octets) en L2... Et mon cache L1 fait qd même 64 ko, donc il est possible que celui du P4 qui est (je crois) plus petit soit encore plus optimisé et que la différence soit plus grande.

En tout cas, si tu veux avoir des stats détaillées sur l'utilisation du cache par ton programme, utilise Valgrind (et code sous Linux), c'est vraiment super précis.

Pourtant la vitesse est indiquée par memtest, je viens de le faire. Le reste, je ne peux pas te dire, si ce n'est que c'est bien un P4.
Je n'ai pas testé avec les memset, d'ailleurs, comment tu fais pour avoir accès directement à ton cache L1/L2? Genre tu crées un buffer:
unsigned long test[16000];
Et tu fais un memset sur le buffer pour voir combien de temps ça met pour 64k? Et à ce moment-là, le buffer sera bien en L2?

(et code sous Linux)

Merci ...mais... non. J'y viendrai un jour mais c'est pas aujourd'hui.
Pollux> Ces routines seront appelées en boucle lors d'un jeu par exemple...

nitro :
En tout cas, si tu veux avoir des stats détaillées sur l'utilisation du cache par ton programme, utilise Valgrind (et code sous Linux), c'est vraiment super précis.

Ah tiens, il n'y a pas que des fonctions de débuggage ? Et ça émule quel type de cache ? Athlon ? Pentium ? ou un pipo-truc entre les deux (mais avec une taille paramétrable) ?

Parce que je pense que calculer précisément des timings, ça doit être très loin d'être trivial...

Valgrind est un framework d'instrumentation de code, après tu instrumentes ce que tu veux (memcheck, heap profiler, cache profiler, thread debugger, etc...)

Cachegrind is a cache profiler. It performs detailed simulation of the I1, D1 and L2 caches in your CPU and so can accurately pinpoint the sources of cache misses in your code. It identifies the number of cache misses, memory references and instructions executed for each line of source code, with per-function, per-module and whole-program summaries. It is useful with programs written in any language. Cachegrind runs programs about 20--100x slower than normal.

ah ouais, ça a l'air sympa

par contre le cache L1 a l'air d'être systématiquement inclusif

Pour ce qui est des vitesses, je n'y crois pas vraiment... Sur mon Athlon 2600+ je peux faire du memset à 8 Go/s (1 cycle / 4 octets) en L1 et à 4 Go/s (2 cycles / 4 octets) en L2... Et mon cache L1 fait qd même 64 ko, donc il est possible que celui du P4 qui est (je crois) plus petit soit encore plus optimisé et que la différence soit plus grande.

C'est vrai que c'est abusé. A la limite, vu sa fréquence, la moitié de la vitesse du cache serait nécessaire (1 cycle pour prendre 32 bits). Mais c'est peut-être dû au Hyper threading, qui donne deux entrées "données" vers le proço (il est détecté comme s'il y en avait deux, quoi). Peut-être que comme un con, memtest teste pour le premier processeur, puis pour le deuxième (virtuel celui-ci) et il additionne les deux. Le résultat serait bien une vitesse deux fois trop élevée... Mais je n'en suis pas sûr, et je n'ai pas d'option dans mon BIOS pour désactiver l'HT...

Faudrait déjà couper le multitache de Windows, car le fait de passer d'une tache à l'autre réduit le bénéfice du cache à 0 ! Dans une GBA, y'a qu'une appli qui tourne, on est donc certains du code actuellement executé. Sur PC, le fait de passer d'un code à l'autre on invalide le cache sans arret, vu que les routines du cache ne correspondent jamais avec la tache courante.

En DOS par contre, ça va booster grave. Je te conseille alors vivement de passer sur le bon vieux DOS4GW avec le compilo DJGPP (http://www.delorie.com/djgpp) ! Et Allegro et/ou SDL si tu veux un résultat graphique correct...

Kochise

Euh, y a pas non plus 10 millions de task switch par seconde, hein... Et tu peux tjs désactiver le multitâche en mettant ton processus avec la priorité "temps réel" si tu veux voir ce que ça change, mais ça va juste modifier de qques % (dans les 5% je crois) le tps d'exécution -- on est pas du tout dans les facteurs 10 de cache vs pas cache.

La plus grosse différence qu'apporte le multitâche, c'est surtout que tu vas avoir une proportion très variable des timeslices à chaque seconde...

En clair et en français dans le texte : si tu es en multitache, le cache ne sert pas à grand chose vu qu'il passe de CACHE MISS en CACHE MISS ! Pour les bench qui coupent le multitache pour avoir le CPU rien qu'à eux, là par contre...

Kochise

Plutôt que de me prendre pour un neuneu, tu ferais mieux de vérifier si tu dis pas des conneries... A ton avis, pkoi l'OS ne fait pas de context switch tous les 50 cycles ? (ou, vu autrement, pkoi tous les fabricants de processeurs s'évertuent à faire des plus gros caches alors que ça sert tellement à rien puisque personne ne tourne sous DOS ?) C'est précisément pour préserver la localité en cache, et faire en sorte que les programmes exécutés passent une partie négligeable de leur temps à aller re-chercher les trucs qui sont sortis du cache... Petit calcul : à 1 Go/s de bande passante pour la RAM, avec un cache de 512 ko, on peut recharger entièrement le cache 2000 fois par seconde. Or mon petit doigt me dit qu'un OS classique (Windows ou Linux) fait bcp moins de task switch que ça par seconde, et qu'une bonne partie des task switch ne vide pas le cache L2 (en se contentant par exemple d'une partie du cache L1), donc qu'en réalité la perte est négligeable et qu'heureusement un cache sert encore à quelque chose sous un OS multitâche...

Va jouer chez les amateurs de spec : http://www.active-hardware.com/english/benchmarks/benchmarks.htm

Quand t'auras toi aussi écrit un p'tit kernel multitache en asm 68030 et 486, avec un task switch de 20 ms, et benché le tout avec PUIS sans cache, tu verras bien que dans ce cas, le cache passe son temps à se réajuster. OK, j'avoue qu'avec mon test et la taille des routines, le tout tenait bien dans le cache. Mais sous Windows avec un PhotoShop qui tiens en 200 MO, avec des pleugines qui font 4 Mo, et ton p'tit cache de 256 Ko, je vois pas vraiment ce que ça apporte. De toute façon, les constructeurs, du moment qu'ils peuvent augmenter un chiffre de spec pour faire rèver les p'tits n'enfants...

Allez, un peu d'infos pour pas pleurer idiot :

http://www.oempcworld.com/support/Memory_and_Cache.htm
http://www.mersenne.org/bench.htm
http://www.simhq.com/_technology/technology_010a.html

http://www.pcguide.com/ref/mbsys/cache/charSpeed-c.html
http://macspeedzone.com/archive/art/edge/misc/backsidecachespeed2.html
http://www.cpu-central.com/wwwboard/msg.asp?id=64230

T'inquiètes, je fait semblant d'être odieux :P

Kochise

PS, pour t'amuser un peu :

http://www.roadside-software.com/CS/

[cite]T'inquiètes, je fait semblant d'être odieux :P[cite]
Le problème, c'est pas tellement que t'es odieux, c'est surtout que tu racontes n'importe quoi

Quand t'auras toi aussi écrit un p'tit kernel multitache en asm 68030 et 486, avec un task switch de 20 ms, et benché le tout avec PUIS sans cache, tu verras bien que dans ce cas, le cache passe son temps à se réajuster.

Je suis très content pour toi que tu aies écrit un "p'tit kernel multitache en asm 68030 et 486", mais ça ne nous avance pas bcp : je ne sais pas du tout sur quelle plateforme tu as testé (il doit bien y avoir un facteur 1000 entre la puissance de calcul d'un Athlon à 2GHz et un 68000 à 10MHz, ce qui peut t'excuser partiellement ) ni quelle taille de cache tu avais ni sur quel programme tu testais, et je ne vois dans ton post aucun argument rationnel pour expliquer tes résultats... Moi je t'ai donné plus haut un petit calcul tout simple, avec un task switch de 20 ms : même en faisant la supposition que les cache L1 et L2 sont ENTIEREMENT vidés à chaque task switch et qu'on a un cache L2 assez gros (512 ko), alors le cache sera re-rempli avec une quantité de MOINS de 512 ko d'accès mémoire, c'est-à-dire que par seconde, on fera au plus 50*512 ko d'accès en trop, soit une bande passante de 25 Mo/s, bien ridicule par rapport aux 1000 Mo/s que peut fournir n'importe quel bus mémoire récent...

Et, miracle, avec un petit bench, j'ai bel et bien l'impression que le cache a une importance cruciale :

~/bench-2004-07-09 $ cat cache-bench.c

#include <stdio.h>

int main(int argc,char **argv) {
    char *s=argv[1];
    int n=atoi(s)/sizeof(int);
    int *p=alloca(n*sizeof(int));
    int i,j;
    for (i=0;i<100000;i++) {
        for (j=0;j<n;j++)
            p[j]=i;
        asm volatile(""::"g"(p));
    }
}

~/bench-2004-07-09 $ gcc -O2 cache-bench.c -o cache-bench
~/bench-2004-07-09 $ time (./cache-bench.exe 200000|./cache-bench.exe 200000|./cache-bench.exe 200000)
(; ./cache-bench.exe 200000 | ./cache-bench.exe 200000 | ./cache-bench.exe ; ) 6.65s user 0.02s system 32% cpu 20.533 total
~/bench-2004-07-09 $ time (./cache-bench.exe 200000|./cache-bench.exe 200000|./cache-bench.exe 200000)
(; ./cache-bench.exe 200000 | ./cache-bench.exe 200000 | ./cache-bench.exe ; ) 6.89s user 0.02s system 33% cpu 20.745 total
~/bench-2004-07-09 $ time ./cache-bench.exe 200000
./cache-bench.exe 200000 6.73s user 0.01s system 96% cpu 6.995 total
~/bench-2004-07-09 $ time ./cache-bench.exe 200000
./cache-bench.exe 200000 6.73s user 0.01s system 96% cpu 6.993 total
~/bench-2004-07-09 $ time ./cache-bench.exe 600000
./cache-bench.exe 600000 154.70s user 0.00s system 93% cpu 2:45.61 total

Hoho, surprise ! (là c'est un Athlon avec 256ko de cache)
Avec 200ko de mémoire allouée, ça prend 6.75 secondes ; en en faisant tourner 3 simultanément, ça prend exactement le même temps (tiens tiens) ; et en en faisant tourner un seul avec 3x plus de mémoire (donc ça ne tient plus du tout dans le cache) ça prend quasiment 3 minutes

OK, j'avoue qu'avec mon test et la taille des routines, le tout tenait bien dans le cache.

Euh, tu pipotes : justement, c'est seulement dans ce cas-là qu'un bench serait pertinent : sinon, le cache ne servirait à rien de toute façon.

Mais sous Windows avec un PhotoShop qui tiens en 200 MO, avec des pleugines qui font 4 Mo, et ton p'tit cache de 256 Ko, je vois pas vraiment ce que ça apporte.

Achète-toi des lunettes Ce n'est pas parce que les 1000 fonctions de Photoshop prennent 204 Mo de mémoire que les boucles internes vont prendre 150 Mo de mémoire chacune... Je soupçonne que tous les calculs intensifs de Photoshop sont des filtres dont le coeur ne prend pas forcément bcp de place. Cela dit, tu n'as pas tort sur un point : effectivement, les routines auront tendance à prendre de plus en plus de place avec le temps, à mesure que les ordinateurs deviennent plus puissants. C'est aussi pour ça que la taille des caches doit s'agrandir, parce que comme tu le sais (peut-être ), un cache ne sert strictement à rien si on s'amuse à parcourir une boucle plus grande que sa taille sans jamais revenir sur un élément déjà vu [bon, ce n'est pas tout à fait exact pour un cache peu associatif, qui peut continuer à apporter encore un peu pour les tailles légérement plus grandes que sa capacité].


Ensuite je n'ai rien à faire de tous tes liens, si ce n'est que ça me désole un petit peu que même en ayant lu tout ça et en ayant programmé un noyau, tu racontes des conneries en insultant les autres (tiens, ça me rappelle un certain amateur d'exonoyaux et de BSD, ça )

Et si par hasard tu avais envie de me contredire, comme je serais moyennement motivé pour écrire un autre post de 3 km, tu seras gentil de m'expliquer *rationnellement* pkoi tu as raison et de m'expliquer *rationnellement* pourquoi 1] mes évaluations quantitatives et 2] mes mesures objectives ne peuvent pas s'appliquer.

Quand t'auras toi aussi écrit un p'tit kernel multitache en asm 68030 et 486, avec un task switch de 20 ms, et benché le tout avec PUIS sans cache, tu verras bien que dans ce cas, le cache passe son temps à se réajuster

han, ca sent le petit prodige incompris et non reconnu qui se sent plus peter pke il a code un truc qu'il estime etre bien et innaccessible a toutes ces pauvres larves rempant sur les forums qui OSENT (c) le contredire et qu'il se fait un devoir d'eclairer avec son immense savoir?

en fait nan, ca doit etre le fils de Kevin :]

Ou son copain

Diffamation et attaques personnelles ©

Ce n'est pas dégrandant ...

sBibi :
han, ca sent le petit prodige incompris et non reconnu qui se sent plus peter pke il a code un truc qu'il estime etre bien et innaccessible a toutes ces pauvres larves rempant sur les forums qui OSENT (c) le contredire et qu'il se fait un devoir d'eclairer avec son immense savoir?

Ah p't'être bien tiens, vu sous cet angle Bwaaaaa...

Pollux :
tu racontes des conneries en insultant les autres

Où ça ? Où ça j'insulte ? J'emet juste de 'profondes' réserves vis-à-vis des 'extraordinaires' performances du cache, y'a rien de répréhensible à cela :/ Regarde la démonstration par l'absurde :

Pollux :
on est pas du tout dans les facteurs 10 de cache vs pas cache

Puis :

Pollux :
Avec 200ko de mémoire allouée, ça prend 6.75 secondes ; en en faisant tourner 3 simultanément, ça prend exactement le même temps (tiens tiens) ; et en en faisant tourner un seul avec 3x plus de mémoire (donc ça ne tient plus du tout dans le cache) ça prend quasiment 3 minutes

Exact dans un sens, 22 fois plus rapide exactement (d'après ton test, attend la suite). Mais je doute fort que tous les processus s'amusent à réserver directement sur la pile avec alloca, mais plutôt avec malloc, voire avec new (quoique j'ai pas vu de difference avec Visual C, alloca et malloc, mëme combat).

Ton exemple est vicieux vu qu'il consiste à faire 100000 'simple' écritures sur la taille d'un tableau (taille passée en paramètre). Or dans un cadre d'utilisation 'normale' (c'est à dire pas juste avec des routines simples pour faire cracher les chiffres), y'a le processeur qui s'en mèle pour faire des calculs savants, des branchements divers (qui eux invalident le prefetch), etc...

Mon processeur, un Athlon 1700+ (L1 core et data de 64 Ko, L2 de 256 Ko, même caractéristiques que ton 2600+), donne les résultats suivant avec ton code avec comme paramètre :

40000 -> 7 secondes
80000 -> 15 secondes (sortie du cache L1 de 65536 octets)
160000 -> 30 secondes
320000 -> 70 secondes (sortie du cache L2 de 262144 octets)
480000 -> 152 secondes

Je ne suis pas allé à 600000, vu que ce n'était pas la peine !

Il apparait qu'entre 40000 et 80000, il n'y a pas de différence si ce n'est que strictement un facteur de 2 (normal, 2 fois plus de données). Le cache L1 au même niveau que le cache L2 ? A la sortie du cache L2 (entre 160000 et 320000), je ne note qu'un facteur de 16% (70 secondes au lieu des 60 théoriquement prévues pour 2 fois plus de données). Concernant la différence entre 160000 (dans le cache L2) et 480000 (dehors), on obtient 68% (152/90) de différence par rapport au temps prévus (3 fois plus de données, mais 5 fois plus lent au lieu de 3).

Ce n'est donc MEME PAS 2 fois plus rapide, alors je ne comprend pas ton résultat de 22 fois (154.7/6.73) :/ Cette différence de 68% je l'obtient aussi sur mon 68030 (71% dans son cas) avec deux caches de 256 octets (on ne rit pas dans la salle, SVP) !

Dans l'exemple de PhotoShop, si tu ne veux pas entendre parler de la taille des routines executées par le processeur (ce qui concerne en fait le cache d'instruction) mais plutôt les données traitées (comme dans ton exemple), tu ne fais à peine tenir dans les 256 Ko de ton cache de donnée qu'une image de 320*240 en 24 bits. Pas très très représentatif des résolutions de la mort des cartes 3D actuelles, plutôt genre 1280*1024 (2.5 Mo en 16 bits, le double en 32 bits).

Je suis d'accord en ce qui concerne les perfs de l'IWRAM de la GBA, vu la taille de l'écran et donc la mémoire à traiter, mais ce n'est pas aussi recevable en ce qui concerne les PC. Eux, ce qui peu allègrement les booster, ce serait une utilisation plus massive des instructions SIMD (qui peuvent elles accélérer jusqu'à 8 foix le calcul), trop régulièrement snobées par les codeux. En s'accroche trop souvent au cache ou à la FSB... Quoique ça aide (à hauteur de 68% donc)

Pour te faire penser à ce que je viens de te dire, dis toi 'simplement' que l'un des composant essentiel du noyau de Windows, kernel32.dll, fait 'juste' 972 Ko. Bien sûr, il n'est pas chargé en entier dans le cache, juste les parties executées régulièrement. Mais kernel32.dll est loin d'être le seul composant appelé, y'a aussi gdi32.dll, 251 Ko !

D'ailleurs au fait, si on avait voulu optimiser un poil avec une vieille ruse d'apache, un 'for (i=100000-1;i>0;i--)' puis un 'for (j=n-1;j>0;j--)' auraient étés plus judicieux (pas de chargement de valeur, juste une comparaison avec 0). Mais bizarrement, c'est 45% plus lent sur un Athlon =:/ Va comprendre...

Et désolé de briser ton rève et de jouer un peu le garde-fou. Sans rancune, tes connaissances sont précieuses et je ne les remets pas en doute, n'ais de craintes... Moi ami !

Kochise

PS : Nah nah, moi pas BSD, moi TOS !

PS2, les liens classiques de Kochise :

http://www.cpuid.com
http://www.codeproject.com/cpp/HighPerfComp.asp : Un p'tit bench entre le CPU et le SIMD

Regarde la démonstration par l'absurde :

Tu sais ce que ça veut dire au moins ? parce que je la vois pas moi la démonstration par l'absurde... (tu démontres quoi d'ailleurs ?)

Mais je doute fort que tous les processus s'amusent à réserver directement sur la pile avec alloca
, mais plutôt avec malloc, voire avec new (quoique j'ai pas vu de difference avec Visual C, alloca et malloc, mëme combat).

C'est beau les mots en gras , mais pour bien faire tu devrais carrément en faire des liens vers les pages correspondantes d'une doc online

réserver directement sur la pile avec alloca, mais plutôt avec malloc, voire avec new

Je crois que comme te l'a dit Sally tu devrais effectivement aller chercher des infos sur le sujet dans une doc.
[11/07 - 12:30, edit pour ne pas faire un autre post...]

tu ne fais à peine tenir dans les 256 Ko de ton cache de donnée qu'une image de 320*240 en 24 bits. Pas très très représentatif des résolutions de la mort des cartes 3D actuelles, plutôt genre 1280*1024 (2.5 Mo en 16 bits, le double en 32 bits).

Euh attention, tu n'as pas besoin de faire tenir l'image dans le cache. Le simple fait d'accéder séquentiellement (ou meme pas séquentiellement, si tu te déplaces de pas beaucoup à chaque fois, genre application d'un filtre 3x3 à ton image) aux données te fais profiter largement du cache.

t1 mais lol...
oue dsl je suis pas tres constructif... seulement mdr

au fait...

Où ça ? Où ça j'insulte ?

(dt..)
t'insulte pas vraiment a proprement parler, du moins avec ma definition d'"insultes", c'est plutot juste que tu prends tlm pour des cons (et que comme 98% des personnes qui reagissent comme toi, t'as tord...)

Pour te faire penser à ce que je viens de te dire, dis toi 'simplement' que l'un des composant essentiel du noyau de Windows, kernel32.dll, fait 'juste' 972 Ko. Bien sûr, il n'est pas chargé en entier dans le cache, juste les parties executées régulièrement. Mais kernel32.dll est loin d'être le seul composant appelé, y'a aussi gdi32.dll, 251 Ko !

heu, quel rapport entre la taille d'une dll et le cache?
si je fais une dll de 35 Mo, avec seulement une boucle de 3 instructions qui s'execute 99.9% du temps, j'ai du mal a voir en quoi le cache (a moins d'etre mal concu) serait concerne par les 35Mo - quelques octets restants...

EDIT: raaah putain de merde [cite]....
yAro, faudrait que tu clone la balise [cite] en balie [quote], stp, t'as une version de yn en anglais avec des anglophones qui viennent sur certains forums, faut penser a eux #desinteresse# surtout que ca doit etre rien du tout a faire, une pauvre ligne a rajouter, et tu rendrais heureux(ses) tellement de personnes

moi j'aime bien les debats destructeurs

erf t'as poste ca juste pendant que j'editais pour rajouter une partie pas destructrice a mon post

./26 > dis-le ailleurs sinon il va pas lire ^^

Kochise
:

Pollux :
tu racontes des conneries en insultant les autres

Où ça ? Où ça j'insulte ? J'emet juste de 'profondes' réserves vis-à-vis des 'extraordinaires' performances du cache, y'a rien de répréhensible à cela :/

Oué, euh, excuse-moi mais c pas vraiment profond ce que tu racontes (à part dans la bêtise)
Et puis si "En clair et en français dans le texte", "Va jouer chez les amateurs de spec" et "Allez, un peu d'infos pour pas pleurer idiot" c'est pas me prendre pour un con (alors que tes posts sont ridicules de la tête aux pieds), je me demande ce que c'est

Regarde la démonstration par l'absurde :

Pollux :
on est pas du tout dans les facteurs 10 de cache vs pas cache

Puis :

Je dis facteur 10 parce que c l'ordre de grandeur, mais effectivement je ne m'étais pas trop trompé...

Pollux
: Avec 200ko de mémoire allouée, ça prend 6.75 secondes ; en en faisant tourner 3 simultanément, ça prend exactement le même temps (tiens tiens) ; et en en faisant tourner un seul avec 3x plus de mémoire (donc ça ne tient plus du tout dans le cache) ça prend quasiment 3 minutes

Exact dans un sens, 22 fois plus rapide exactement (d'après ton test, attend la suite).

Bien, au moins tu sais compter ^^ (mais cf plus bas, sur mon ordinateur [pas celui de mes parents] le dual channel et la fréquence supérieure du bus font qu'il n'y a qu'un facteur 11).

Mais je doute fort que tous les processus s'amusent à réserver directement sur la pile avec alloca
, mais plutôt avec malloc, voire avec new (quoique j'ai pas vu de difference avec Visual C, alloca et malloc, mëme combat).

Tu crois que le processeur fait la moindre différence entre la pile et le tas ? Les différences ne se situent qu'au niveau de la gestion qu'en fait l'OS... Au niveau de la localité en cache, la seule chose qui pourrait changer, ce serait la contiguïté des données allouées si on fait plusieurs allocations, mais ici ce n'est pas pertinent puisqu'on alloue un seul gros bloc.

Ton exemple est vicieux vu qu'il consiste à faire 100000 'simple' écritures sur la taille d'un tableau (taille passée en paramètre). Or dans un cadre d'utilisation 'normale' (c'est à dire pas juste avec des routines simples pour faire cracher les chiffres), y'a le processeur qui s'en mèle pour faire des calculs savants

Bon, je vais souligner un point où tu n'as pas entièrement tort : faire un bench de mémoire, ça ne veut pas forcément dire faire un bench réaliste. Ce qui veut dire qu'effectivement, si on fait juste un calcul qui n'a pas besoin de bande passante mémoire, le cache n'apportera rien. De même qu'un bus mémoire avec une fréquence supérieure n'apporterait rien dans ce cas-là. Mais il se trouve que, précisément, les applications ont besoin à la fois de puissance de calcul et de bande passante mémoire

(et, puisque tu es un "spécialiste" des 68k et 486, je pense que tu n'es pas sans savoir que la bande passante vers la mémoire principale a augmenté bcp moins vite que la puissance de calcul, d'où la nécessité de caches -- d'ailleurs on peut voir la RAM comme la première forme de cache)

des branchements divers (qui eux invalident le prefetch), etc...

Euh ?

Bon allez je suis grand prince, je te fais un supermegabench pour te montrer que tous tes points sont faux :

~/bench-2004-07-11 $ cat cache-bench.c

#include <stdio.h>

int main(int argc,char **argv) {
    char *s=argv[1];
    int n=atoi(s)/sizeof(int);
    int *p=alloca(n*sizeof(int));
    int i,j,k;
    char rnd[32];
    for (i=0;i<32;i++)
        rnd[i]=(rand()%217)&1;
    for (i=0;i<30000;i++) {
        for (j=0;j<n;/* slap les smileys qui apparaissent dans le code :| */)
            for (k=0;k<32;k++,j++)
                if (rnd[k])
                    p[j]+=i;
        asm volatile(""::"g"(p));
    }
}

~/bench-2004-07-11 $ gcc -O2 cache-bench.c -o cache-bench
~/bench-2004-07-11 $ time ./cache-bench.exe 400000
./cache-bench.exe 400000 10.53s user 0.01s system 99% cpu 10.571 total
~/bench-2004-07-11 $ time (./cache-bench.exe 400000|./cache-bench.exe 400000|./cache-bench.exe 400000)
(; ./cache-bench.exe 400000 | ./cache-bench.exe 400000 | ./cache-bench.exe ; ) 10.31s user 0.01s system 33% cpu 31.141 total
~/bench-2004-07-11 $ time ./cache-bench.exe 1200000
./cache-bench.exe 1200000 59.00s user 0.00s system 97% cpu 1:00.61 total

(j'ai pris des tailles 2x plus grandes parce que là je suis sur un Barton avec 512ko de cache)
Comme tu peux le constater, il y a :
* des lectures
* des écritures
* des calculs
* des branchements totalement imprédictibles (car aléatoires) à chaque itération
Et en plus une bonne partie du coût (test de rnd[k] et incrémentation) ne dépend pas du fait que le tableau "p" réside en cache ou non. (et accessoirement, on accède au tableau "p" 2x moins souvent que dans l'exemple d'avant)

Et pourtant, on remarque un facteur 6x de différence ! (contre 11x si on ne rajoute pas les branchements imprédictibles)

Note que les branchements sont effectivement imprédictibles, il y a une différence de 1.5 secondes si j'affecte des constantes (tjs 0 ou tjs 1) à rnd[k]... (et ce n'est pas une optimisation du compilo)

Mon processeur, un Athlon 1700+ (L1 core et data de 64 Ko, L2 de 256 Ko, même caractéristiques que ton 2600+), donne les résultats suivant avec ton code avec comme paramètre :

40000 -> 7 secondes
80000 -> 15 secondes (sortie du cache L1 de 65536 octets)
160000 -> 30 secondes
320000 -> 70 secondes (sortie du cache L2 de 262144 octets)
480000 -> 152 secondes
Je ne suis pas allé à 600000, vu que ce n'était pas la peine !

L'absence de différence L1-L2 est probablement normal, à cause de l'overhead de la boucle.
Et note que ton cache L2 est exclusif, donc la sortie du cache L2 se fait à 320ko... Tu peux peut-être essayer un peu plus loin, mais ça m'étonne que tu ne trouves qu'un facteur 1.7 entre L2 et RAM

Ce n'est donc MEME PAS 2 fois plus rapide, alors je ne comprend pas ton résultat de 22 fois (154.7/6.73) :/ Cette différence de 68% je l'obtient aussi sur mon 68030 (71% dans son cas) avec deux caches de 256 octets (on ne rit pas dans la salle, SVP) !

Moué, uploade ton binaire sur yN pour voir... (lien Upload à côté du formulaire de post)

Dans l'exemple de PhotoShop, si tu ne veux pas entendre parler de la taille des routines executées par le processeur (ce qui concerne en fait le cache d'instruction) mais plutôt les données traitées (comme dans ton exemple), tu ne fais à peine tenir dans les 256 Ko de ton cache de donnée qu'une image de 320*240 en 24 bits.

Sauf que les algos sont précisément conçus pour avoir une bonne localité en cache, i.e. faire 42 passes sur chaque pixel (et ceux aux alentours) plutôt que faire 42 passes sur toute l'image...

Pas très très représentatif des résolutions de la mort des cartes 3D actuelles, plutôt genre 1280*1024 (2.5 Mo en 16 bits, le double en 32 bits).

N'importe quoi. On peut avoir une bonne localité en cache même en 3d (et j'en sais qqch d'ailleurs faudrait que je m'y remette ^^)

Je suis d'accord en ce qui concerne les perfs de l'IWRAM de la GBA, vu la taille de l'écran et donc la mémoire à traiter, mais ce n'est pas aussi recevable en ce qui concerne les PC. Eux, ce qui peu allègrement les booster, ce serait une utilisation plus massive des instructions SIMD (qui peuvent elles accélérer jusqu'à 8 foix le calcul), trop régulièrement snobées par les codeux. En s'accroche trop souvent au cache ou à la FSB... Quoique ça aide (à hauteur de 68% donc)

Connais pas.
(mais *moi* je vais pas m'exprimer sur qqch que je connais pas )

Pour te faire penser à ce que je viens de te dire, dis toi 'simplement' que l'un des composant essentiel du noyau de Windows, kernel32.dll, fait 'juste' 972 Ko. Bien sûr, il n'est pas chargé en entier dans le cache, juste les parties executées régulièrement. Mais kernel32.dll est loin d'être le seul composant appelé, y'a aussi gdi32.dll, 251 Ko !

cf les posts ci-dessus

D'ailleurs au fait, si on avait voulu optimiser un poil avec une vieille ruse d'apache, un 'for (i=100000-1;i>0;i--)' puis un 'for (j=n-1;j>0;j--)' auraient étés plus judicieux (pas de chargement de valeur, juste une comparaison avec 0). Mais bizarrement, c'est 45% plus lent sur un Athlon =:/ Va comprendre...

L'optimisation x86 moderne et l'optimisation 68k, c pas vraiment pareil...

Et désolé de briser ton rève et de jouer un peu le garde-fou.