Tenhle nápad s testováním CPU není až tak špatný, ale neodpustím si několik poznámek:
Nepochopil jsem tu sekci Měření v Linuxu. Správný postup je přece zajistit, že adresovaná paměť bude vždy residentní, viz mlock(2), a potom zakázat přerušení po celou dobu trvání testu.
Pokud vdím, autor při testování latence RAM pozapomněl na stránkování, resp. na velmi omezenou velikost TLB cache. Nejlepší by bylo stránkovací jednotku úplně vypnout, ale to je docela problém, pokud má test běžet v nějakém OS. Jako druhé nejlepší řešení se mi tak pro PITCH=1MiB zdá projít celou oblast jednou (a tím naplnit TLB cache), pak přičíst nějaký malý offset, tak aby adresa zůstala ve stejné stránce, tj. třeba 2KiB), ale aby CPU nemohl znovu využít již naplněnou L2 cache (takže např. 2KiB), a provést vlastní test.
Mate uplnou pravdu. Kdyz to budu chtit zmerit vedecky, tj. izolovat od sebe
jednotlive priciny latence, tak bych to mel delat pokud mozno bez OS, se
zakazanym prerusenim, s vypnutym strankovanim a v konfiguracnich bitech
procesoru bych jeste mohl zakazat cache, nebo aspon vynutit cache flush kdyz
to potrebuju (matne si vzpominam ze nejmin jedno z toho je mozne na intelech
docilit nejakou privilegovanou instrukci).
Jenze lenost mi zabranila v implmentaci neceho tak velkolepeho. Proto jsem
se rozhodl pro mene vedecky (statisticky) pristup, kdy vsechny hierarchie
cache vcetne TLB beru jako jednu cernou skrinku. Slo mi o to, vedet kolik
radove ztratim za cache miss a kolik maximalne (pokud se k nemu neprida
jeste swap nebo taskswitch nebo jina pohroma). Tim jsem prestal na TLB
myslet a ani v clanku jsem ji nezminil (coz je urcite chyba).
Myslim ale, ze pro praxi je asi lepsi takovyto souhrnny test i kdyz je
vlastne na pul cesty mezi aplikacnimi testy a pomerne jednoznacnym merenim
aritmetickych instrukci. Napriklad,kdybych to delal "velkolepe" bez OS a mel
vypnutou cache tak bych nejspis neprisel na to ze Intel Xeon ma lepsi
chovani cache po jednorazovem preplaveni daty.
Nicmene s tou TLB jste me privedl na myslenku, ze vlastne netestuju dobu
pristupu k pameti ale nejmene dobu 2 pristupu, protoze nejspis temer vzdy
vypadnu z TLB. A vlastne jsou to mozna 3 pristupy, protoze ty 2 instrukce
MOV se asi provadeji zaroven na vsech pocitacich (a pouze intel pak nestihne
udelat jeste tu inktementaci pointeru). Vysvetluju si to tak ze ve stare
verzi, kdy se provadely instrukce seriove, se pri TLB-miss nacetla (alespon)
do cache nejspis i TLB-entry potrebna pro nasledujici instrukci.
V nove verzi kdy bezi 2 MOVy zaroven a vytvori tak 2 vyjimky (nejakeho
vnitrniho typu -- intel doplnuje TLB na rozdil od PowerPC automaticky a
negeneruje opravdovou vyjimku pro OS) se asi nacitani serializuje a mozna ze
se nekontroluje ze tataz data uz mame... Bohuzel tohle vysvetleni prilis
neobjasnuje namerene casy, a navic by se musel cist naraz asi 1KB
TLB-polozek abychom tim pokryli pitch=1MB. Takze to asi taky nebude dobre.
Rozhodne ale duvod nebude v prereadu jak pisu v clanku, protoze se ten efekt
projevuje i na starych CPU (K6) o kterych pochybuju ze neco takoveho mely.
Musi to byt neco spolecneho pro vsechny ia32 procesory a TLB se jako takove
vysvetleni uplne nabizi.
Jeste by se nabizelo jako vysvetleni prokladani pristupu do pameti. Kdyz se
jde do jine banky DRAM tak je mozne v dobe kdy cekame na vybavani zadat v
urcitem casovem okne command pro jinou banku. Tuhle vlastnost myslim mely
SDRAMky i v dobach K6. Takze v OLDVERSION by to vypadalo tak ze zada
pozadavek na precteni TLB a temer zaroven s nim i pozadavak na data (z
predchozi adresy pro kterou TLB uz mame z minula prectenou). V nove verzi
ale instrukce zadaji o doplneni TLB zaroven a protoze TLB-entries bydli ve
stejne bance DRAM, prokladani nebude mozne. Totez pak plati o datech,
protoze kdyz jsou jen 1MB od sebe tak budou vetsinu casu ve stejne bance. To
by uz vysvetlovalo proc je to na vetsine pocitacu priblizne 2* delsi. Ale
asi je to taky blbost.