Vlákno názorů k článku Test: paměti mají čtyřistakrát delší latenci než procesory od vid - Fuj, AT&T syntax :) Ale inak fajn clanok, niekedy...
-
vid (neregistrovaný)Fuj, AT&T syntax :)
Ale inak fajn clanok, niekedy je zaujimave neverit manualom a pozriet sa na vec v praxi. Len este k tomu co napisali ostatni par detailov:
> Takových instrukcí je sto, pak je skok na začátek, opakujeme pětsetkrát (důvod pro opakování je případné vyprůměrování doby, kdy se instrukce načítaly do instrukční cache)
pre nacitanie do instrukcnej cache staci kod alignovat na co najokruhlejsej hranici, a potom ho pred samotnym meranim 1x nechat prebehnut. Pri dalsom behu uz bude v instruction cache.
> Přesnějšího měření by bylo možné dosáhnout při zakázaném přerušení, ale nevím, co by se pak stalo při případném page-faultu (jestli by si Linux přerušení zase povolil, kdyby třeba potřeboval mmapovat program z disku nebo swapovat, čemuž by se částečně dalo předejít zamknutím stránek v RAM). Pak by mělo smysl výsledky z jednotlivých opakování průměrovat. Jelikož jsem ale nechtěl riskovat zamrznutí systému a na většině měřených počítačů stejně nejsem root, dále jsem tento problém neřešil.
1. Neviem co presne urobi zakazanie preruseni v user mode v Linuxe (zalezi ako linux nastavil IOPL), ale dost pochybujem ze by vyvojari linuxu boli taki sprosti aby ho normalne povolili. Ved to by potom mohol ktorykolvek program zablokovat cely system.
2. (aj pre p. Tesarika) Zakazanie preruseni (STI) nezakazuje vynimky, takze page fault sa handluje normalne aj pri IF=0.
Este k tomu co sa pisalo v inych komentaroch:
> a jak se lisi ruzne kompilery co se tyka vyuziti ruznych registru, aby se instrukce
staly nezavislymi a dalsi chytre zmeny v kodu ktere provede kompiler ???
Ohladne C kompilatorov: Zevraj najlepsi je Intelacky kompilator, aj co som videl ukazky dokaze dost drsne paralelizovat instrukcie, aj ked to nieje este celkom dotiahnute. Co som pozeral kod tak MSVC and GCC su tak zajedno, obidva dobre. Osobne mi viac sedel MSVC, pri GCC sa mi zdalo ze tam defaultne hadze vela zbytocneho svinstva, ale mozno je to len tym ze MSVC viem lepsie pouzivat. Ostatne by som radsej nepouzival.
> 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.
Samotne precitanie polozky zo strankovacej tabulky su v zavislosti od typu strankovania 2-4 pristupy do pamate. 4 ale len v IA32e resp. long mode.
> Nemáte někdo přístup k počítači, kde je gcc i icc? Moc by mě zajímalo srovnání, jestli to intel optimalizuje na svoje procesory lépe. Tvrdí se, že na čísla bývá o pár procent nebo desítek procent rychlejší.
Ja mam obidva, ale nejak som to zatial neskusal. Ale co som videl ukazky na internete, ak je ten intelacky kompilator dobre nastaveny, dokaze take veci o ktorych sa msvc alebo gcc ani nesniva.
> Zajimalo by mne na ktere typy uloh je mozne uplatnit tenhle low-level typ profilingu?
V podstate na vsetky, kuknes co ti vyliezlo z kompilatoru a rozmyslas ako by to islo spravit lepsie. Ale to by bolo nehorazne vela roboty. Otazka by skor mala zniet na ktore casti programu MA ZMYSEL tento typ profilingu uplatnit. A tam je to jasne:
1. Ma to cele zmysel iba ak program naozaj potrebuje urychlit
2. Ma to zmysel len na bottleneckoch programu, aj to len v pripade ze program je CPU/RAM bound. Pri hrach sa pokail viem vecsinou caka na GPU, pri vecsine programov na disk alebo co, a tam takato optimalizacia nic neriesi.
Typicky priklad kde to ma zmysel su vypoctovo narocne veci - neuronove siete, simulacie typu Folding@home, atd.
A ze je problem vypat strankovanie pod operacnym systemom: nesuhlasim, podla mna to skoro vobec nieje problem, akonahle uz raz si v kernel kode. Staci si v alokovat kus identity-mapped pamate (windows to vie urcite a linux IMO musi tiez, napriklad DMA to tusim vyzaduje), nakopcit do nej svoj position-independent kod, skocit nan a vypat strankovanie - nic sa nedeje. -
> Fuj, AT&T syntax :)
No jo, Stallmanova oblibena. Asi mel rad M 68k. Podle me je to blbost, protoze pak se tezko pouziva kod urceny pro jine kompilatory. Syntax ma byt takova jakou pouziva vyrobce CPU. Ale poucili se, napr. ARM ma na gcc temer uplne standardni syntax.
> pre nacitanie do instrukcnej cache staci kod alignovat na co najokruhlejsej hranici,
Ono se to opakuje nejen kvuli cache, ale taky aby se vyprumerovala RDTSC instrukce, ktera na intelu trva 100 taktu. Sice se jeji efekt snazim odcitat, ale je to k nicemu, protoze neni zaruceno kdy presne se provede (out-of-order execution). Skoro soudruhy od Intelu podezrivam ze implmentovaly TSC jako citac se seriovym prenosem aby usetrili. Kdyz pak chteji chytnout jeho hodnotu tak musi mit druhy registr do ktereho to kopiruji bit po bitu (LSB first), kazdy takt jeden bit (aby dostali spravnou hodnotu i kdyz nastal prenos). To by trvalo 64 taktu a ten zbytek uz jsem ochoten verit ze trva mikrokodu nez to dopravi do edx:eax.
> 2. (aj pre p. Tesarika) Zakazanie preruseni (STI) nezakazuje vynimky, takze page fault sa handluje
> normalne aj pri IF=0.
To jiste ano, ale kdyz to dopadne jako cteni stranky z disku tak disk oznamuje ukonceni DMA prerusenim. Mohli by sice na nej cekat ve smycce, ale to by tam pak musely byt 2 ruzne kody cteni te stranky jeden pro IF=0 a druhy pro IF=1. To se mi nechce moc verit. Myslim si, ze bud to nebude fungovat vubec (vytuhne), nebo si to preruseni povoli. Urcite to tu nejaky kernel guru bude vedet....
> A ze je problem vypat strankovanie pod operacnym systemom...
To je problem protoze na takovou vec bych musel byt root (coz na vetsine testovanych pocitacu nejsem).
> Samotne precitanie polozky zo strankovacej tabulky su v zavislosti od typu strankovania 2-4 pristupy
> do pamate. 4 ale len v IA32e resp. long mode.
Predpokladejme ze nejsem v long modu. Pak je treba nacist GDT a LDT, ale pitch neni zase tak veliky aby se pozice v GDT moc menila, takze se GDT se dostane rychle do cache (pokud je tam aspon nejaky preread) a pak uz je to jen 1 pristup do LDT. Aspon si to tak predstavuju. -
vid (neregistrovaný)> Skoro soudruhy od Intelu podezrivam ze implmentovaly TSC jako citac se seriovym prenosem aby usetrili.
Od urcitej rady (uz neviem ktorej) TSC uz nepocita cykly CPU, ale len sa veselo inkrementuje nezavisle od CPU. Myslim ze kvoli tomu aby bola zarucena viacmenej rovnaka rychlost pripocitavania na viacerych jadrach aj ked jedno z nich chvilu idlovalo. Pre zaujimavost, u mna na CoreDuo sa TSC pripocitava zasadne v nasobkoch 10 :)
> To jiste ano, ale kdyz to dopadne jako cteni stranky z disku tak disk oznamuje ukonceni DMA prerusenim.
To je pravda, dobry postreh :)
> Myslim si, ze bud to nebude fungovat vubec (vytuhne), nebo si to preruseni povoli. Urcite to tu nejaky kernel guru bude vedet....
Ako som pisal, najskor proste nastavi IOPL na hodnotu mensiu ako 3, po com STI/CLI bude pristupovat k VIF a nie k IF. Ale kazdopadne, urcite nedovoli usermode aplikacii pristupit k IF, to by bolo chore.
>> Samotne precitanie polozky zo strankovacej tabulky su v zavislosti od typu strankovania 2-4 pristupy do pamate. 4 ale len v IA32e resp. long mode.
> Predpokladejme ze nejsem v long modu. Pak je treba nacist GDT a LDT, ale pitch neni zase tak veliky aby se pozice v GDT moc menila, takze se GDT se dostane rychle do cache (pokud je tam aspon nejaky preread) a pak uz je to jen 1 pristup do LDT. Aspon si to tak predstavuju.
Tu si asi nieco pleties. Do GDT pri pristupe do pamate nieje preco pristupovat (ak myslis ze kvoli segment base, tak nie, ta sa uklada do zvlast registra uz pri nastaveni selektoru). Pristupuje sa do strankovacich struktur, teda ak nieje adresa v TLB tak su to 1 alebo 2 extra pristupy do pamate pri klasickom strankovani (podla toho ci je stranka 2MB alebo 4KB), 2 az 3 extra pristupy pri PAE-36 strankovani, 1 extra pristup pri PSE-36 strankovani, a 3 az 4 extra pristupy pri PAE-64 strankovani. -
vid (neregistrovaný)Na tych inteloch kde to znicili uz mas performace monitoring, ktory je vraj ovela preciznejsi. Ale este sa tomu nevenoval a neviem ti zodpovedne povedat nakolko to vie merat rychlost relativne maleho kusu kodu.
Len viem ze samotne koncepcia poctu CPU cyklov ktore kod trva, je uz v dnesnych procesoroch dost fiktivna, kedze mas veci ako out-of-order execution atd. Tak sa netreba cudovat ze spravili to co spravili.
Ale tak celkovo s tebou suhlasim, bola to sikovna vecicka, len uz jej doba skoncila.
