s...@g...com wrote:

> W dniu niedziela, 5 października 2014 11:01:21 UTC+2 użytkownik Jacek
> Radzikowski napisał:
>> s...@g...com wrote:
>>
>>
>>
>> > W dniu niedziela, 5 października 2014 01:47:28 UTC+2 użytkownik Jacek
>>
>> > Radzikowski napisał:
>>
>> >
>>
>> >> Jak już wspomniał Andrzej, w takim przypadku strona pamięci z danymi
>>
>> >>
>>
>> >> zostanie przepisana do pamięci cache i problem jednoczesnego dostępu
>> >> do
>>
>> >>
>>
>> >> zewnętrznej kostki przestanie istnieć.
>>
>> >>
>>
>> >
>>
>> > Dlaczego?! Cóż tam za magia jest zaszyta w tym cache'u, że pozwala na
>>
>> > jednoczesny dostęp do dwóch albo i więcej(ilość rdzeni/wątków) adresów
>>
>> > jednocześnie?
>>
>>
>>
>> L1 jest najczęściej do wyłącznego użytku rdzenia. A jeśli nie - to działa
>>
>> mechanizm identyczny do opisanego. Z tą drobną różnicą że pamięć cache
>> jest
>>
>> o wiele szybsza i przestoje są krótsze.
>>
>
> OK, czas dostępu do cache jest argumentem przekonywującym. Zapomnijmy na
> chwilę o wielowątkowości/wielordzeniowości. A co w przypadku jeżeli mamy
> program, którego kod znacznie objętościowo przekracza pojemność cache'a? A
> z reguły tak jest. No i teraz w wyniku działania programu przy spełnieniu
> jakiś tam warunków mamy dłuuuugie skoki do innej części kodu? Nie mam
> zamiaru się tutaj wymądrzać i deprecjonować sensu pakowania cache'a do
> procka, ale czy zawsze ten mechanizm jest porządany? No bo w przypadku
> dłuuugich skoków o ile dobrze rozumiem pamięć cache powinna być
> przeładowana na nowy obszar kodu. No a to przeładowanie, to jakby na to
> nie patrzeć zaś komunikacja z pamięcią zewnętrzną, a co za tym idzie zaś
> trzeba na to trochę czasu... Bilans zysków i strat wydaje mi się może być
> przy spełnieniu pewnych warunków wręcz niekorzystny. Tak se gdybam...

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. Tym żeby wiedzieć jaki adres w cache odpowiada adresowi w pamięci
zajmuje się tablica translacji.
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.

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.

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

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

pzdr,
j.