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