On Sun, 5 Oct 2014 01:47:21 -0700 (PDT), s...@g...com wrote:

>W dniu niedziela, 5 października 2014 00:41:48 UTC+2 użytkownik A. L. napisał:
>> On Sat, 4 Oct 2014 15:25:04 -0700 (PDT), s...@g...com wrote:
>>
>
>>
>> A o czyms takim jak "cache memory" slyszales? Poczytaj sobie cos o
>>
>> architekturze procesora wielordzeniowego
>>
>
>Pamięć cache to też taka "kostka" tyle że zaszyta w kostce procka. No i co w
sytuacji, gdy 2 procesory odwołują się jednocześnie do dwóch różnych adresów w
obrębie tej pamięci?

L1 cache (a w niektorych procesorach i L2 cache) sa wlasnoscia "core"
czyli rdzenia. Tylko jeden moze odwolac sie do tej pamieci

A.L.

do góry

W dniu niedziela, 5 października 2014 16:30:21 UTC+2 użytkownik A. L. napisał:

>
>
>
> Z che3cia bym wzial udzial w dyskusji, ale wezme dopiero wtedy gdy
>
> nauczysz sie wtsylac posty tak aby nie byly one jedna linia dluga na
>
> kilometr.
>
>

No nieee... Byle burok "skapnąłby się", że korzystam z google.groups .
Na wygląd postów w Twojej odczytywarce nie mam żadnego wpływu. Może mi powiesz żem
Burok bo z GG korzystam? G Ci do tego, nie chcesz to się nie odzywaj. A tak w
temacie.. Masz coś do powiedzenia w temacie, czy ino czekasz na krótką linijkę do
krótkiej linijki, w której po krótce opiszę to co jest zawarte w głównym wątku.
>
> Ciezko widze programowanie wieloprocesorow jak ktos nie umie wyslac
>
> posat na usenet
>

Miszczu!! Dzięki za wsparcie. Nie umiałem wysłać, a jednak poszło. W końcu
odczytałeś geniuszu.

Doradź mi miszczu jeszcze coś. Pytać się o coś na grupach dyskusyjnych, czy raczej
nie? Będą tu jakieś porady, czy ino zjeby?

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

Dobrze dyskutuje się z Bartkiem, można mieć inne zdanie na "coś tam", wymiana
poglądów/argumenty, miło się gada.

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

Z Tobą A.L. się nie da. Wyżej ..asz niż ...e masz.

do góry

On Sun, 5 Oct 2014 08:12:07 -0700 (PDT), s...@g...com wrote:

>W dniu niedziela, 5 października 2014 16:30:21 UTC+2 użytkownik A. L. napisał:
>
>>
>>
>>
>> Z che3cia bym wzial udzial w dyskusji, ale wezme dopiero wtedy gdy
>>
>> nauczysz sie wtsylac posty tak aby nie byly one jedna linia dluga na
>>
>> kilometr.
>>
>>
>
>No nieee... Byle burok "skapnąłby się", że korzystam z google.groups .
>Na wygląd postów w Twojej odczytywarce nie mam żadnego wpływu. Może mi powiesz żem
Burok bo z GG korzystam?

Tak

>G Ci do tego, nie chcesz to się nie odzywaj. A tak w temacie.. Masz coś do
powiedzenia w temacie, czy ino czekasz na krótką linijkę do krótkiej linijki, w
której po krótce opiszę to co jest zawarte w głównym wątku.
>>
>> Ciezko widze programowanie wieloprocesorow jak ktos nie umie wyslac
>>
>> posat na usenet
>>
>
>Miszczu!! Dzięki za wsparcie. Nie umiałem wysłać, a jednak poszło. W końcu
odczytałeś geniuszu.
>
>Doradź mi miszczu jeszcze coś. Pytać się o coś na grupach dyskusyjnych, czy raczej
nie? Będą tu jakieś porady, czy ino zjeby?
>
>=============
>
>Dobrze dyskutuje się z Bartkiem, można mieć inne zdanie na "coś tam", wymiana
poglądów/argumenty, miło się gada.
>
>================
>
>Z Tobą A.L. się nie da. Wyżej ..asz niż ...e masz.

Idziesz do KF. Permanantnie. Z burakami nie rozmawiam.

A.L.

do góry

W dniu niedziela, 5 października 2014 18:19:18 UTC+2 użytkownik A. L. napisał:

>
>
> Idziesz do KF. Permanantnie. Z burakami nie rozmawiam.
>

Ależ proszę bardzo, jak Guru z erystyką nie daje sobie rady, to najprościej nie
słuchać adwersarza.

A odnośnie epitetów, to radzę trochę przystopować. W najlepszym przypadku możesz być
Pan postrzegany na grupie w/g użytego przez Pana określenia.

Tymczasem do zobaczenia w KF.

do góry

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

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

