Dnia Sat, 03 Mar 2012 15:44:10 +0000, Edek Pienkowski napisal:


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

Tak miałem wrażenie, że coś kłamię: jedno zero mi zjadło. Jakieś
kilkadziesiąt razy.

Edek

do góry

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

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

nie wiem jaki jest koszt 'rozpedzenia' drugiego procesora - petla
miliona dodawan to pare milisekund - jesli z drugim procesorem
jest dwa razy wolniej to wynikaloby ze koszt rozpedzenia tego
procka to tez kilka milisekund albo wchodza w gre jakies inne
koszty

zobacz na znacznie wiekszej petli i wydziel koszty 'rozpedzenia'
procka tak by byly minimalne - taki model podejscia chyba powinien
sie stosowac - bo czemu nie? (a jak nie to czemu nie: stale koszty
uzywania dodadtkowych procowchyba nie sa duze ale koszty rozruchowe
moga byc duze dla malych zadan - tak to wyglada - zobacz czy tak jest - jesli
tak nie jest to bedzie cos nowego o czym ew warto pogadac i dowiedziec
sie co to takiego <- tak to widze








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

do góry

Użytkownik "Edek Pienkowski" <e...@g...com> napisał w
wiadomości grup dyskusyjnych:jite8a$dvn$1...@i...gazeta.pl...
> 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ą.

Nie taka mikro ;)

Nie da się - ta pętla to jedyny etap na którym coś sensownie (tj.
bezmyślnie) można zrównoleglić.

Było rzędu 1000

Dałem docelowe N, czyli 10 000, i nagle... surprise, surprise

(a nic innego nie zmieniałem!)

>gfortran -fopenmp -Ofast program.f95
>a test.in
CPU_TIME time = 35.6875 seconds
ETIME CPU time = 35.2500 seconds 98.64 %
ETIME SYS time = 0.4844 seconds 1.36 %
ETIME TOT time = 35.7344 seconds

>gfortran -Ofast program.f95
>a test.in
CPU_TIME time = 37.0000 seconds
ETIME CPU time = 36.9375 seconds 99.79 %
ETIME SYS time = 0.0781 seconds 0.21 %
ETIME TOT time = 37.0156 seconds

Czyli wersja z OpenMP zrobiła się szybsza (na dwóch rdzeniach) niż
jednowątkowa. I to nawet bez schedule (z też).

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

Wszystko da się spieprzyć.

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

Nie o to chodzi - po prostu dziwiłem się kiedyś, po co Intel dał GPU do CPU
zamiast zrobić coś innego. Tłumaczył się wtedy (inż. z Intela), że mieli
pusto na krzemie, bo obwód wafelka jest ograniczony prądowo przez I/O, więc
przy malejącej szerokości ścieżki zostały puste placki, więc wsadzili tam
coś, czyli GPU. Bardziej jednak prawdopodobne, że te GPU tam już teraz
jest... aby kiedyś używać podobnie jak to robi CUDA.

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

Też tak myślę.

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

Niezupełnie - oddychają Windowsy, piszę newsy, coś się dzieje...

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

Na serio narzekam. Powinno być tak prosto jak się da. A jest... no dobrze,
jeszcze tylko dlaczego OpenMP nie chce działać pod GCC 4.7 ?! Tzn. coś mu
się nie podoba "stara" glibc. Ok. Ale czy ja mam chęć walczyć z glibc - na
każdym systemie na jaki przypadkiem trafię?! Nie mam!

> 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ą:

Przełom jest przy około 50 tysiącach iteracji.

Nagle wszystko robi się płynne, obciążenie CPU leci do 100%, oba wątki się
dogadują - normalnie cud mniemany.

do góry

Dnia Sat, 03 Mar 2012 17:12:22 +0100, slawek napisal:

> Użytkownik "Edek Pienkowski" <e...@g...com> napisał w
> wiadomości grup dyskusyjnych:jite8a$dvn$1...@i...gazeta.pl...
>> 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ą.
>
> Nie taka mikro ;)

