Użytkownik <f...@N...gazeta.pl> napisał w wiadomości grup
dyskusyjnych:jisdma$441$...@i...gazeta.pl...
> mz wiadomo a przynajmniej bezpieczniej jest zakladac ze koszt
> owatkowienia moze byc spory, mi nie podoba sie watkowa rozrzutnosc,

Właśnie w tym cały wic:

1. OpenMP "podręcznikowo" stosuje się tak:

!$omp parallel do
do i = 1,N
! ... robota do wykonania
end do
!$omp end parallel do

tymczasem narzut na utworzenie wątków jest paskudnie duży i opłaca się
robić tak

!$omp parallel

!$omp master
! ... część jednowątkowa
!$omp end master

!$omp do
do i = 1,N
/* robota do wykonania */
end do
!$omp end do

...
!$omp parallel

ale o tym "ludzie od OpenMP" milczą w swoich zaangażowanych
prezentacjach i przykładach.

Mimo tej sztuczki - program nadal jest 2x _wolniejszy_ niż jednowątkowy
(był nawet 35 razy wolniejszy). A powinien być 2x szybszy. Dziwne.

2. OpenMP miał być (jest?! wątpię!) sposobem na łatwie-i-przyjemne
wprowadzenie wielowątkowości dla usprawnienia obliczeń numerycznych.

> - byc moze tak naprawde systemy mozna by robic zupelnie inaczej
> trzebaby kiedys przemyslec podstawy wielowątkowosci

3. Myślę, że takie coś będzie szło od strony GPU - Intel "wsadził" GPU do
CPU - więc pewnie da się - tam powinno być około 1000 rdzeni... to zupełnie
nowy horyzont.

> - tak naprawde zeby zobaczyc co sie dzieje trzebeby zobaczyc
> i umiec zrozumiec kod schedulera i okolic w kernelu - warto
> by to bylo po prostu obejrzec (zob watek jadro jadra)

4. Znowu przypomnę - OpenMP miał być sposobem na
"łatwo-prosto-i-przyjemnie". Jak mam wgłębiać się w kod kernela - to trudno
mówić, że jest prosto.

5. Czyli podsumowując - cały ten OpenMP jest mocno do niczego - wydajność
SPADA - a w dodatku trzeba mocno uważać, aby zrobić działający program.

6. Punkt 5. odnosi się do "przeciętnego PC mającego 1 procesor z niewieloma
rdzeniami". Być może gdyby tych rdzeni było więcej... ale, ale, na 16 też
było kiepsko.

do góry

On Saturday, March 3, 2012 10:13:08 AM UTC, slawek wrote:
> Właśnie w tym cały wic:
>
> 1. OpenMP "podręcznikowo" stosuje się tak:
>
> !$omp parallel do
> do i = 1,N
> ! ... robota do wykonania
> end do
> !$omp end parallel do
>
> tymczasem narzut na utworzenie wątków jest paskudnie duży i opłaca się

To, skoro masz do zrownoleglenia prosta petle, olej Open MP i tworz watki samemu? W
C++ moglbys uzyc np. boost::threads. Latwe w uzyciu i tanie.

RW

do góry

slawek <s...@h...pl> napisał(a):

