W dniu 2012-02-15 21:26, f...@g...pl pisze:

> bylo fajnie zaznaczone ze storage na wspolczesnych kompach jest
> struktura hierarchiczną o pieciu a nawet siedmu stopniach, najnizej
> jest dysk twardy a najwyzej (tu byc moze mala niespodzianka):
> rejestry

Ale co w tym dziwnego. Przecież to od zawsze
'jest na wykładach'
http://wazniak.mimuw.edu.pl/index.php?title=MN06#Hie
rarchia_pami.C4.99ci
Żadne zaskoczenie, żadna tajemnica;)


> bylo pokazywane ze rejestry maja ok 6 razy wieksza przepustowosc niz
> najlepszy cache (uzasadniane bylo jakos tym ze adresowanie rejestru
> wymaga kilka bitow a cache wiele razy wiecej itp) - i ze korzystnie
> jest miec

Bardzo rozsądne wytłumaczenie tłumaczenie.
Hmm, coś nie mogę znaleść porównania prędkośći
mov rejest rejestr
mov rejestr pamiec
mov pamiec rejestr

http://www.intel.com/content/dam/doc/manual/64-ia-32
-architectures-software-developer-instruction-set-re
ference-manual-325383.pdf
ale te półtora tysiąca stron mogło to gdzieś ukryć;)

> ich duzo (mz przydalo by sie przynajmniej 16 a jeszcze lepiej i z 64
> czemu nie) tak by przynajmniej fastcalle moc robic bez problemu -
> tymczasem x86 ma biedne pare i dla mnie jest to niewytlumaczalne (tj
> niezrozumiale ale jakos nie moge sie doszukac wytlumaczenia)

Jeśli doża liczba rejestrów jest potrzebne 'aby szybko
robić fastcall' to napraqwdę jest to najmniejszy problem:)

Rejestrów nie jest tak mało

16 bitór miały 6+2
32 bity mają 6+2
64 bity mają 14+2

wygląda więc, że cie posłuchali i zwiększyli ich ilość;)

No i do tego mamy jeszcze sporo rejestrów 'dodatkowych'
koprocesora/MMX (8 po 80/64 bitów)
i 16 XMM (po 128bitów) przynajmniej na x64.

Ręcznie bym tego nie ogarnął;)

> obok innych ciekawych informacji bylo nt tego ze kosci ramu sa 50
> nanosekundowe (a byla to ksiazka chyba gdzies tak z 2003 czyli dosyc
> stara) i nietrafienie w cache kosztuje wlasnie te 50 ns - wiec tu
> przynajmniej nie jest tak zle bo ta liczba (czyli totalne
> nietrafienie) dla mnie urastala juz do legendy :/

Widzisz ten link na samej górze. Był na tej grupie jakieś 5 razy.

Jest tam tabelka:

Algorytm ijk ikj bikj(16) bikj(32) DGEMM ATLAS DGEMM
Czas (s) 320.49 24.28 8.68 30.45 25.72 2.58
Mflop/s 10.06 132.67 371.11 105.79 125.24 1248.53

Te algorytmy robią to samo. Praktycznie tak samo (tyle samo mnożeń!
bardziej skomplikowane algorytmy robią nawet więcej dodatkowych rzeczy)
Główna różnica to 'inna kolejność działań'.

Algorytm naiwny olewający sprawę cache jest ponad 100 razy gorszy.

Przeanalizuj różnicę między "ijk" a "ikj". Trywialna zamiana,
a przyspieszenie o kilkanaście razy.

[na różnych precesorach wyniki są oczywisćie różne. choćby
algorytmy blokowe mają optimum dla różnych rozmiarów bloku,
ale prawidłowość pozostaje
T_naiwny >> T_{z pomysłem} > T_specjalistyczny ]

Oczywiście, trzeba wiedzieć, gdzie to jest istotne.
Tu mielimy wielokrotnie dany obszar, więc zysk jest duży.
Gdzie indziej może nie być. W przeszukiwaniu binarnym bazy
danych nie będzie;)


pzdr
bartekltg