Chodzi mi o jedną iterację.

>
> Nie da się - ta pętla to jedyny etap na którym coś sensownie (tj.
> bezmyślnie) można zrównoleglić.
>
> Było rzędu 1000
>
> Dałem docelowe N, czyli 10 000, i nagle... surprise, surprise
>
> (a nic innego nie zmieniałem!)
[...]

To jednak udawadnia twoją tezę, że to trochę chimeryczne stworzenie.

Dla mojej ciekawości: zrobiłbyś test N=1000 (zgubiłem się już, które to
N) i zrobił pętlę tak:
for i = 0 ; i += 1000 ; i < n
for private(j) = i; j < 1000 + i && j < n; j++)

(sam bym zrobił, ale chwilowo mi się system instaluje)

>
>> 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ść
>
> Nie o to chodzi - po prostu dziwiłem się kiedyś, po co Intel dał GPU do
> CPU zamiast zrobić coś innego. Tłumaczył się wtedy (inż. z Intela), że
> mieli pusto na krzemie, bo obwód wafelka jest ograniczony prądowo przez
> I/O, więc przy malejącej szerokości ścieżki zostały puste placki, więc
> wsadzili tam coś, czyli GPU. Bardziej jednak prawdopodobne, że te GPU
> tam już teraz jest... aby kiedyś używać podobnie jak to robi CUDA.

Ciekawe story, ten ring danych to pewnie dlatego, że jej się LOTR
przyśnił? Pierścienie na wafelku?

Wiem, że iX mają GPU, ale to inne GPU niż Nvidii. Na nowych AMD,
Intelach może też, już GPU daje jakąś pomoc dla CPU w zwykłym kodzie
CPU, przynajmniej tomshardware tak twierdzi. Jak dla mnie to
chwilowo jest skomplikowane, a że "w domu" i "w pracy" mam
starszy sprzęt (pomijając może mainframe) to nie mam z tym do czynienia.

>
>> Ta, schedulera. W przypadku dwóch wątków na dwucorowym procku scheduler
>> nie ma nic do gadania.
>
> Niezupełnie - oddychają Windowsy, piszę newsy, coś się dzieje...

Ok, ruszysz myszką: przerwanie, I/O, kursor, itd. Podejrzewasz,
że jakikolwiek scheduler robi potem msleep(100)?

Jedyne o czym wiem, to Windows preferuje okienka z focusem. Chcesz
mieć szybciej działającą aplikację: zrób puste okienko. Albo zmień
ustwienia wydajności na "aplikacje w tle", serwerowe to się cyhba nazywa.

>
>> OpenMP jest fajny, RTFM. Trolujesz, czy serio narzekasz?
>
> Na serio narzekam. Powinno być tak prosto jak się da. A jest... no
> dobrze, jeszcze tylko dlaczego OpenMP nie chce działać pod GCC 4.7 ?!
> Tzn. coś mu się nie podoba "stara" glibc. Ok. Ale czy ja mam chęć
> walczyć z glibc - na każdym systemie na jaki przypadkiem trafię?! Nie
> mam!

Do pełni szczęścia dodaj -std=c++0x i miłego debugowania, ech.

>
>> 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ą:
>
> Przełom jest przy około 50 tysiącach iteracji.
>
> Nagle wszystko robi się płynne, obciążenie CPU leci do 100%, oba wątki
> się dogadują - normalnie cud mniemany.

Na Thrust możesz zerknąć i tak, samo się na GPU przeniesie.

Edek

do góry

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

> Procedura solve (napisana w Fortranie), według profilera, wykonuje się 2.43
> mikrosekundy jako "single thread". Jeżeli jednak uruchomić program jako
> wielowątkowy (2 wątki, OpenMP), to profiler pokazuje około 1.21
> mikrosekundy. Problem jednak w tym że cały program, co zmierzyłem "ręcznie"
> zwykłym stoperem, a także przez CPU_TIME z wnętrza programu, wykonuje się
> wtedy nie krócej - ale aż 20 razy dłużej!