Dzięki temu że pamięć cache jest szybka i lokalna dla rdzenia, nie zajmuje
ani trochę czasu.
Mechanizm "klasyczny" jest dość prosty. Procesor chcąc odczytać komórkę
pamięci wystawia adres na szynę adresową. Ta nie jest podpięta bezpośrednio
do pamięci RAM, a do układu zarządzającego cache. Adres jest dzielony na
logiczne kawałki: w dużym uproszczeniu wygląda to tak, że najmłodsze bity
określają przesunięcie na stronie, a starsze numer strony. Trochę jak
intelowe offset i segment, ale sensowniej zrobione.
Numer strony jest porównywany z numerami stron ściągniętymi do cache, i
jeśli strona jest załadowana, odpowiednia wartość jest zwracana do
procesora, a jeśli nie - układ (podkreślam że to jest układ, program nic o
tym nie wie) zarządzania cache ściąga stronę z pamięci wyższego poziomu
(czyli kolejny poziom cache, albo pamięć RAM.)

Jeśli strona siedzi w cache to cała procedura nie zajmuje nawet jednego
cyklu zegara. Dzieje się tak dlatego, że tablica translacji jest
zaimplementowana jako pamięć asocjacyjna - taka sprzętowa baza danych
adresowana zawartością. Na wejście podajesz numer strony do której się
odwołujesz, na wyjściu otrzymujesz albo informację gdzie ta strona jest w
cache, albo że jej nie ma. To w którym wierszu tabeli ta informacja jest
zapisana nie ma najmniejszego 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?

W nowych procesorach może to wyglądać na sztuczki magiczne, ale magii tam
nie ma. Tablica translacji jest uaktualniana przez układ zarządzania cache
który wie dokładnie które strony są załadowane do cache i pod jakimi
adresami. Ani kompilator ani procesor nie muszą o tym wiedzieć.


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

To nie kompilator. Ten mechanizm jest wbudowany w krzem.
Najprostszy manager cache reaguje na to co procesor chce odczytać i ściąga w
razie potrzeby. Doktoraty są robione na "wróżeniu z fusów" które pomoże
ściągnąć stronę do cache zanim faktycznie będzie potrzebna.


[...]

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

To nie jest bełkot marketingowy, a jeden (kilka?) z doktoratów. Nie wiem jak
to działa w szczegółach, ale polega mniej-więcej na tym że jak układ
sterujący wykonaniem rozkazów widzi w kolejce instrukcję skoku to będzie się
starał przewidzieć która strona pamięci będzie potrzebna i zleca układowi
cache żeby ją ściągnął. W ostateczności może zawsze upewniać się że dostępny
jest kod dla obydwu wariantów, ale to jest bardzo naiwne i nie-ekonomiczne
podejście.


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

Gratuluję odkrycia jednej z najprostszych optymalizacji możliwych do
zaimplementowania na etapie projektowania struktur danych :)


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

Tablica ma rozmiar A x B. Odwołujemy się do elementu (i, j). Adres elementu
w przestrzeni liniowej przy zapisywaniu danych wierszami to k = (j * A) + i


>> 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ę !!

Kompilator może tak ułożyć kod żeby podprogram wykonywany przez dłuższy czas
w całości zmieścił się w cache. O tym żeby dane były tak ułożone musisz sam
zadbać. Poczytaj sobie o cache locality (możesz zacząć tutaj:
http://stackoverflow.com/questions/12065774/why-does
-cache-locality-matter-for-array-performance)
Ani kompilator ani Ty nie musicie się przejmować panowaniem nad
stronicowaniem. To jest robota układu zarządzania cache zaszytego w krzemie
tuż obok rdzenia procesora.


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

Jak czytam wywody niektórych elektroników to chętnie bym wysłał ich na kurs
podstaw inżynierii programowania. Lekkie poszerzenie horyzontów na pewno nie
zaszkodzi :)

pzdr.
j.

do góry

On Sun, 5 Oct 2014 09:57:53 -0700 (PDT), s...@g...com wrote:

>W dniu niedziela, 5 października 2014 18:19:18 UTC+2 użytkownik A. L. napisał:
>
>>
>>
>> Idziesz do KF. Permanantnie. Z burakami nie rozmawiam.
>>
>
>Ależ proszę bardzo, jak Guru z erystyką nie daje sobie rady, to najprościej nie
słuchać adwersarza.
>
>A odnośnie epitetów, to radzę trochę przystopować. W najlepszym przypadku możesz być
Pan postrzegany na grupie w/g użytego przez Pana określenia.
>
>Tymczasem do zobaczenia w KF.

Cytuje: "Wyżej ..asz niż ...e masz." Ja tez radze przystopowac.

Do zobaczenai

A.L.

do góry

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

>
>
>
> Jak czytam wywody niektórych elektroników to chętnie bym wysłał ich na kurs
>
> podstaw inżynierii programowania. Lekkie poszerzenie horyzontów na pewno nie
>
> zaszkodzi :)
>

Po pierwsze to wielki sorry za wycięcie kupy dyskusji w której brałeś udział. Jak kto
chce, niech sobie te wpisy poczyta. W pewnej części zgadzam się z Tobą, w pewnej nie.
Ale to duperele, nie warto tutaj sobie zawracać tym głowy. A co się zaś tyczy
fragmentu Twojego wpisu, którego nie wycicachałem, no to cóż..

