W dniu niedziela, 5 października 2014 12:01:53 UTC+2 użytkownik Jacek Radzikowski
napisał:



> Zarządzanie zawartością pamięci cache to bardzo skomplikowany temat, na
>
> którym zrobiono wiele doktoratów i sporo zostanie zrobionych w przyszłości.
>
> W skrócie wygląda to tak, że zawartość cache nie odwzorowuje liniowo jednego
>
> wielkiego obszaru pamięci, a wiele stosunkowo niedużych stron. Strony
>
> sąsiadujące ze sobą w cache mogą w pamięci głównej być położone daleko od
>
> siebie.

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
kurdelebelans, nie da się z jednej kostki odczytać w tym samym czasie danych z 2-ch
różnych adresów!! No bo niby jak ? Zakładam że kostka ma liniową przestrzeń adresową
A(N downto 0). Szerokość słowa danych nie ma znaczenia.

> 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? Czyżby kompilator najpierw wykonywał wszelakia możliwe
obliczenia, a następnie odpowiednio to kompilował? David Copperfield?

>
> Jeśli strona do której procesor chce się odwołać nie znajduje się w cache -
>
> wykonanie programu jest wstrzymywane i strona jest ładowana. To, którą
>
> stronę w cache zastąpić nową zawartością - to jeden z tematów na doktorat.

Bez jaj. Tego się nie da zrobić w sposób predykcyjny z poziomu kompilatora. Jeżeli
ktoś podejmie się takiego doktoratu, to równie dobrze może się chwycić za doktorat z
wróżenia z fusów.

>
>
>
> Oddzielnym zagadnieniem jest synchronizacja zapisywanych danych. Nie może
>
> dojść do sytuacji że jeden procesor zapisze coś do do pamięci, ale to utknie
>
> w jego lokalnym cache i inny procesor będzie dalej czytać starą wartość. Na
>
> to poświęca się sporą część z tych milionów tranzystorów jakie są pakowane w
>
> krzem.
>

To jest oczywiste. Implikacja tego co napisałem wcześniej.

>
>
> Ż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.

>
>
> 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.

> Zamiast tego indeksy są mapowane do liniowego obszaru pamięci i jak
>
> trzeba obliczyć stan w następnym kroku symulacji - solwer jedzie po
>
> kolejnych komórkach nie troszcząc się o indeksy (oczywiście wszystkie dane
>
> wejściowe są odpowiednio przygotowane).

Upsss.. Nie za bardzo kojarzę.

>
> Zrób kiedyś eksperyment: zaalokuj wielką tablicę dwu-wymiarową i przeskanuj
>
> ją iterując najpierw po wierszach później po kolumnach, a później odwróć
>
> kolejność iteracji: najpierw po kolumnach później po wierszach. Przekonasz
>
> się o ile szybciej program będzie działać kiedy będziesz odwoływać się do
>
> pamięci bez skakania po stronach.
>

Bez jaj !! Poważnie? Kurde, zrobię taki eksperyment, ale aż wierzyć mi się nie chce.
Załóżmy że masz rację. No ale wróćmy do realu. Załóżmy że potrzebuję w koło macieju w
jakiejś tam pętli odczytywać dane pomiarowe, z tych danych jest tworzona macierz
(NxN), robimy z niej macierz odwrotną, następnie wykonujemy jakieś tam czary mary na
elementach a(i,j), potem liczymy z tego wyznacznik i cholera wie co jeszcze. No i jak
w takim burdelu mam zapanować nad stronicowaniem? Kompilator to zrobi za mnie? Nie
wierzę !!

==============

Cholera, na grupie elektronicznej w zasadzie zjechaliśmy na matematykę. Ale cóż,
nowoczesna elektronika bez matematyki/algorytmiki nie może funkcjonować.