Użytkownik "Roman W" <b...@g...pl> napisał w wiadomości grup
dyskusyjnych:17879294.84.1330773260414.JavaMail.geo-
discussion-forums@vbbfy7...
> On Saturday, March 3, 2012 10:13:08 AM UTC, slawek wrote:
>> 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ę
>
> To, skoro masz do zrownoleglenia prosta petle, olej Open MP i tworz watki
> samemu? W C++ moglbys uzyc np. boost::threads. Latwe w uzyciu i tanie.

Więc właśnie dojrzałem do olania.

Mam dużo rachowania na liczbach zespolonych, ma to działać pod
Uniksem/Linuksem/? (co tam gdzie się znajdzie), ma to w miarę możliwości
używać wielu CPU (tzn. 2048 rdzeni na ten przykład), ma być
łatwe-proste-przyjemne (jeden plik źródłowy), z bibliotek to niech używa
lapack/blas/itp. a i to może lepiej nie, bo i po co?

Wybór padł na Fortran, bo dość łatwo go znaleźć na mainframesach (zwykle są
ze 3-4 kompilatory do wyboru). Oczywiście (?) nie Fortran 77, bo nie chce mi
się liczyć do 73. A po lekturze książki Krzyżanowskiego "Obliczenia
inżynierskie i naukowe. Skuteczne, szybkie, efektowne", Wydawnictwo Naukowe
PWN, 2011, http://www.mimuw.edu.pl/~przykry/ przyszło mi do głowy, że jak
już jest gotowy (tzn. działa, ale sam problem który jest nim rozwiązywany
"ewoluuje", np. udało mi się rozwiązać niezły jego kawałek analitycznie, co
stwarza zupełnie nowe możliwości) program, to dodanie współbieżności a'la
OpenMP jest trywialne i - co najważniejsze - da się zrobić standardowo w
Fortranie. Bez niszczenia tego, co jest.

I niestety, wydaje się że cała koncepcja OpenMP jest w tej chwili po prostu
błędna. Podobne do moich problemy są dość często spotykane - program z
OpenMP działa wolniej niż bez. A skoro działa wolniej - to nie ma
najmniejszego sensu używać. Bo i po co używać czegoś, co wymaga dodatkowej
roboty i od programisty, i od komputera - a nic w zamian nie daje?!

I jeszcze jedno - OpenMP z GCC 4.6 obciąża rdzenie 20% do 30%. OpenMP jakie
daje Microsoft (w MS Visual Studio Professional 2010) jest znacznie
wydajniejsze: obciążenie idzie do 100% na każdym rdzeniu. Ale i tak program
z OpenMP osiągnął wydajność... 50% wydajności programu bez OpenMP. I
dlatego - jeżeli nie będzie postępu - OpenMP jest chybione.

To już wolę PBS i uruchomić endziesiąt instancji mojego programu - każda z
innym zestawem danych. Też jest równolegle, a nawet prościej - nie trzeba
nic w programie zmieniać.

A jak będę się nudził, to raczej spróbować na GPU/CUDA niż drążyć OpenMP.
Zwłaszcza iż OpenMP nie wiadomo jak obsługuje I/O i takie tam.