Dnia Sun, 5 Oct 2014 04:16:25 -0700 (PDT), s...@g...com
> W dniu niedziela, 5 października 2014 12:01:53 UTC+2 użytkownik Jacek Radzikowski
napisał:
> Fakt, że nie jest to odwzorowanie "wielkiego" obszaru pamiąci jest
> oczywisty. Natomiast mechanizm kojarzenia stron jest dla mnie
> niezrozumiały. Od strony HW, mamy jakiś tam adres zapisany na
> n-bitach. Jasne, że możemy ten adres w przypadku "dużych" pamięci
> podzielić na strony, bądź innymi słowy na kostki pamięci. OK, no
> ale wtedy cykl dostępu do pamięci to 2 kliknięcia zegarka na
> licznik adresowy, bądź 2 rozkazy zapisu od strony procka do
> jakiegoś tam rejestru adresowego. O co mi chodzi? Nosz

To robi sprzet a nie program. Ale owszem, trwa.

> kurdelebelans, nie da się z jednej kostki odczytać w tym samym
> czasie danych z 2-ch różnych adresów!! No bo niby jak ?

No, pamieci dwuportowe sa, moga byc i wiecej portowe, ale glowny RAM
taki nie jest. Natomiast cache ... kto wie.

>> Tym żeby wiedzieć jaki adres w cache odpowiada adresowi w pamięci
>> zajmuje się tablica translacji.
> A skąd owa tablica ma wiedzieć o wynikach działania programu/obliczeń
>i jak przypisać skoki tam gdie trzeba?

Nie, to sie dzieje automatycznie.

Masz pamiec cache C, moze i 32-bit, ale podzielona na ramki po np 16
bajtow. Adres w niej dzielimy bitowo na f:w, gdzie f to nr ramki, a w
- slowa/bajtu w ramce. Podobnie pamiec glowna R, gdzie adres dzielimy
na p:f:w.
f i w w obu pamieciach sa takie same, wiec kazda ramka f:* w C jest
przypisana do jednej z mozliwych lokalizacji *:f:* w pamieci R.
Do ktorej aktualnie - to jest zapisane w osobnej pamieci S, ktora
przechowuje starsza czesc adresu p.

No i teraz - jak procesor ma potrzebuje siegnac do jakiegos adresu
pamieci, to dzieli go na p:f:w, odczytuje S(f), i jesli tam jest
akurat p, to wie ze moze odczytac z pamieci C(f:w).
A jesli nie ma, to przepisujemy cala ramke R(p:f:*) do cache C(f:*),
a do S(f) zapisujemy p. I nastepnym razem juz jest.
Sam odczyt calej ramki z SDRAM idzie w miare szybko, bo sa do tego
stosowne funkcje.

Tak wyglada pierwsza wersja, ktora ma te wade, ze procesor moze sie
odwolywac do roznych obszarow pamieci o przypadkowo zgodnym f.
Wiec powiekszamy pamiec C np 4 razy, adresujac ja s:f:w, dajemy 4
pamieci S - nazwijmy je S0 do S3, i teraz jesli procesor potrzebuje
adresu p:f:w, odczytujemy wszystkie Sn(f), sprawdzamy czy jest w
ktorejs p, i jesli jest, do odczytujemy dane z C(n:f:w).
A jak nie ma, to dobrze by bylo znalezc najdawniej uzywane n,
po czym ponownie przepisujemy ramke do C(n:f), i w odpowiednia
Sn(f) wpisujemy p.

To wszystko robi sprzet wbudowany w procesor, a moze wrecz zewnetrzny
kontroler, tylko w procesorze szybciej.

>Czyżby kompilator najpierw wykonywał wszelakia możliwe obliczenia,
>a następnie odpowiednio to kompilował? David Copperfield?

No, to sie raczej nowym procesorom przypisuje.
Predykcja adresow itp.


>> Że to wszystko wymaga czasu - no cóż, "taką mamy pamięć". Dlatego szybkie
>> procesory mają po kilka poziomów pamięci cache o różnych szybkościach,
>> dlatego rozdziela się cache programu i danych. Temu też służą algorytmy
>> przewidywania skoków i cała masa innej magii zaimplementowanej w nowoczesnym
>> procesorze.
>>
> Ano właśnie ta magia.. Na czym owa predykcja polega?
> Może się mylę, ale coś mi tu pachnie marketingowym bełkotem.

No, potrafi byc np taka ze jak jest skok warunkowy w tyl, to zaklada
sie ze on bedzie, i wstepnie odczytuje rozkaz spod adresu skoku. Bo to
jakas petla w programie jest, a petla jest po to aby sie petlic :-)

>> Na szybkość działania programu bardzo duży wpływ ma też to jak zaplanujesz
>> dostępy do pamięci. Numerycy bardzo nie lubią operować na tablicach
>> wielowymiarowych, bo to potrafi dodać sporo niepotrzebnych przeładowań
>> stron.
> Hah!! Właśnie ja tak robię. Dzięki paru GB pamięci, DSP mogę robić na
> najpodlejszym laptopie w czasie rzeczywistym.

Jak trzeba to trzeba i tego nie unikniesz. Zlosliwe jest tu raczej
mnozenie, potrzebne do obliczenia adresu, plus np to ze robisz funkcje
biblioteczna, ktora nie zna rozmiaru, wiec kompilator nie moze
zoptymalizowac, a czesto nawet nie umozliwia .

Patrzac na opis powyzej, to cache nie lubi:
a) obszarow polozonych pod "okraglymi" adresami, bo jak sie okaze ze
np jedna tablica jest pod 1A0000, druga pod 1B0000 a trzecia pod 1D000
i chcemy dodac z pierwszej i drugiej i zapisac w trzeciej, to za
wszystkie maja te sama czesc adresu f i koliduja w cache. Lepiej zdac
sie na dynamiczny przydzial pamieci, moze lepiej rozrzuci.

b) skakania po adresach co kilkanascie bajtow - my tu cachujemy cala
ramke, a program uzywa z niej 1 bajt i przeskakuje do nastepnej.

J.