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