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!

Ciekawe: gprof stwierdza, że to co się zaoszczędziło na 2-gim wątku zostało
zjedzone przez _gcc_deregister_frame, ale i tak - według profilera - cały
program liczył się trochę krócej...

Co to jest? Kiepska implementacja OpenMP? Urok systemu MS Windows XP ?
(Komputer z fizycznie 2-ma rdzeniami i tyle właśnie wątków jest z OpenMP.)

A może jest tak, że jak program jest uruchomiony jako jednowątkowy, to idzie
na jednym rdzeniu i nikomu/niczemu nie pozwala sobie przerywać (prawie 100%
obciążenia rdzenia), natomiast dwuwątkowo co chwila blokuje go sam system
(obciążenie obu rdzeni jest jakieś takie połowiczne). I choć CPU-time jest -
jak widzi to profiler - 3.2 sekundy - to wall-time jest niemal
dwuminutowy?!

Ma ktoś pomysł jak to rozruszać?




Flat profile: <<< wersja 1-wątkowa >>>

time seconds seconds calls us/call us/call name
98.78 4.87 4.87 2000001 2.43 2.43 __main_MOD_solve
1.22 4.93 0.06 MAIN__

granularity: each sample hit covers 4 byte(s) for 0.20% of 4.93 seconds


Flat profile: <<< wersja 2-wątkowa >>>

time seconds seconds calls us/call us/call name
71.70 2.23 2.23 2000001 1.11 1.11 __gcc_deregister_frame
21.86 2.91 0.68 MAIN__
6.11 3.10 0.19 2000001 0.09 1.21 __main_MOD_solve
0.32 3.11 0.01 __chkstk_ms

granularity: each sample hit covers 4 byte(s) for 0.32% of 3.11 seconds

do góry

On Thursday, March 1, 2012 9:34:06 PM UTC, slawek wrote:
> Co to jest? Kiepska implementacja OpenMP? Urok systemu MS Windows XP ?
> (Komputer z fizycznie 2-ma rdzeniami i tyle właśnie wątków jest z OpenMP.)

Cos masz zepsute u siebie IMHO, Windows nie ma problemu z programami wielowatkowymi.

RW

do góry

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

Jakieś cuda niewidy. Albo jeden albo drugi pomiar masz źle robiony.
Wykonaj je najpierw na czymś bardziej miarodajnym niż 2 us. Najlepiej o
kilka rzędów wielkości.

--
Mateusz Bogusz

do góry

Użytkownik "Roman W" <b...@g...pl> napisał w wiadomości grup
dyskusyjnych:47771.22.1330645656356.JavaMail.geo-dis
cussion-forums@ynlw24...
> Cos masz zepsute u siebie IMHO, Windows nie ma problemu z programami
> wielowatkowymi.

Nie. Puściłem to na Linuksie (16 rdzeni) i jest równie źle, a nawet gorzej.
Dziwne.

do góry

Użytkownik "Karol Y" <k...@o...pl> napisał w wiadomości grup
dyskusyjnych:jip3ao$9u9$...@n...news.atman.pl...
>> 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!
>
> Jakieś cuda niewidy. Albo jeden albo drugi pomiar masz źle robiony.
> Wykonaj je najpierw na czymś bardziej miarodajnym niż 2 us. Najlepiej o
> kilka rzędów wielkości.

Spokojnie - oba pomiary robiłem stoperem - takie coś z takimi guzikami do
przyciskania.

I nie trzeba jakiejś ultra-dokładności - nawet bez zegarka widać, że OpenMP
drastycznie ZWIĘKSZA czas jaki potrzebuje program na przeprowadzenie tych
samych obliczeń, choć na zdrowy rozum powinien ZMNIEJSZAĆ, bo po to jest
OpenMP.

do góry

> I nie trzeba jakiejś ultra-dokładności - nawet bez zegarka widać, że
> OpenMP drastycznie ZWIĘKSZA czas jaki potrzebuje program na
> przeprowadzenie tych samych obliczeń, choć na zdrowy rozum powinien
> ZMNIEJSZAĆ, bo po to jest OpenMP.

Nie wiem jak zbudowany jest OpenMP, ale zapewne takie rzeczy jak pula
wątków, a nie tworzenie ich za każdym razem używa. To co pozostaje, to w
takim razie synchronizacja / komunikacja między wątkami. Tutaj masz
wszystko dobrze?

--
Mateusz Bogusz

do góry