Mialem podobne problemy gdy probowalem uzywac profilera do trudniejszego
kodu. Nie wiem co jest przyczyna problemow. Ostatecznie mierzylem czasy
tylko przy pomocy time a kod uruchamialem wielokrotnie w petli. Czasami
oczywiscie dopieszczony kawalek kodu po przeniesieniu do calego programu
zwyczajnie nie dzialal wydajnie, nie wspolpracowal z reszta. Ale co
poradzic, chyba nie ma innego sposobu gdy sie programuje w jezykach
wysokiego poziomu?
Pozdrawiam





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

do góry

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

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

Na poczatku mialem takie samo wrazenie :) Jednak prawda jest taka, ze
OpenMP wyraznie upraszcza trudne przypadki, a proste upraszcza kolosalnie.
Ale na poczatku tez wyzywalem na ten standard, wiec rozumiem kolege.
Sprobuj jeszcze kilka razy :)

Pozdrawiam


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

do góry

Użytkownik " M.M." <m...@N...gazeta.pl> napisał w wiadomości grup
dyskusyjnych:jiu2nr$14d$...@i...gazeta.pl...
> Sprobuj jeszcze kilka razy :)

Będzie jeszcze okazja - na razie jest odświeżony 1 program z serii
kilkunastu (lub więcej) - najprostszy i najszybszy (tzn. mało co w pętli).

do góry

<f...@N...gazeta.pl> napisał(a):

> > 1. OpenMP "podręcznikowo" stosuje się tak:
> >
> > !$omp parallel do
> > do i = 1,N
> > ! ... robota do wykonania
> > end do
> > !$omp end parallel do
Co Ty za podreczniki czytasz? :) To okolo 3% mozliwosci
OpenMP :)

> > tymczasem narzut na utworzenie wątków jest paskudnie duży i opłaca się
> > robić tak
Zawsze narzut na utworzenie watkow jest duzy, to nie wina OpenMP.


> > ale o tym "ludzie od OpenMP" milczą w swoich zaangażowanych
> > prezentacjach i przykładach.
Nie milcza, pelno w sieci materialow.


> > Mimo tej sztuczki - program nadal jest 2x _wolniejszy_ niż
> jednowątkowy
> > (był nawet 35 razy wolniejszy). A powinien być 2x szybszy. Dziwne.
Zrownoleglaj obliczenia ktore trwaja przynajmniej 60s na jednym
watku, wtedy pisz ze dziwne jesli spowolni :)

> > 2. OpenMP miał być (jest?! wątpię!) sposobem na łatwie-i-przyjemne
> > wprowadzenie wielowątkowości dla usprawnienia obliczeń numerycznych.
No kurde jest. Bez OpenMP taki sam efekt uzyskujesz piszac 5-20 razy
wiecej kodu. OpenMP robi to samo co bys zrobil sam bez OpenMP -
pisze za Ciebie kod. Ty tylko mowisz jaki kod ma napisac. Cos
ala paradygmat deklaratywny.


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

> > 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.
Nie spada, po prostu uzywasz tira do przewozenia jednego pudelka zapalek.

Pozdrawiam


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

do góry

On Sunday, March 4, 2012 5:46:00 AM UTC, M.M. wrote:
> Zawsze narzut na utworzenie watkow jest duzy, to nie wina OpenMP.

Jezeli tworzysz watki recznie, narzut jest znacznie mniejszy.

RW

do góry

Roman W <b...@g...pl> napisał(a):

> On Sunday, March 4, 2012 5:46:00 AM UTC, M.M. wrote:
> > Zawsze narzut na utworzenie watkow jest duzy, to nie wina OpenMP.
>
> Jezeli tworzysz watki recznie, narzut jest znacznie mniejszy.

Mozesz to jakos uzasadnic i opisac jak uzywasz slowa "recznie"?
Pozdrawiam


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

do góry