>
> Użytkownik <f...@N...gazeta.pl> napisał w wiadomości grup
> dyskusyjnych:jisdma$441$...@i...gazeta.pl...
> > mz wiadomo a przynajmniej bezpieczniej jest zakladac ze koszt
> > owatkowienia moze byc spory, mi nie podoba sie watkowa rozrzutnosc,
>
> Właśnie w tym cały wic:
>
> 1. OpenMP "podręcznikowo" stosuje się tak:
>
> !$omp parallel do
> do i = 1,N
> ! ... robota do wykonania
> end do
> !$omp end parallel do
>
> tymczasem narzut na utworzenie wątków jest paskudnie duży i opłaca się
> robić tak
>
> !$omp parallel
>
> !$omp master
> ! ... część jednowątkowa
> !$omp end master
>
> !$omp do
> do i = 1,N
> /* robota do wykonania */
> end do
> !$omp end do
>
> ...
> !$omp parallel
>
> ale o tym "ludzie od OpenMP" milczą w swoich zaangażowanych
> prezentacjach i przykładach.
>
> Mimo tej sztuczki - program nadal jest 2x _wolniejszy_ niż
jednowątkowy
> (był nawet 35 razy wolniejszy). A powinien być 2x szybszy. Dziwne.
>
> 2. OpenMP miał być (jest?! wątpię!) sposobem na łatwie-i-przyjemne
> wprowadzenie wielowątkowości dla usprawnienia obliczeń numerycznych.
>
> > - byc moze tak naprawde systemy mozna by robic zupelnie inaczej
> > trzebaby kiedys przemyslec podstawy wielowątkowosci
>
> 3. Myślę, że takie coś będzie szło od strony GPU - Intel "wsadził" GPU do
> CPU - więc pewnie da się - tam powinno być około 1000 rdzeni... to zupełnie
> nowy horyzont.
>
> > - tak naprawde zeby zobaczyc co sie dzieje trzebeby zobaczyc
> > i umiec zrozumiec kod schedulera i okolic w kernelu - warto
> > by to bylo po prostu obejrzec (zob watek jadro jadra)
>
> 4. Znowu przypomnę - OpenMP miał być sposobem na
> "łatwo-prosto-i-przyjemnie". Jak mam wgłębiać się w kod kernela - to trudno
> mówić, że jest prosto.
>
> 5. Czyli podsumowując - cały ten OpenMP jest mocno do niczego - wydajność
> SPADA - a w dodatku trzeba mocno uważać, aby zrobić działający program.
>
> 6. Punkt 5. odnosi się do "przeciętnego PC mającego 1 procesor z niewieloma
> rdzeniami". Być może gdyby tych rdzeni było więcej... ale, ale, na 16 też
> było kiepsko.
>


