-
Data: 2012-02-15 22:31:30
Temat: Re: [hrdw] ssd ze zrownoleglaniem
Od: " " <f...@g...pl> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]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/
Następne wpisy z tego wątku
- 15.02.12 22:38 Edek
- 15.02.12 23:11 bartekltg
- 15.02.12 23:16 bartekltg
- 15.02.12 23:50 Edek
- 16.02.12 16:17 bartekltg
- 16.02.12 20:13 Edek
- 17.02.12 09:56 M.M.
- 17.02.12 10:00 Adam Klobukowski
- 17.02.12 10:39 M.M.
- 17.02.12 10:51 M.M.
- 17.02.12 13:23 bartekltg
- 17.02.12 14:37 M.M.
- 17.02.12 15:05 bartekltg
Najnowsze wątki z tej grupy
- Grok zaczął nadużywać wulgaryzmów i wprost obrażać niektóre znane osoby
- Can you activate BMW 48V 10Ah Li-Ion battery, connecting to CAN-USB laptop interface ?
- We Wrocławiu ruszyła Odra 5, pierwszy w Polsce komputer kwantowy z nadprzewodzącymi kubitami
- Ada-Europe - AEiC 2025 early registration deadline imminent
- John Carmack twierdzi, że gdyby gry były optymalizowane, to wystarczyły by stare kompy
- Ada-Europe Int.Conf. Reliable Software Technologies, AEiC 2025
- Linuks od wer. 6.15 przestanie wspierać procesory 486 i będzie wymagać min. Pentium
- ,,Polski przemysł jest w stanie agonalnym" - podkreślił dobitnie, wskazując na brak zamówień.
- Rewolucja w debugowaniu!!! SI analizuje zrzuty pamięci systemu M$ Windows!!!
- Brednie w wiki - hasło Dehomag
- Perfidne ataki krakerów z KRLD na skrypciarzy JS i Pajton
- Instytut IDEAS może zacząć działać: "Ma to być unikalny w europejskiej skali ośrodek badań nad sztuczną inteligencją."
- Instytut IDEAS może zacząć działać: "Ma to być unikalny w europejskiej skali ośrodek badań nad sztuczną inteligencją."
- Instytut IDEAS może zacząć działać: "Ma to być unikalny w europejskiej skali ośrodek badań nad sztuczną inteligencją."
- U nas propagują modę na SI, a w Chinach naukowcy SI po kolei umierają w wieku 40-50lat
Najnowsze wątki
- 2025-07-23 Gdańsk => Programista Delphi <=
- 2025-07-23 Gdańsk => Programista Mainframe (z/OS, Assembler) <=
- 2025-07-23 Warszawa => Starszy inżynier DevOps (AWS) <=
- 2025-07-23 Gdańsk => Mainframe (z/OS, Assembler) Developer <=
- 2025-07-23 Kraków => Senior Fullstack Engineer (Low-Code Platform) <=
- 2025-07-23 Wrocław => Senior Key Account Manager IT <=
- 2025-07-23 Trójmiasto => Head of Social Media <=
- 2025-07-23 Rzeszów => Spedytor Międzynarodowy <=
- 2025-07-23 Lublin => ERP Implementation Consultant (AP Module) <=
- 2025-07-23 Środa Wielkopolska => SAP FI/CO Internal Consultant <=
- 2025-07-23 Warszawa => Inżynier oprogramowania .Net <=
- 2025-07-23 Kraków => Kotlin Developer <=
- 2025-07-23 Żerniki => Dyspozytor Międzynarodowy <=
- 2025-07-23 Warszawa => Java Developer <=
- 2025-07-23 Wrocław => Konsultant wdrożeniowy (systemy controlingowe) <=