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.