On 02.03.2012 20:11, slawek wrote:
[...]
> /***************************************************
****************************************************
************************
>
> !
> ! Program test-omp
> !
> ! /openmp
> !
Zacytuję ioccc:
You can hide a semi truck in 300 lines of C.

Tu jest w 88 liniach C ukryty fiat 126p z 4 przyczepami - nic dziwnego,
że jedzie tak wolno.


Wyniki z mojego komputera (core i5) i gcc-4.6:
(wywaliłem niepotrzebną linijkę z getchar() na końcu)
$ gcc-4.6 -O3 kot.c
$ time ./a.out
CPU time = 8.100000
just for fun 91.999668
./a.out 8,12s user 0,01s system 99% cpu 8,128 total

$ gcc-4.6 -O3 --fast-math kot.c
$ time ./a.out
CPU time = 0.700000
just for fun 91.999668
./a.out 0,71s user 0,00s system 99% cpu 0,716 total

Ciekawi mogą zajrzeć do assemblera i zobaczyć, że gcc zastąpiło
dzielenie i 2 dodawania przez mnożenie i dodawanie. Psuje to pełną
zgodność ze standardem, ale generuje kod 11 razy szybszy.

$ gcc-4.6 -O3 --fast-math -fopenmp kot.c
$ time ./a.out
CPU time = 7.540000
just for fun 91.999668
./a.out 7,18s user 0,39s system 394% cpu 1,917 total

Interesujące - wszystkie rdzenie obciążone, dużo czasu w kernel mode a
czas wykonania ponad 2 razy dłuższy nie mówiąc o czasie procesora, który
jest 10 razy dłuższy.

Pora pobieżnie przejrzeć kod i zaaplikować patch:

- #pragma omp parallel
{

- #pragma omp for schedule(static,100)
for(i = 0; i < n; i++)
v2[i] = v1[i]/(c*c) + epsilon0 + pi;


setup(vec[i1]);
+ #pragma omp parallel for schedule(static,4096)
for(j = 0; j < m; j++)
{


$ gcc-4.6 -O3 --fast-math -fopenmp kod.c
$ time ./a.out
CPU time = 1.960000
just for fun 91.999668
./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:
1. NIE wykonywaniu TEGO SAMEGO kodu wielokrotnie (naprawdę się
zastanawiam, czy slawek nie umie czytać, czy zrobił to specjalnie(co
będzie pewnie utrzymywać)).
2. sensowny przydział bloków obliczeń

--
Pozdrawiam
Michoo