ogolnie sie zgadzam - tak to jest, (moze tak byc,
zasadniczo jednak kombinujac powinno sie dac osiagnac
pod 200% na dwu prockach pod 400% na czterech pod 800% na
osmiu 1600% na 16stu itp -

o ile sie faktycznie NIE DA to cos jest zepsute - ale
nie wiem czy owo openmp gwarantuje ze przy jego pomocy
da sie to osiagnac dla wszystkich kodów (?) czy tylko dla
niektorych

- jesli nnie da sie tego 1600% osiagnac w openmp to powinno
dac innymi sposobami zwiazanymi z mt, a jesli nie da sie
tego siagnac i innymi sposobami to te techniki są z kolei
zepsute bo powinny to umozliwiac - prosta sprawa





--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Użytkownik "Roman W" <b...@g...pl> napisał w wiadomości grup
dyskusyjnych:17879294.84.1330773260414.JavaMail.geo-
discussion-forums@vbbfy7...
> On Saturday, March 3, 2012 10:13:08 AM UTC, slawek wrote:
>> Właśnie w tym cały wic:
>>
>> 1. OpenMP "podręcznikowo" stosuje się tak:
>>
>> !$omp parallel do
>> do i = 1,N
>> ! ... robota do wykonania
>> end do
>> !$omp end parallel do
>>
>> tymczasem narzut na utworzenie wątków jest paskudnie duży i opłaca się
>
> To, skoro masz do zrownoleglenia prosta petle, olej Open MP i tworz watki
> samemu? W C++ moglbys uzyc np. boost::threads. Latwe w uzyciu i tanie.

Więc właśnie dojrzałem do olania.

Mam dużo rachowania na liczbach zespolonych, ma to działać pod
Uniksem/Linuksem/? (co tam gdzie się znajdzie), ma to w miarę możliwości
używać wielu CPU (tzn. 2048 rdzeni na ten przykład), ma być
łatwe-proste-przyjemne (jeden plik źródłowy), z bibliotek to niech używa
lapack/blas/itp. a i to może lepiej nie, bo i po co?

Wybór padł na Fortran, bo dość łatwo go znaleźć na mainframesach (zwykle są
ze 3-4 kompilatory do wyboru). Oczywiście (?) nie Fortran 77, bo nie chce mi
się liczyć do 73. A po lekturze książki Krzyżanowskiego "Obliczenia
inżynierskie i naukowe. Skuteczne, szybkie, efektowne", Wydawnictwo Naukowe
PWN, 2011, http://www.mimuw.edu.pl/~przykry/ przyszło mi do głowy, że jak
już jest gotowy (tzn. działa, ale sam problem który jest nim rozwiązywany
"ewoluuje", np. udało mi się rozwiązać niezły jego kawałek analitycznie, co
stwarza zupełnie nowe możliwości) program, to dodanie współbieżności a'la
OpenMP jest trywialne i - co najważniejsze - da się zrobić standardowo w
Fortranie. Bez niszczenia tego, co jest.

I niestety, wydaje się że cała koncepcja OpenMP jest w tej chwili po prostu
błędna. Podobne do moich problemy są dość często spotykane - program z
OpenMP działa wolniej niż bez. A skoro działa wolniej - to nie ma
najmniejszego sensu używać. Bo i po co używać czegoś, co wymaga dodatkowej
roboty i od programisty, i od komputera - a nic w zamian nie daje?!

I jeszcze jedno - OpenMP z GCC 4.6 obciąża rdzenie 20% do 30%. OpenMP jakie
daje Microsoft (w MS Visual Studio Professional 2010) jest znacznie
wydajniejsze: obciążenie idzie do 100% na każdym rdzeniu. Ale i tak program
z OpenMP osiągnął wydajność... 50% wydajności programu bez OpenMP. I
dlatego - jeżeli nie będzie postępu - OpenMP jest chybione.

To już wolę PBS i uruchomić endziesiąt instancji mojego programu - każda z
innym zestawem danych. Też jest równolegle, a nawet prościej - nie trzeba
nic w programie zmieniać.

A jak będę się nudził, to raczej spróbować na GPU/CUDA niż drążyć OpenMP.
Zwłaszcza iż OpenMP nie wiadomo jak obsługuje I/O i takie tam.

do góry

Użytkownik <f...@N...gazeta.pl> napisał w wiadomości grup
dyskusyjnych:jit2t8$q3u$...@i...gazeta.pl...
> - jesli nnie da sie tego 1600% osiagnac w openmp to powinno
> dac innymi sposobami zwiazanymi z mt, a jesli nie da sie
> tego siagnac i innymi sposobami to te techniki są z kolei
> zepsute bo powinny to umozliwiac - prosta sprawa

PBS - działa i działało.

do góry

to ze tylko czasem program przepisany na dwa rdzenie
bedzie 2razy szybszy a czasem jest nawet wolniejszy
to dobrze wiadoma sprawa - jak dobrze go jednak napisac
to powinien byc prawie 2razy szybszy

w sumie pytanie czy nie moglbybyc wiecej niz 2 razy
szybszy? pewnym problemem jest np to ze procesor2
musi czasem wykonac dokladnie ta sama robotę co
procesor1 - gdyby dac jednemu mozliwosc kopiowania
wynikow do rugiego to drugi nie musialby tego liczyc i
teoretycznie moglby robic cos innego (mglisty pomysl
ale byc moze sa zasady z ktorych wynika ze jednak
komputer 2procesorowy moze byc wiecej niz 2 razy szybszy)

co do fortrana to czy program kompilowany fortranem jest
porownywalny z szybkoscia do c? c ma pewną szkole
optymalizacji zrodel a czy fortran ma cos takiego?










--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Użytkownik <f...@N...gazeta.pl> napisał w wiadomości grup
dyskusyjnych:jit5c1$38v$...@i...gazeta.pl...
> to ze tylko czasem program przepisany na dwa rdzenie
> bedzie 2razy szybszy a czasem jest nawet wolniejszy
> to dobrze wiadoma sprawa - jak dobrze go jednak napisac
> to powinien byc prawie 2razy szybszy

Oczywista oczywistość. Ale! Spodziewałem się, że takie coś jak rozdzielenie
pętli

for i := 1 to 1000000 do b[i] = a[i] + 1.0;

to *nie* *jest*
BARDZO-TRUDNE-WYZWANIE-DLA-WYSPECJALIZOWANEGO-STANDA
RDU(tm) ble ble ble

Przecież - co widać - operacja jest "wektorowa" - nie ma mieszania w rodzaju
b[i] = b[i-1] + a[i] itd. itp.

> co do fortrana to czy program kompilowany fortranem jest
> porownywalny z szybkoscia do c? c ma pewną szkole
> optymalizacji zrodel a czy fortran ma cos takiego?

Fortran pod względem optymalizacji jest niedościgniony (chyba).

A tak naprawdę - to i tak jedno i to samo GCC - bo nie chce mi się sprawdzić
jak to byłoby z kompilatorem Intel'a lub Portland.

Dość, że przykładowy przykład np. z -O0 (bez optymalizacji) liczy się 5
sekund, a z optymalizacją -Ofast 0.5 sekundy.

do góry

slawek <s...@h...pl> napisał(a):

>
> Użytkownik <f...@N...gazeta.pl> napisał w wiadomości grup
> dyskusyjnych:jit5c1$38v$...@i...gazeta.pl...
> > to ze tylko czasem program przepisany na dwa rdzenie
> > bedzie 2razy szybszy a czasem jest nawet wolniejszy
> > to dobrze wiadoma sprawa - jak dobrze go jednak napisac
> > to powinien byc prawie 2razy szybszy
>
> Oczywista oczywistość. Ale! Spodziewałem się, że takie coś jak rozdzielenie
> pętli
>
> for i := 1 to 1000000 do b[i] = a[i] + 1.0;
>
> to *nie* *jest*
> BARDZO-TRUDNE-WYZWANIE-DLA-WYSPECJALIZOWANEGO-STANDA
RDU(tm) ble ble ble
>
> Przecież - co widać - operacja jest "wektorowa" - nie ma mieszania w
rodzaju
> b[i] = b[i-1] + a[i] itd. itp.
>

po prawdzie to poki co nie interesowalem sie/ nie zajmowalem
tym jak takie rzeczy sa robione - ale koszt rozkrecenia
dodatkowego watku to na pewno sporo wiecej niz wpisanie
do ip drugiego procesora adresu startu i zlapania jakiegos
przerwania na koncu roboty - o tyle czynisz blad zakladajac
ze to tak malo kosztuje - trzebaby sie naprawde zainteresowac
jak wieloprocesorowosc jest robiona na poziomie okolic asma
albo nizej - np czy pojedyncze cykle kilku procesorow sa ze soba
synchronizowane jednym zegarem czy sie rozjezdzaja
- szukam info na te tematy jakby ktos znal

co do poczytania kodu schedulera czy dispatchera z kernela
to mz warto by tez to zrobic - nie powinno to byc takjie trudne
o ile jest jakis tutorial na ten temat - tez szukam jakiegos
info/tutoriala na ten temat



> > co do fortrana to czy program kompilowany fortranem jest
> > porownywalny z szybkoscia do c? c ma pewną szkole
> > optymalizacji zrodel a czy fortran ma cos takiego?
>
> Fortran pod względem optymalizacji jest niedościgniony (chyba).
>
> A tak naprawdę - to i tak jedno i to samo GCC - bo nie chce mi się
sprawdzić
> jak to byłoby z kompilatorem Intel'a lub Portland.
>
> Dość, że przykładowy przykład np. z -O0 (bez optymalizacji) liczy się 5
> sekund, a z optymalizacją -Ofast 0.5 sekundy.
>
>


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Użytkownik <f...@N...gazeta.pl> napisał w wiadomości grup
dyskusyjnych:jitafc$hgv$...@i...gazeta.pl...
> dodatkowego watku to na pewno sporo wiecej niz wpisanie
> do ip drugiego procesora adresu startu i zlapania jakiegos
> przerwania na koncu roboty - o tyle czynisz blad zakladajac
> ze to tak malo kosztuje - trzebaby sie naprawde zainteresowac

Ale to nie tak!

Oczywiście, z pewnością są takie rzeczy, że wątki będą "ciężkie" -
współdzielenie pamięci i nie tylko, synchronizacja i nie tylko, różne tempo
pracy różnych procesorów czy nawet możliwość awarii jednego z procesorów w
trakcie pracy.

Jednak przykłady dawane przez entuzjastów OpenMP są "lekkie" - tzn. np.
rozłożona na wątki pętla, w której każdy wątek pracuje na zupełnie innym
zakresie indeksów tablic. I to jeszcze z dyrektywą #pragma omp parallel for
obejmującą takie pętle, jak np. sumowanie kolejnych wyrazów szeregu
potęgowego od 1 do N .

Jeżeli OpenMP ma dawać "łatwo-prosto-przyjemnie" wielowątkowość - to ma być
"lekkie-gdzie-trzeba".

A nie jest.

Więc nie ma sensu - bo ani do łatwych zadań, ani do trudnych się nie nadaje.

do góry

Dnia Sat, 03 Mar 2012 11:13:08 +0100, slawek napisal:

> Użytkownik <f...@N...gazeta.pl> napisał w wiadomości grup
> dyskusyjnych:jisdma$441$...@i...gazeta.pl...
>> mz wiadomo a przynajmniej bezpieczniej jest zakladac ze koszt
>> owatkowienia moze byc spory, mi nie podoba sie watkowa rozrzutnosc,
>
> Właśnie w tym cały wic:
>
> 1. OpenMP "podręcznikowo" stosuje się tak:
>
> !$omp parallel do do i = 1,N
> ! ... robota do wykonania
> end do !$omp end parallel do

OpenMP pozwala robić przede wszystkim coarse-grained, fine-grained może
i też, ale twoje pętla jest "mikro". Zrób zewnętrzną/wewnętrzną.


>
> Mimo tej sztuczki - program nadal jest 2x _wolniejszy_ niż
> jednowątkowy
> (był nawet 35 razy wolniejszy). A powinien być 2x szybszy. Dziwne.

No i będzie 2x szybszy. OpenMP nie zwalnia od myślenia. Chcesz coś
prostszego: Thrust. Ma backend openMP, ma backend CUDA, używa
się tak prosto, jak stl::transform, z Fortrana chyba też się da.
Jak przy pomocy Thrust uda ci się spieprzyć, chylę czoła ;)

