.. i do tego programowanie wielowątkowe. Ja tu czegoś nie rozumiem.
Weźmy na przykład program do obliczenia sumy liczb od 1 do N. Ot, zwykły ciąg
arytmetyczny S(N)=N*(N+1)/2. Zakładając, że wzoru nie znamy, zlecamy to kompowi. Soft
jest banalny:

s:=0;
for i:=0 to N do
begin
s:=s+1;
end;

Powyższe jest nasmarowane w Pascalu, którego składnia jest podobna do C, ino jest to
bardziej czytelne. Nie w tym rzecz.. Rozbijmy to na 2 wątki:

1)
s1:=0;
for i:=0 to k do
...........
..........
2) s2:=0;
for i:=k+1 do
.............
..............

Wiasomo o co biega,no i na koniec s:=s1+s2. Czyli wykonujemy jak gdyby 2 programy na
2-ch różnych kompach, kompilator ładnie nam to rozdzielił i klawo jak cholera. No to
teraz skomplikujmy zagadnienie ciuta bardziej.. Chcemy policzyć sumę wyrazów
jakiegoś ciągu, którego wyrazy są zapisane w wektorze A[i] (i=0..N). Robimy zaś 2
wątki:

1)
s1:=0;
for i:=0 to k do
begin
s1:=s1+A[i];
end;

2) s2:=0;
for i:=k+1 to N do
begin
s2:=s2+A[i];
end;

s:=s1+s2. A co jeżeli elementy ciągu A[m] i A[n] są zapisane fizycznie w tej samej
kostce pamięci? Co w takiej sytuacji dają mi 2 rdzenie?

do góry

On Sat, 4 Oct 2014 15:25:04 -0700 (PDT), s...@g...com wrote:

>.. i do tego programowanie wielowątkowe. Ja tu czegoś nie rozumiem.
>Weźmy na przykład program do obliczenia sumy liczb od 1 do N. Ot, zwykły ciąg
arytmetyczny S(N)=N*(N+1)/2. Zakładając, że wzoru nie znamy, zlecamy to kompowi. Soft
jest banalny:
>
>s:=0;
> for i:=0 to N do
> begin
> s:=s+1;
> end;
>
>Powyższe jest nasmarowane w Pascalu, którego składnia jest podobna do C, ino jest to
bardziej czytelne. Nie w tym rzecz.. Rozbijmy to na 2 wątki:
>
>1)
> s1:=0;
> for i:=0 to k do
> ...........
>..........
>2) s2:=0;
> for i:=k+1 do
> .............
>..............
>
>Wiasomo o co biega,no i na koniec s:=s1+s2. Czyli wykonujemy jak gdyby 2 programy na
2-ch różnych kompach, kompilator ładnie nam to rozdzielił i klawo jak cholera. No to
teraz skomplikujmy zagadnienie ciuta bardziej.. Chcemy policzyć sumę wyrazów
jakiegoś ciągu, którego wyrazy są zapisane w wektorze A[i] (i=0..N). Robimy zaś 2
wątki:
>
>1)
>s1:=0;
> for i:=0 to k do
> begin
> s1:=s1+A[i];
> end;
>
>2) s2:=0;
> for i:=k+1 to N do
> begin
> s2:=s2+A[i];
> end;
>
>s:=s1+s2. A co jeżeli elementy ciągu A[m] i A[n] są zapisane fizycznie w tej samej
kostce pamięci? Co w takiej sytuacji dają mi 2 rdzenie?
>

A o czyms takim jak "cache memory" slyszales? Poczytaj sobie cos o
architekturze procesora wielordzeniowego

A.L.

do góry

s...@g...com wrote:
> .. i do tego programowanie wielowątkowe. Ja tu czegoś nie rozumiem.
> Weźmy na przykład program do obliczenia sumy liczb od 1 do N. Ot, zwykły
> ciąg arytmetyczny S(N)=N*(N+1)/2. Zakładając, że wzoru nie znamy, zlecamy
[...]
> s:=s1+s2. A co jeżeli elementy ciągu A[m] i A[n] są zapisane fizycznie w
> tej samej kostce pamięci? Co w takiej sytuacji dają mi 2 rdzenie?

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

Ale załóżmy że tech cache nie ma i przy każdym odczycie procesor będzie
musiał sięgnąć do pamięci zewnętrznej.
Jeśli cały program by się składał wyłącznie z odczytów z pamięci, wtedy
byłby problem, bo rdzenie by sobie przeszkadzały nawzajem. Ale nawet przy
tak prostym programie jak przytoczyłeś, odczyt z pamięci jest jedną z kilku-
kilkunastu instrukcji które muszą zostać wykonane podczas jednego obiegu
pętli. Podczas kiedy jeden rdzeń zajmuje się wykonaniem dodawania,
przepisywaniem pomiędzy rejestrami sprawdzaniem warunku końca czy czy
skokiem do początku pętli, szyna pamięci danych leży odłogiem i może być
wykorzystana przez drugi rdzeń do pobrania danych.

Nawet jeśli założymy najbardziej niekorzystny przypadek, że podczas każdego
obiegu pętli obydwa rdzenie będą chciały czytać w tym samym momencie, i tak
spowolnienie będzie ledwie zauważalne. W większości przypadków każdy rdzeni
nawet nie zauważy że dostęp do pamięci jest dzielony z kimś innym.

pzdr.
j.

do góry

W dniu 2014-10-05 00:25, s...@g...com pisze:
> Powyższe jest nasmarowane w Pascalu, którego składnia jest podobna do C, ino jest
to bardziej czytelne.
:))))))
he he nie mogłeś się opanować? :)

do góry

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?

do góry

W dniu niedziela, 5 października 2014 10:44:49 UTC+2 użytkownik Jawi napisał:
> W dniu 2014-10-05 00:25, s...@g...com pisze:
>
> > Powy�sze jest nasmarowane w Pascalu, kt�rego sk�adnia jest podobna do C,
ino jest to bardziej czytelne.
>
> :))))))
>
> he he nie mog�e� si� opanowa�? :)

Ano nie :)) Widzę że znasz moją "miłość" do C z innych grup, ale akurat w tym wątku
nie o to chodzi.

do góry

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?

do góry

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.

pzdr,
j.

do góry

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

do góry

W dniu 2014-10-05 11:20, s...@g...com pisze:
>>
>> 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...
>

ale chodzi, ze ma być po polsku czy że na grupie? bo tu:
http://en.wikibooks.org/wiki/Microprocessor_Design/C
ache#Memory_Stall_Cycles
jest wszystko ładnie rozkminione..

@

do góry