On 06.03.2012 10:43, slawek wrote:
>
> Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości grup
> dyskusyjnych:jj3soa$jrf$...@m...internetia.pl...
>> ./a.out 1,97s user 0,00s system 389% cpu 0,507 total
>>
>> I mamy wykonanie 40% szybciej na 2 rdzeniach z HT (z narzutem na
>> zrównoleglenie 180%).
>>
>> Magia polega na dwóch zmianach:
>
> Przypadkiem zauważyłeś, że MSVC to Windows - natomiast ty uruchamiasz i
> testujesz pod Linuksem?
>
> Połowa (większa) problemu to narzuty "wewnętrzne" - widać po twoim
> teście jedynie to, że Linuks sprawdza się lepiej (czyli jak trzeba).
>
>> 1. NIE wykonywaniu TEGO SAMEGO kodu wielokrotnie (naprawdę się
>
> do for paralell jest równoważne parze linijek parallel/do for --
> przynajmniej to wyczytałem w opisie OpenMP
Bo tam jest to zapisane.
A czy wyczytałeś przy okazji coś o koszcie synchronizacji? Każdy blok
parallel to 2 punkty synchronizacji.

0x08048576 <+134>: call 0x8048474 <GOMP_parallel_start@plt>
0x0804857b <+139>: mov DWORD PTR [esp],esi
0x0804857e <+142>: call 0x8048750 <main._omp_fn.0>
0x08048583 <+147>: call 0x8048484 <GOMP_parallel_end@plt>

Lepiej je wykonać 200 razy niż 20000 razy. A jeszcze lepiej wykonać je
tylko raz.

Btw: na podstawie tu przedstawionych wniosków, stosując 2 drobne
modyfikacje w kodzie slawka uzyskałem czas:
$ time ./a.out
CPU time = 1.040000
just for fun 91.999668
./a.out 1,00s user 0,04s system 393% cpu 0,264 total

>
>> 2. sensowny przydział bloków obliczeń
>
> Sensowny dla MS Windows oznacza w tym przypadku kawałki liczące się
> około milisekund. A w programie są mikrosekundowe.
Zazwyczaj im mniej synchronizacji tym szybciej kod działa - to chyba
oczywiste. Przydaje się też, żeby nie właziły sobie nawzajem w cache.

--
Pozdrawiam
Michoo