Dnia 01-03-2012 o 22:34:06 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!
>
> Ciekawe: gprof stwierdza, że to co się zaoszczędziło na 2-gim wątku
> zostało zjedzone przez _gcc_deregister_frame, ale i tak - według
> profilera - cały program liczył się trochę krócej...
>
> Co to jest? Kiepska implementacja OpenMP? Urok systemu MS Windows XP ?
> (Komputer z fizycznie 2-ma rdzeniami i tyle właśnie wątków jest z
> OpenMP.)
>
> A może jest tak, że jak program jest uruchomiony jako jednowątkowy, to
> idzie na jednym rdzeniu i nikomu/niczemu nie pozwala sobie przerywać
> (prawie 100% obciążenia rdzenia), natomiast dwuwątkowo co chwila blokuje
> go sam system (obciążenie obu rdzeni jest jakieś takie połowiczne). I
> choć CPU-time jest - jak widzi to profiler - 3.2 sekundy - to wall-time
> jest niemal dwuminutowy?!
>
> Ma ktoś pomysł jak to rozruszać?

myślę, że może być tak, że dwurdzeniowy program poświęca dużo czasu na
przerzucanie danych między rdzeniami, a jednordzeniowy cały czas ma dane w
tym rdzeniu, co trzeba (bo jedynym)
może być coś innego, Fortrana ni OpenMP nie znam, nie wiem co twój kod
robić próbuje...

--
Jordan Szubert

do góry

On Friday, March 2, 2012 12:24:17 AM UTC, slawek wrote:

> I nie trzeba jakiejś ultra-dokładności - nawet bez zegarka widać, że OpenMP
> drastycznie ZWIĘKSZA czas jaki potrzebuje program na przeprowadzenie tych
> samych obliczeń, choć na zdrowy rozum powinien ZMNIEJSZAĆ, bo po to jest
> OpenMP.

Programowanie wielowatkowe to nie jest magiczny sposob na zwiekszenie wydajnosci.

RW

do góry

Użytkownik "Karol Y" <k...@o...pl> napisał w wiadomości grup
dyskusyjnych:jip477$asl$...@n...news.atman.pl...
> Nie wiem jak zbudowany jest OpenMP, ale zapewne takie rzeczy jak pula
> wątków, a nie tworzenie ich za każdym razem używa. To co pozostaje, to w
> takim razie synchronizacja / komunikacja między wątkami. Tutaj masz
> wszystko dobrze?

OpenMP jest prosty jak konstrukcja cepa. Wystarczy wstawić pętlę w "nawiasy"

!$omp parallel do
do i=1,N
a(i) = b(i) * b(i) + c + d + etc
enddo
!$omp end parallel do

i to co jest w niej robione jest dzielone na n-wątków (gdzie n to liczba
rdzeni, no chyba że ustawimy inaczej).

Synchronizacja jest robiona przez blokadę na !$omp end, a komunikacja jest
niepotrzebna, bo to model ze wspólną pamięcią.

Nie ma problemów dostępem do pamięci, bo... po prostu pętla wewnętrzna jest
tak napisana, że przetwarza zupełnie różne fragmenty tablic - nigdy jeden
drugiemu nie zmodyfikuje pamięci, bo zapisuje tylko "swoje" a(i).

do góry

Użytkownik "Jordan Szubert" <u...@j...us.to> napisał w wiadomości grup
dyskusyjnych:o...@a...home...
> myślę, że może być tak, że dwurdzeniowy program poświęca dużo czasu na
> przerzucanie danych między rdzeniami, a jednordzeniowy cały czas ma dane w
> tym rdzeniu, co trzeba (bo jedynym)

Wic w tym, że nie trzeba tych danych przerzucać - bo i po co?

One są przetwarzane _równolegle_ - tj. wektor b jest tworzony z wektora a
tak, że połowę elementów b oblicza wątek 1, a drugą połowę wątek 2.
Oczywiście żaden z wątków nie używa wyników które są otrzymywane poza nim
samym.

W dodatku to był AMD, czyli _wspólne_ cache.

> może być coś innego, Fortrana ni OpenMP nie znam, nie wiem co twój kod
> robić próbuje...

Nie próbuje, tylko robi i to dość skutecznie (jeżeli jest jednowątkowy).

Jeżeli jest uruchomiony z OpenMP też robi to co powinien - tyle że
przeraźliwie wolno (2 minuty zamiast 5 sekund).

A najciekawsze, że profiler daje "dobre" oszacowania - dokładnie takie
jakich spodziewałbym się teoretycznie - tyle, że te oszacowania zupełnie
rozmijają się z tym, co widać na zegarku (takim na rękę, nakręcanym).

Gdzieś jest błąd. I oczywiście jest narzut na tworzenie wątków (200 tysięcy
razy są tworzone), ale: 1. tak to się w OpenMP robi "podręcznikowo"; 2. ten
narzut jest łapany przez profiler jako całkiem nieduży i akceptowalny.

do góry