Użytkownik "Roman W" <b...@g...pl> napisał w wiadomości grup
dyskusyjnych:8479760.53.1330651071927.JavaMail.geo-d
iscussion-forums@vbux23...
> Programowanie wielowatkowe to nie jest magiczny sposob na zwiekszenie
> wydajnosci.

Programowanie w ogóle nie ma wiele wspólnego z magią.

Jednak OpenMP wymyślono właśnie po to, aby programy liczyły szybciej. I
jeżeli "podręcznikowy" przykład użycia OpenMP działa jednak wolniej - to
chyba coś jest źle z tym OpenMP (lub jego implementacją). Ok, OpenMP to
raczej pod mainframe (tak, trzeba będzie sprawdzić na klastrze, takim nieco
większym), ale niegłupio byłoby np. mieć program liczący 8 razy szybciej na
"zwykłym PC" (SSE daje 2x, czterordzeniowiec daje 4x). Aha, oczywiście jest
jeszcze GPU (bardzo sensownie byłoby go użyć), ale wymagałoby to
"zasadniczej przeróbki programu" - no i przywiązałoby go to do konkretnego
hardware (co też jest w planach).

Inaczej - masz zaopatrywać 20 dużych hipermarketów. I teraz ktoś ci mówi:
"kupienie tuzina ciągników siodłowych z naczepami to zły pomysł na
zwiększenie wydajności, WIĘCEJ I SZYBCIEJ przewieziesz jednym fiacikiem
szwagra". Sorry, ale właśnie coś takiego napisałeś - tyle że o programach
współbieżnych.

do góry

W dniu 3/2/2012 1:03 PM, slawek wrote:
>

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

Tak z głupia frant, bo ani OpenMP, ani tego kompilatora nie znam, ale
liczysz czas wersji release, a nie debug?

Pozdrawiam,
Arkadesh

do góry

Dnia Fri, 02 Mar 2012 12:53:09 +0100, slawek napisal:

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

To jak udało ci się to spieprzyć? Serio, chcesz wiedzieć, dlaczego twój
kod chodzi wolno, to się podziel. To nie OpenMP jest spieprzony.

Edek

do góry

Użytkownik "Arkadiusz Dymek" <a...@n...bedzie> napisał w wiadomości grup
dyskusyjnych:4f50b94c$...@n...home.net.pl...
> Tak z głupia frant, bo ani OpenMP, ani tego kompilatora nie znam, ale
> liczysz czas wersji release, a nie debug?

Kompilator to "tak naprawdę" GCC (4.6 jak pamiętam) - MinGW.

Z tymi samymi ustawieniami, raz z -fopenmp program.f95, a raz z samym
program.f95

gfortran -Wall -O3 -Ofast -floop-interchange -floop-strip-mine -floop-block
-fgraphite-identity -floop-flatten -floop-parallelize-all -ftree-loop-if-convert
-ftree-loop-distribution -ftree-loop-im -ftracer -funroll-loops -funroll-all-loops
-fvariable-expansion-in-unroller -ffast-math -fassociative-math -freciprocal-math
-ftree-vectorize -ftree-vectorizer-verbose=5 -msse2 -funswitch-loops %1 %2
%3 %4 %5

Gdy idzie pod profiler, to oczywiście dochodzi -pg do opcji, lecz...
oczywiście tak samo dla OpenMP jak i bez.

Co ciekawe - spodziewałbym się, że wersja z OpenMP będzie przyciążała CPU na
2*100%, tymczasem tak nie jest, może po 30% na każdym rdzeniu.

Natomiast gdy odpali się dwie instancje wersji jednordzeniowej, to
rzeczywiście jest 99% na każdym rdzeniu.

do góry

Użytkownik "Edek Pienkowski" <e...@g...com> napisał w
wiadomości grup dyskusyjnych:jiqdm3$dvn$...@i...gazeta.pl...
> To jak udało ci się to spieprzyć? Serio, chcesz wiedzieć, dlaczego twój
> kod chodzi wolno, to się podziel. To nie OpenMP jest spieprzony.

