NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Wielordzeniowe procesory a programowanie wielowątkowe: jak unikać konfliktów pamięci?
Goto page Previous 1, 2, 3, 4 Next
bartekltg
Guest
Guest
Sun Oct 05, 2014 1:21 pm
On 05.10.2014 15:01, stchebel@gmail.com wrote:
Quote:
W dniu niedziela, 5 października 2014 14:30:25 UTC+2 użytkownik
bartekltg napisał: [ciach]
Wyciachałem, coby poprzez zmniejszoną ilość tekstu dalsza dyskusja
była bardziej czytelna. Zarówno dla mnie, dla Ciebie i
Zainteresowanych wątkiem. Szczególy są do odczytania w poprzednich
wpisach.
bartekltg napisał: [ciach]
Wyciachałem, coby poprzez zmniejszoną ilość tekstu dalsza dyskusja
była bardziej czytelna. Zarówno dla mnie, dla Ciebie i
Zainteresowanych wątkiem. Szczególy są do odczytania w poprzednich
wpisach.
Wycinanie wycinanienm, wazne, czy przeczytałeś.
Quote:
1) Dzięki za podany przykład w języku krzaczastym
Język językiem. Przeanalizowałeś?
Quote:
2) Napisałeś jak to napisać, aby działało zgodnie z oczekiwaniem
programisty. Chyba mnie nie zrozumiałeś. To nie chodzi o to że
a^2+b^2=c^2, tylko DLACZEGO a^2+b^2=c^2 !! Chodzi o to magiczne
słowo "dlaczego?".
programisty. Chyba mnie nie zrozumiałeś. To nie chodzi o to że
a^2+b^2=c^2, tylko DLACZEGO a^2+b^2=c^2 !! Chodzi o to magiczne
słowo "dlaczego?".
Dlaczego co? W zapędach wycinania wyciąłeś pytanie.
pzdr
bartekltg
J.F.
Guest
Guest
Sun Oct 05, 2014 1:45 pm
Dnia Sun, 5 Oct 2014 04:16:25 -0700 (PDT), stchebel@gmail.com
Quote:
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
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.
Quote:
kurdelebelans, nie da się z jednej kostki odczytać w tym samym
czasie danych z 2-ch różnych adresów!! No bo niby jak ?
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.
Quote:
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?
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.
Quote:
Czyżby kompilator najpierw wykonywał wszelakia możliwe obliczenia,
a następnie odpowiednio to kompilował? David Copperfield?
a następnie odpowiednio to kompilował? David Copperfield?
No, to sie raczej nowym procesorom przypisuje.
Predykcja adresow itp.
Quote:
Ż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.
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 :-)
Quote:
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.
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.
A.L.
Guest
Guest
Sun Oct 05, 2014 2:30 pm
On Sun, 5 Oct 2014 06:52:32 -0700 (PDT), stchebel@gmail.com wrote:
Quote:
W dniu niedziela, 5 października 2014 15:21:41 UTC+2 użytkownik bartekltg napisał:
2) Napisałeś jak to napisać, aby działało zgodnie z oczekiwaniem
programisty. Chyba mnie nie zrozumiałeś. To nie chodzi o to że
a^2+b^2=c^2, tylko DLACZEGO a^2+b^2=c^2 !! Chodzi o to magiczne
słowo "dlaczego?".
Dlaczego co? W zapędach wycinania wyciąłeś pytanie.
W zapędach wycinania wyciąłem chyba pytanie "jak to działa?" , a nie "dlaczego?". Być może, ale nie chce mi się przeglądać dyskusji od początku.W ogóle chyba (?) stricte takiego pytania nie zadałem. Nie neguję sensu implementowania w prockach pamięci cache, nie neguję sensu produkowania procków wielordzeniowych/programowania wielowątkowego, ale po prostu pytam jak jest to zrealizowane. W notach aplikacyjnych HW/SW jest napisane jak to obsługiwać, ale jak jest to zrobione to ni cholery. Pytanie ot, z czystej ciekawości. Ale są pewne wątpliwości o których wcześniej napisałem. Czy aby w pewnych szczególnych przypadkach częstych i dłuuugich skoków ten mechanizm jest porządany? Sądzę, że w takich przypadkach może być wręcz szkodliwy.
2) Napisałeś jak to napisać, aby działało zgodnie z oczekiwaniem
programisty. Chyba mnie nie zrozumiałeś. To nie chodzi o to że
a^2+b^2=c^2, tylko DLACZEGO a^2+b^2=c^2 !! Chodzi o to magiczne
słowo "dlaczego?".
Dlaczego co? W zapędach wycinania wyciąłeś pytanie.
W zapędach wycinania wyciąłem chyba pytanie "jak to działa?" , a nie "dlaczego?". Być może, ale nie chce mi się przeglądać dyskusji od początku.W ogóle chyba (?) stricte takiego pytania nie zadałem. Nie neguję sensu implementowania w prockach pamięci cache, nie neguję sensu produkowania procków wielordzeniowych/programowania wielowątkowego, ale po prostu pytam jak jest to zrealizowane. W notach aplikacyjnych HW/SW jest napisane jak to obsługiwać, ale jak jest to zrobione to ni cholery. Pytanie ot, z czystej ciekawości. Ale są pewne wątpliwości o których wcześniej napisałem. Czy aby w pewnych szczególnych przypadkach częstych i dłuuugich skoków ten mechanizm jest porządany? Sądzę, że w takich przypadkach może być wręcz szkodliwy.
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.
Ciezko widze programowanie wieloprocesorow jak ktos nie umie wyslac
posat na usenet
A.L.
A.L.
Guest
Guest
Sun Oct 05, 2014 2:45 pm
On Sun, 5 Oct 2014 01:47:21 -0700 (PDT), stchebel@gmail.com wrote:
Quote:
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), stchebel@gmail.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?
On Sat, 4 Oct 2014 15:25:04 -0700 (PDT), stchebel@gmail.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.
Guest
Sun Oct 05, 2014 3:01 pm
W dniu niedziela, 5 października 2014 14:30:25 UTC+2 użytkownik bartekltg napisał:
[ciach]
Wyciachałem, coby poprzez zmniejszoną ilość tekstu dalsza dyskusja była bardziej czytelna. Zarówno dla mnie, dla Ciebie i Zainteresowanych wątkiem. Szczególy są do odczytania w poprzednich wpisach.
1) Dzięki za podany przykład w języku krzaczastym (C, znasz moje zdanie w tym temacie, ale proszę nie "uruchamiajmy" się w dyskusję Pascal/C, bo będzie awantura/pyskówa).
2) Napisałeś jak to napisać, aby działało zgodnie z oczekiwaniem programisty. Chyba mnie nie zrozumiałeś. To nie chodzi o to że a^2+b^2=c^2, tylko DLACZEGO a^2+b^2=c^2 !! Chodzi o to magiczne słowo "dlaczego?".
Wiem, że nie wiem jak w szczegółach działa mechanizm multicore/multithreade.
Odnoszę wrażenie, że umiesz ten mechanizm wykorzystywać, ale jak to funguje to chyba podobnie jak i ja za bardzo nie wiesz. Ot jak moja Kobita.. Autem jeździ, ale zasady działania silnika nie zna.
Guest
Sun Oct 05, 2014 3:52 pm
W dniu niedziela, 5 października 2014 15:21:41 UTC+2 użytkownik bartekltg napisał:
Quote:
2) Napisałeś jak to napisać, aby działało zgodnie z oczekiwaniem
programisty. Chyba mnie nie zrozumiałeś. To nie chodzi o to że
a^2+b^2=c^2, tylko DLACZEGO a^2+b^2=c^2 !! Chodzi o to magiczne
słowo "dlaczego?".
Dlaczego co? W zapędach wycinania wyciąłeś pytanie.
W zapędach wycinania wyciąłem chyba pytanie "jak to działa?" , a nie "dlaczego?". Być może, ale nie chce mi się przeglądać dyskusji od początku.W ogóle chyba (?) stricte takiego pytania nie zadałem. Nie neguję sensu implementowania w prockach pamięci cache, nie neguję sensu produkowania procków wielordzeniowych/programowania wielowątkowego, ale po prostu pytam jak jest to zrealizowane. W notach aplikacyjnych HW/SW jest napisane jak to obsługiwać, ale jak jest to zrobione to ni cholery. Pytanie ot, z czystej ciekawości. Ale są pewne wątpliwości o których wcześniej napisałem. Czy aby w pewnych szczególnych przypadkach częstych i dłuuugich skoków ten mechanizm jest porządany? Sądzę, że w takich przypadkach może być wręcz szkodliwy.
A.L.
Guest
Guest
Sun Oct 05, 2014 4:19 pm
On Sun, 5 Oct 2014 08:12:07 -0700 (PDT), stchebel@gmail.com wrote:
Quote:
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?
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
Quote:
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.
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.
Guest
Sun Oct 05, 2014 5:12 pm
W dniu niedziela, 5 października 2014 16:30:21 UTC+2 użytkownik A. L. napisał:
Quote:
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.
Quote:
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.
Jacek Radzikowski
Guest
Guest
Sun Oct 05, 2014 5:50 pm
stchebel@gmail.com wrote:
Quote:
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.
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.
Quote:
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?
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ć.
Quote:
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.
-
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.
[...]
Quote:
Ż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.
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.
Quote:
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.
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 :)
Quote:
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ę.
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
Quote:
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ę !!
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.
Quote:
Cholera, na grupie elektronicznej w zasadzie zjechaliśmy na matematykę.
Ale cóż, nowoczesna elektronika bez matematyki/algorytmiki nie może
funkcjonować.
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.
A.L.
Guest
Guest
Sun Oct 05, 2014 6:29 pm
On Sun, 5 Oct 2014 09:57:53 -0700 (PDT), stchebel@gmail.com wrote:
Quote:
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.
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.
Guest
Sun Oct 05, 2014 6:57 pm
W dniu niedziela, 5 października 2014 18:19:18 UTC+2 użytkownik A. L. napisał:
Quote:
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.
Marek Borowski
Guest
Guest
Sun Oct 05, 2014 7:23 pm
On 2014-10-05 19:50, Jacek Radzikowski wrote:
Quote:
stchebel@gmail.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.
.
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.
.Quote:
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.
cyklu zegara. Dzieje się tak dlatego, że tablica translacji jest
zaimplementowana jako pamięć asocjacyjna - taka sprzętowa baza danych
j.w. przewaznie zbiorowo asocjacyjna.
Quote:
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
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.
Quote:
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.
Quote:
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
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
.
Quote:
tuż obok rdzenia procesora.
Mozna by odniesc wrazenie ze piszesz ogolnie o sprzecie. Nie jest tak
Mozna by odniesc wrazenie ze piszesz ogolnie o sprzecie. Nie jest tak
dobrze, chociazby bariery pamieci nas w programie nie omina.
Pozdrawiam
Marek
bartekltg
Guest
Guest
Sun Oct 05, 2014 8:38 pm
On 05.10.2014 21:23, Marek Borowski wrote:
Quote:
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
Guest
Sun Oct 05, 2014 9:14 pm
W dniu niedziela, 5 października 2014 19:50:19 UTC+2 użytkownik Jacek Radzikowski napisał:
Quote:
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).
J.F.
Guest
Guest
Sun Oct 05, 2014 9:25 pm
Dnia Sun, 05 Oct 2014 22:38:43 +0200, bartekltg napisał(a):
Quote:
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?
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?
Jakos musieli zrobic, aby dzialalo.
Widac te miliardy tranzystorow sa tam nie bez powodu :-)
J.
elektroda NewsGroups Forum Index - Elektronika Polska - Wielordzeniowe procesory a programowanie wielowątkowe: jak unikać konfliktów pamięci?