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/