>
> 3. Myślę, że takie coś będzie szło od strony GPU - Intel "wsadził" GPU
> do CPU - więc pewnie da się - tam powinno być około 1000 rdzeni... to
> zupełnie nowy horyzont.

GPU działa inaczej. Taka pętla będzie "memory-bound", za mało liczenia.
W przypadku GPU mówi się o przepustowości, i generalnie przepustowość
obliczeniowa karty jest rzędu 8-10 x większa niż przepustowość
pamięci, do tego z pamięci trzeba odczytać i jeszcze zapisać wynik.
Fakt, że GPU mają lepszą przepustowość pamięci niż procek, ale znowu:
wszystko memory-bound musi mieć odpowiednie dostępy do pamięci, albo
będzie strasznie wolne. Zobacz Thrust, oni zrobili to dobrze, sam z takim
podejściem spieprzysz koncertowo i będzie jeszcze wolniejsze.

Nie wiem, co Intel (i AMD) zrobią naprawdę mieszając CPU i GPU. Widziałem
te architektury, ale nie powiem, żebym znał ich właściwości. Nie liczyłbym
też na to, że 1000 rdzeni: rdzenie GPU są inne i nie są niezależne;
no i rdzenie Intela to nie rdzenie Nvidii czy ATI. Ale mix może być fajny.