Ale tam w pętli nie ma nic szczególnego - po prostu

b(i) = bardzo długie wyrażenie z a(i) i półtuzinem stałych różnych

Ty twierdzisz, że to nie OpenMP. Ok. Ale OpenMP to "teoria". Praktyka jest
jednak taka jaka jest - być może winna jest biblioteka pthreads, być może
winne są Windows, a być może coś nie pasuje procesorowi. Fakt jest faktem -
wersja z OpenMP muli się niesamowicie. Choć według profilera jest szybsza 2x
(tak jak powinna być).

Więc co się naprawdę dzieje? Wiesz? Nie wiesz?! Aha, nie wiesz i tylko
spamujesz...

do góry

Dnia Fri, 02 Mar 2012 13:35:50 +0100, slawek napisal:

> Użytkownik "Edek Pienkowski" <e...@g...com> napisał w
> wiadomości grup dyskusyjnych:jiqdm3$dvn$...@i...gazeta.pl...
>> To jak udało ci się to spieprzyć? Serio, chcesz wiedzieć, dlaczego twój
>> kod chodzi wolno, to się podziel. To nie OpenMP jest spieprzony.
>
> Ale tam w pętli nie ma nic szczególnego - po prostu
>
> b(i) = bardzo długie wyrażenie z a(i) i półtuzinem stałych różnych

Przypuszczam, że jest to coś, na co nie zwróciłeś uwagi. Skoro
twierdzisz, że nie ma tam nic złego, to albo faktycznie nie ma
i wszystko hula, albo jednak jest, ale ty tego nie widzisz.

>
> Ty twierdzisz, że to nie OpenMP. Ok. Ale OpenMP to "teoria". Praktyka
> jest jednak taka jaka jest - być może winna jest biblioteka pthreads,
> być może winne są Windows, a być może coś nie pasuje procesorowi. Fakt
> jest faktem -
> wersja z OpenMP muli się niesamowicie. Choć według profilera jest
> szybsza 2x (tak jak powinna być).

Tworzenie wątków na XP jest relatywnie drogie, ale pisałeś, że na linuxie
jest to samo.

>
> Więc co się naprawdę dzieje? Wiesz? Nie wiesz?! Aha, nie wiesz i tylko
> spamujesz...

Nie wiem, bo mało informacji udzielasz. Jak będziesz cały czas
powtarzał "nic złego tam nie ma" to nic z tego nie będzie. Fortrana
nie używałem już dość długo, ale może zrozumiem, albo kto inny
zrozumie.

Edek

do góry

Dnia Fri, 02 Mar 2012 13:28:18 +0100, slawek napisal:

> Użytkownik "Arkadiusz Dymek" <a...@n...bedzie> napisał w wiadomości
> grup dyskusyjnych:4f50b94c$...@n...home.net.pl...
>> Tak z głupia frant, bo ani OpenMP, ani tego kompilatora nie znam, ale
>> liczysz czas wersji release, a nie debug?
>
> Kompilator to "tak naprawdę" GCC (4.6 jak pamiętam) - MinGW.
>
> Z tymi samymi ustawieniami, raz z -fopenmp program.f95, a raz z samym
> program.f95
>
> gfortran -Wall -O3 -Ofast -floop-interchange -floop-strip-mine
> -floop-block -fgraphite-identity -floop-flatten -floop-parallelize-all
> -ftree-loop-if-convert
> -ftree-loop-distribution -ftree-loop-im -ftracer -funroll-loops
> -funroll-all-loops -fvariable-expansion-in-unroller -ffast-math
> -fassociative-math -freciprocal-math -ftree-vectorize
> -ftree-vectorizer-verbose=5 -msse2 -funswitch-loops %1 %2
> %3 %4 %5

Wywal większość -fX, heurystyka gcc może być lepsza, a ty wymuszasz
arbitralnie to, co sam uważasz za stosowne. Nie mówię o fast-math
oczywiście.

Edek

do góry

