Użytkownik "Edek Pienkowski" <e...@g...com> napisał w
wiadomości grup dyskusyjnych:jiqfqb$dvn$...@i...gazeta.pl...
> 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.

1. IMHO te -fX tylko zezwalają GCC na próbę tego rodzaju optymalizacji -
dają więcej swobody kompilatorowi - i nie są aktywowane nawet przy -O3, a z
opisu w dokumentacji wyglądają zachęcająco.

2. Zasadniczy problem jest taki sam nawet jeżeli da się tylko -O0, albo i
nie da żadnej opcji (poza oczywiście daniem/niedaniem -fopenmp ) Więc to nie
to.

do góry

Dnia Fri, 02 Mar 2012 14:07:21 +0100, slawek napisal:

> Użytkownik "Edek Pienkowski" <e...@g...com> napisał w
> wiadomości grup dyskusyjnych:jiqfqb$dvn$...@i...gazeta.pl...
>> 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.
>
> 1. IMHO te -fX tylko zezwalają GCC na próbę tego rodzaju optymalizacji -
> dają więcej swobody kompilatorowi - i nie są aktywowane nawet przy -O3,
> a z opisu w dokumentacji wyglądają zachęcająco.

-funroll-all-loops
Unroll all loops, even if their number of iterations is
uncertain when the loop is entered. This usually makes programs run more
slowly.
-funroll-all-loops implies the same options as -funroll-loops,

Czego w opisie z man-a nie rozumiesz?

>
> 2. Zasadniczy problem jest taki sam nawet jeżeli da się tylko -O0, albo
> i nie da żadnej opcji (poza oczywiście daniem/niedaniem -fopenmp ) Więc
> to nie to.

Tak, to było tak poza głównym tematem.

Edek

do góry

Użytkownik "Paweł Kierski" <n...@p...net> napisał w wiadomości grup
dyskusyjnych:jiqgdp$2sv$...@i...gazeta.pl...
> Obok napisałem, ale dla pewności - ten program to już tylko ta jedna
> pętla?

W zasadzie tak. W każdym razie OpenMP jest tylko użyte w tej jednej pętli -
reszta jest jednowątkowa.

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

Wystarczy ctrl+shif+esc. No właśnie że jest około 100% dla jednowątkowej i
30% per CPU dla 2-wątkowej.

I nie tłumaczy to 20-krotnego wzrostu czasu wykonania.

Spróbuję rozdzielić inaczej wątki - nie według puli indeksów od 1 do N1, od
N1 do N, ale na np. parzyte-nieparzyste elementy macierzy a, b.

Dla AMD - wyobrażam to sobie - mogło dojść do rywalizacji o cache pomiędzy
wątkami - jest wspólna pamięć cache, wątek jeden ściąga sobie 100 000 liczb
double, potem przychodzi wątek 2 i też chce ściągnąć 100 000 liczb double.

Ale co w takim razie widzi profiler?

do góry

Użytkownik "Edek Pienkowski" <e...@g...com> napisał w
wiadomości grup dyskusyjnych:jiqh0g$dvn$...@i...gazeta.pl...
> -funroll-all-loops
> Unroll all loops, even if their number of iterations is
> uncertain when the loop is entered. This usually makes programs run more
> slowly.

Ok.

do góry

Użytkownik "slawek" <s...@h...pl> napisał w wiadomości grup
dyskusyjnych:4f50c952$0$1273$6...@n...neostrada
.pl...
> Dla AMD - wyobrażam to sobie - mogło dojść do rywalizacji o cache pomiędzy
> wątkami - jest wspólna pamięć cache, wątek jeden ściąga sobie 100 000
> liczb double, potem przychodzi wątek 2 i też chce ściągnąć 100 000 liczb
> double.

Ogólnie liczb jest 200 000.

do góry

Dnia Fri, 02 Mar 2012 14:00:56 +0100, slawek napisal:

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

Pogrupuj po 64 i spróbuj:

schedule(dynamic, 64)

Bo dostępy typu x[n] i x[n+1] są zabójcze.

Edek

do góry

Dnia Fri, 02 Mar 2012 13:26:38 +0000, Edek Pienkowski napisal:

> Dnia Fri, 02 Mar 2012 14:00:56 +0100, slawek napisal:
>
>> 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.
>>
>>
> Pogrupuj po 64 i spróbuj:
>
> schedule(dynamic, 64)

... bo inaczej zostawiasz decyzje gcc i/lub openMP, a jednocześnie
używasz:

-floop-parallelize-all
Use the Graphite data dependence analysis to identify loops
that can be parallelized. Parallelize all the loops that can be analyzed
to not contain
loop carried dependences without checking that it is
profitable to parallelize the loops.

Edek

do góry

Użytkownik "Edek Pienkowski" <e...@g...com> napisał w
wiadomości grup dyskusyjnych:jiqhqe$dvn$...@i...gazeta.pl...
> Dnia Fri, 02 Mar 2012 14:00:56 +0100, slawek napisal:
>
>> 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.
>>
>
> Pogrupuj po 64 i spróbuj:
>
> schedule(dynamic, 64)
>
> Bo dostępy typu x[n] i x[n+1] są zabójcze.
>
> Edek

Trochę nie na temat - opis opcji za
http://gcc.gnu.org/onlinedocs/gcc-3.3.6/g77/Optimize
-Options.html

-funroll-loops
Typically improves performance on code using iterative DO loops by unrolling
them and is probably generally appropriate for Fortran, though it is not
turned on at any optimization level. Note that outer loop unrolling isn't
done specifically; decisions about whether to unroll a loop are made on the
basis of its instruction count.

do góry

Dnia Fri, 02 Mar 2012 14:31:53 +0100, slawek napisal:

>
> Trochę nie na temat - opis opcji za
> http://gcc.gnu.org/onlinedocs/gcc-3.3.6/g77/Optimize
-Options.html
>
> -funroll-loops Typically improves performance on code using iterative DO
> loops by unrolling them and is probably generally appropriate for
> Fortran, though it is not turned on at any optimization level. Note that
> outer loop unrolling isn't done specifically; decisions about whether to
> unroll a loop are made on the basis of its instruction count.

Przekształcenia pętli w 3.3 to nie to samo, co w 4.6. Powiedziałbym nawet,
że dzielą je lata świetlne.

Może patrzę nie w to miejsce, co trzeba, nie używam fortrana.

Edek

do góry

Użytkownik "Edek Pienkowski" <e...@g...com> napisał w
wiadomości grup dyskusyjnych:jiqi0e$dvn$1...@i...gazeta.pl...
>> Pogrupuj po 64 i spróbuj:
>>
>> schedule(dynamic, 64)

Nie pomogło: ani dynamic, ani static. Ani 64, ani 1, ani 1000 .

> ... bo inaczej zostawiasz decyzje gcc i/lub openMP, a jednocześnie
> używasz:
>
> -floop-parallelize-all

Sprawdzałem też z "gołym" wywołaniem gfortran bez jakichkolwiek opcji.

do góry