>
>> - tak naprawde zeby zobaczyc co sie dzieje trzebeby zobaczyc i umiec
>> zrozumiec kod schedulera i okolic w kernelu - warto by to bylo po
>> prostu obejrzec (zob watek jadro jadra)

Ta, schedulera. W przypadku dwóch wątków na dwucorowym procku scheduler
nie ma nic do gadania.

>
> 4. Znowu przypomnę - OpenMP miał być sposobem na
> "łatwo-prosto-i-przyjemnie". Jak mam wgłębiać się w kod kernela - to
> trudno mówić, że jest prosto.
>
> 5. Czyli podsumowując - cały ten OpenMP jest mocno do niczego -
> wydajność SPADA - a w dodatku trzeba mocno uważać, aby zrobić działający
> program.

OpenMP jest fajny, RTFM. Trolujesz, czy serio narzekasz?

>
> 6. Punkt 5. odnosi się do "przeciętnego PC mającego 1 procesor z
> niewieloma rdzeniami". Być może gdyby tych rdzeni było więcej... ale,
> ale, na 16 też było kiepsko.

Bo spieprzyłeś. Gcc wektoryzuje pętle. Jak masz task z 1 iteracją
może mieć problem (też bym liczył na to, że sobie poradzi, ale
nie wszystkie optymalizacje zawsze działają). Zresztą:

weź Thrust. Jest zrobiony właśnie dla ludzi, którzy nie kumają co to GPU,
co to OpenMP i chcą coś szybko policzyć. Przepisanie twojej pętli to
5 minut, używa się tego bardzo prosto. Gratis będzie działało na GPU,
ale nie oczekiwałbym wielkich zysków jeżeli nie masz takiego "nowego
procka CPU/GPU, który by jeszcze wspierał CC 2.0", bo na GPU trzeba
dane dodatkowo przekopiować i przekopiować wyniki, do tego pewne latency
wykonania dochodzi (rzędu 1ms).

Edek

do góry