Użytkownik "Edek Pienkowski" <e...@g...com> napisał w
wiadomości grup dyskusyjnych:jiqfeg$dvn$...@i...gazeta.pl...
> Przypuszczam, że jest to coś, na co nie zwróciłeś uwagi. Skoro
> twierdzisz, że nie ma tam nic złego, to albo faktycznie nie ma
> i wszystko hula, albo jednak jest, ale ty tego nie widzisz.

Nic tam nie ma takiego, ba! Mogę dać b(i) = a(i) + 1 i jest to samo.

> Tworzenie wątków na XP jest relatywnie drogie, ale pisałeś, że na linuxie
> jest to samo.

Też myślałem że to to. Ale dalej zostaje zagadka dlaczego profiler
"prawidłowo" pokazuje zysk na czasie... którego na prawdę nie ma.

Tj. profilowanie daje czasy mniejsze o połowę dla dwóch wątków niż dla
jednego - a taki zegarek na rękę ze wskazówkami - zupełnie coś przeciwnego
(20 razy dłużej).

Wygląda na to, że program dwuwątkowy... po prostu nie pracuje. Tzn. co
chwila oddaje inicjatywę systemowi, a system robi coś innego. Czyli cpu-time
jest mniejszy, a wall-time rośnie.

do góry

W dniu 2012-03-02 13:35, slawek pisze:
>
> Użytkownik "Edek Pienkowski" <e...@g...com> napisał w
> wiadomości grup dyskusyjnych:jiqdm3$dvn$...@i...gazeta.pl...
>> To jak udało ci się to spieprzyć? Serio, chcesz wiedzieć, dlaczego twój
>> kod chodzi wolno, to się podziel. To nie OpenMP jest spieprzony.
>
> Ale tam w pętli nie ma nic szczególnego - po prostu
>
> b(i) = bardzo długie wyrażenie z a(i) i półtuzinem stałych różnych

Zredukuj program do samej pętli zawierające b(i) = a(i)+a(i), puść
w obu wersjach. Jeśli wyeliminujesz _wszystko_ inne, a problem będzie
nadal, to można podejrzewać implementację OpenMP, system itp. Bez
takiego testu, gdybym miał się zakładać, to obstawiałbym błąd w twoim
kodzie (lub ogólniej - interakcje z innymi kawałkami kodu). Aha -
sprawdź dla skrajnie różnych rozmiarów tablic w obu wersjach.

[...]
> Więc co się naprawdę dzieje? Wiesz? Nie wiesz?! Aha, nie wiesz i tylko
> spamujesz...

Sprawdź redukując maksymalnie problem. W ten sposób czegoś się dowiesz.

--
Paweł Kierski
n...@p...net

do góry

W dniu 2012-03-02 14:00, slawek pisze:
>
> Użytkownik "Edek Pienkowski" <e...@g...com> napisał w
> wiadomości grup dyskusyjnych:jiqfeg$dvn$...@i...gazeta.pl...
>> Przypuszczam, że jest to coś, na co nie zwróciłeś uwagi. Skoro
>> twierdzisz, że nie ma tam nic złego, to albo faktycznie nie ma
>> i wszystko hula, albo jednak jest, ale ty tego nie widzisz.
>
> Nic tam nie ma takiego, ba! Mogę dać b(i) = a(i) + 1 i jest to samo.

Obok napisałem, ale dla pewności - ten program to już tylko ta jedna
pętla?

[...]
> Tj. profilowanie daje czasy mniejsze o połowę dla dwóch wątków niż dla
> jednego - a taki zegarek na rękę ze wskazówkami - zupełnie coś
> przeciwnego (20 razy dłużej).
>
> Wygląda na to, że program dwuwątkowy... po prostu nie pracuje. Tzn. co
> chwila oddaje inicjatywę systemowi, a system robi coś innego. Czyli
> cpu-time jest mniejszy, a wall-time rośnie.

Zobacz obciążenie procesora w czasie wykonania obu wersji. Na Windows
polecam Process Explorer i wykresy ogólne i per proces.

--
Paweł Kierski
n...@p...net

do góry