bartekltg <b...@g...com> napisał(a):

> 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-
dev
> eloper-instruction-set-reference-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;)
>
>
mniej chodzi o zaskoczenie czy tajemnice (choc chyba rejestry
maja swoje powody by byc szybsze ) co po prostu o zwykla istotnosc
tego faktu


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/