Jak nie wyciachałem, to wypadałoby wdać się w polemikę, a nie jak niejaki AL "idziesz
do KF", bo tak każdy dzieciak potrafi.

No to wdaję się w ową. Co było pierwsze? Jajco, czy kura? Hmmm.. Mamy drobny
problem..

Co było pierwsze: program, czy komputer ? I co jest ważniejsze? Program czy komputer?

Tak z historycznego punktu widzenia, to chyba najpierw został skonstruowany ENIAC,
następnie maszyny typu IBM360/ODRA1305, systemy operacyjne GEORGE2,
aż w końcu pojawił się geniusz A.L. , dzięki któremu wylądowałem w kiblu (KF).

do góry

On 2014-10-05 19:50, Jacek Radzikowski wrote:
> s...@g...com wrote:
>
>> W dniu niedziela, 5 października 2014 12:01:53 UTC+2 użytkownik Jacek
>> Radzikowski napisał:
>>> 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.
>>
Zawsze mi sie wydawalo ze cache trafia linia na nie cala strona. ;-).


> Jeśli strona siedzi w cache to cała procedura nie zajmuje nawet jednego
> cyklu zegara. Dzieje się tak dlatego, że tablica translacji jest
> zaimplementowana jako pamięć asocjacyjna - taka sprzętowa baza danych
j.w. przewaznie zbiorowo asocjacyjna.

>>> 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.
Jednej z lepszych algorytmow przewidywanie skokow zaimplementowany w
procesorze Citrix byl taki: skok wykonywany jest zawsze :-).
I co ciekawe nie odstepowal tragicznie od uwczesnego mu pentium intela
ktore (o ile dobrze pamietam) mialo liczniki trafien predykcji.


>
> To nie jest bełkot marketingowy, a jeden (kilka?) z doktoratów. Nie wiem jak
> to działa w szczegółach, ale polega mniej-więcej na tym że jak układ
> sterujący wykonaniem rozkazów widzi w kolejce instrukcję skoku to będzie się
> starał przewidzieć która strona pamięci będzie potrzebna i zleca układowi
> cache żeby ją ściągnął. W ostateczności może zawsze upewniać się że dostępny
> jest kod dla obydwu wariantów, ale to jest bardzo naiwne i nie-ekonomiczne
> podejście.
>
Mozna tez jak ARMie miec instrukcje ktore sa zawsze przepychane przez
pipeline ale z zaleznosci od flagi wykonywane bardz ignorowane.

> Ani kompilator ani Ty nie musicie się przejmować panowaniem nad
> stronicowaniem. To jest robota układu zarządzania cache zaszytego w krzemie
Stronicowanie ma niewiele wspolnego z cache i bez wsparcia programowego
nie dziala. Zdaje sie ze miales co innego na mysli ;-).

> tuż obok rdzenia procesora.
>
Mozna by odniesc wrazenie ze piszesz ogolnie o sprzecie. Nie jest tak
dobrze, chociazby bariery pamieci nas w programie nie omina.


Pozdrawiam

Marek

do góry

W dniu niedziela, 5 października 2014 20:29:20 UTC+2 użytkownik A. L. napisał:
> On Sun, 5 Oct 2014 09:57:53 -0700 (PDT), s...@g...com wrote:
>
>
>
> >W dniu niedziela, 5 października 2014 18:19:18 UTC+2 użytkownik A. L. napisał:
>
> >
>
> >>
>
> >>
>
> >> Idziesz do KF. Permanantnie. Z burakami nie rozmawiam.
>
> >>
>
> >
>
> >Ależ proszę bardzo, jak Guru z erystyką nie daje sobie rady, to najprościej nie
słuchać adwersarza.
>
> >
>
> >A odnośnie epitetów, to radzę trochę przystopować. W najlepszym przypadku możesz
być Pan postrzegany na grupie w/g użytego przez Pana określenia.
>
> >
>
> >Tymczasem do zobaczenia w KF.
>


Brak konsekwencji. Podobno jestem w KF. Do zobaczenia w KF? Weż wyluzuj.. Albo
dyskutuj tutaj, albo sam się zkilfajluj.

do góry

On 05.10.2014 21:23, Marek Borowski wrote:
>>>
> Zawsze mi sie wydawalo ze cache trafia linia na nie cala strona. ;-).

> Mozna by odniesc wrazenie ze piszesz ogolnie o sprzecie. Nie jest tak
> dobrze, chociazby bariery pamieci nas w programie nie omina.


W cache ląduje całą linia. A jak to jest z transportem w górę?
Mamy problemy z false sharing, ale jest on tylko wydajnościowy,
jeśli na raz będę zapisywał jednym wątkiem do tablicy w miejscach
parzystych, drugim w nieparzystych, poza wydajnością wszystko
będzie w porządku. Czyli nie pcham w górę całej linii.
Jak to jest sprzętowo?
[a do tego kołacze mi się instrukcja MOVNTQ, która wysyła
dane do pamięci 'z pominięciem cache']

pzdr
bartekltg

do góry