🚀 go-pugleaf

Dnia Sat, 29 Sep 2012 12:21:56 +0200, Adam Majewski napisal:

> Witam.
> 
> W książce :Programowanie w Linuksie. Ćwiczenia
> Autorzy: Katarzyna Kuźniar, Kazimierz Lal, Tomasz Rak
> Data wydania: 2012/07
> http://helion.pl/ksiazki/programowanie-w-linuksie-cwiczenia-katarzyna-kuzniar-kazimierz-lal-tomasz-rak,cwplin.htm
> 
> jest porównanie czsu wykonania programu mnożącego macierze dwuwymiarowe.
> Można pobrać przykładowy rozdział w pdf i tam jest ten przykład.
> Dla gcc czas = 1345 ms
> dla icc czas =  109 ms
> 
> Czyli program skompilowany przez icc wykonywany jest 12 razy szybciej.
> 
> Co o tym sądzicie ?

Zależnie od wymiarów tablic i wersji gcc można trafić na "corner case" [1],
który icc obsługuje o niebo lepiej niż gcc. Gcc też samo nawet w tak
prostych przypadkach nie konwertuje zagnieżdżonych pętli ani do
cache-oblivious ani nawet do "tiles" - trzeba to zrobić ręcznie. Nie
sprawdzałem, czy icc samo tak przekształca kod, a to jest ważne dla
dużych macierzy.


[1] "Cache aliasing", możesz znaleźć opis w Intel Optimization Guide
-- 
Edek

On 29.09.2012 15:11, Edek Pienkowski wrote:
> Dnia Sat, 29 Sep 2012 12:21:56 +0200, Adam Majewski napisal:
>
>> Witam.
>>
>> W książce :Programowanie w Linuksie. Ćwiczenia
>> Autorzy: Katarzyna Kuźniar, Kazimierz Lal, Tomasz Rak
>> Data wydania: 2012/07
>> http://helion.pl/ksiazki/programowanie-w-linuksie-cwiczenia-katarzyna-kuzniar-kazimierz-lal-tomasz-rak,cwplin.htm
>>
>> jest porównanie czsu wykonania programu mnożącego macierze dwuwymiarowe.
>> Można pobrać przykładowy rozdział w pdf i tam jest ten przykład.
>> Dla gcc czas = 1345 ms
>> dla icc czas =  109 ms
>>
>> Czyli program skompilowany przez icc wykonywany jest 12 razy szybciej.
>>
>> Co o tym sądzicie ?
>
> Zależnie od wymiarów tablic i wersji gcc można trafić na "corner case" [1],
> który icc obsługuje o niebo lepiej niż gcc. Gcc też samo nawet w tak
> prostych przypadkach nie konwertuje zagnieżdżonych pętli ani do
> cache-oblivious ani nawet do "tiles" - trzeba to zrobić ręcznie. Nie
> sprawdzałem, czy icc samo tak przekształca kod, a to jest ważne dla
> dużych macierzy.
>
>
> [1] "Cache aliasing", możesz znaleźć opis w Intel Optimization Guide
>
Czy to znaczy że jest to jednostkowy przypadek a ogólnei wyniki powinny 
być porównywalne ?

Adam

Dnia Sat, 29 Sep 2012 16:52:00 +0200, Adam Majewski napisal:

> On 29.09.2012 15:11, Edek Pienkowski wrote:
>> Dnia Sat, 29 Sep 2012 12:21:56 +0200, Adam Majewski napisal:
>>
>>> Witam.
>>>
>>> W książce :Programowanie w Linuksie. Ćwiczenia
>>> Autorzy: Katarzyna Kuźniar, Kazimierz Lal, Tomasz Rak
>>> Data wydania: 2012/07
>>> http://helion.pl/ksiazki/programowanie-w-linuksie-cwiczenia-katarzyna-kuzniar-kazimierz-lal-tomasz-rak,cwplin.htm
>>>
>>> jest porównanie czsu wykonania programu mnożącego macierze dwuwymiarowe.
>>> Można pobrać przykładowy rozdział w pdf i tam jest ten przykład.
>>> Dla gcc czas = 1345 ms
>>> dla icc czas =  109 ms
>>>
>>> Czyli program skompilowany przez icc wykonywany jest 12 razy szybciej.
>>>
>>> Co o tym sądzicie ?
>>
>> Zależnie od wymiarów tablic i wersji gcc można trafić na "corner case" [1],
>> który icc obsługuje o niebo lepiej niż gcc. Gcc też samo nawet w tak
>> prostych przypadkach nie konwertuje zagnieżdżonych pętli ani do
>> cache-oblivious ani nawet do "tiles" - trzeba to zrobić ręcznie. Nie
>> sprawdzałem, czy icc samo tak przekształca kod, a to jest ważne dla
>> dużych macierzy.
>>
>>
>> [1] "Cache aliasing", możesz znaleźć opis w Intel Optimization Guide
>>
> Czy to znaczy że jest to jednostkowy przypadek a ogólnei wyniki powinny 
> być porównywalne ?

Nie rozumiem. Co jest napisane w tej książce?

-- 
Edek

On 29.09.2012 18:25, Edek Pienkowski wrote:
> Dnia Sat, 29 Sep 2012 16:52:00 +0200, Adam Majewski napisal:
>
>> On 29.09.2012 15:11, Edek Pienkowski wrote:
>>> Dnia Sat, 29 Sep 2012 12:21:56 +0200, Adam Majewski napisal:
>>>
>>>> Witam.
>>>>
>>>> W książce :Programowanie w Linuksie. Ćwiczenia
>>>> Autorzy: Katarzyna Kuźniar, Kazimierz Lal, Tomasz Rak
>>>> Data wydania: 2012/07
>>>> http://helion.pl/ksiazki/programowanie-w-linuksie-cwiczenia-katarzyna-kuzniar-kazimierz-lal-tomasz-rak,cwplin.htm
>>>>
>>>> jest porównanie czsu wykonania programu mnożącego macierze dwuwymiarowe.
>>>> Można pobrać przykładowy rozdział w pdf i tam jest ten przykład.
>>>> Dla gcc czas = 1345 ms
>>>> dla icc czas =  109 ms
>>>>
>>>> Czyli program skompilowany przez icc wykonywany jest 12 razy szybciej.
>>>>
>>>> Co o tym sądzicie ?
>>>
>>> Zależnie od wymiarów tablic i wersji gcc można trafić na "corner case" [1],
>>> który icc obsługuje o niebo lepiej niż gcc. Gcc też samo nawet w tak
>>> prostych przypadkach nie konwertuje zagnieżdżonych pętli ani do
>>> cache-oblivious ani nawet do "tiles" - trzeba to zrobić ręcznie. Nie
>>> sprawdzałem, czy icc samo tak przekształca kod, a to jest ważne dla
>>> dużych macierzy.
>>>
>>>
>>> [1] "Cache aliasing", możesz znaleźć opis w Intel Optimization Guide
>>>
>> Czy to znaczy że jest to jednostkowy przypadek a ogólnei wyniki powinny
>> być porównywalne ?
>
> Nie rozumiem. Co jest napisane w tej książce?
>
W książce jest : "rodzaj użytego kompilatora ma duze znaczenie."
Nie rozwijają tego.
Czy można powiedzieć że średni czas wykonywania programu po kompilacji z 
użyciem icc jest znacząco krótszy niż po użyciu gcc ? ( na procesorach 
intela )

Adam

Adam

Dnia Sat, 29 Sep 2012 19:22:31 +0200, Adam Majewski napisal:

> On 29.09.2012 18:25, Edek Pienkowski wrote:
>> Dnia Sat, 29 Sep 2012 16:52:00 +0200, Adam Majewski napisal:
>>
>>> On 29.09.2012 15:11, Edek Pienkowski wrote:
>>>> Dnia Sat, 29 Sep 2012 12:21:56 +0200, Adam Majewski napisal:
>>>>
>>>>> Witam.
>>>>>
>>>>> W książce :Programowanie w Linuksie. Ćwiczenia
>>>>> Autorzy: Katarzyna Kuźniar, Kazimierz Lal, Tomasz Rak
>>>>> Data wydania: 2012/07
>>>>> http://helion.pl/ksiazki/programowanie-w-linuksie-cwiczenia-katarzyna-kuzniar-kazimierz-lal-tomasz-rak,cwplin.htm
>>>>>
>>>>> jest porównanie czsu wykonania programu mnożącego macierze dwuwymiarowe.
>>>>> Można pobrać przykładowy rozdział w pdf i tam jest ten przykład.
>>>>> Dla gcc czas = 1345 ms
>>>>> dla icc czas =  109 ms
[...]
>>> Czy to znaczy że jest to jednostkowy przypadek a ogólnei wyniki powinny
>>> być porównywalne ?
>>
>> Nie rozumiem. Co jest napisane w tej książce?
>>
> W książce jest : "rodzaj użytego kompilatora ma duze znaczenie."
> Nie rozwijają tego.
> Czy można powiedzieć że średni czas wykonywania programu po kompilacji z 
> użyciem icc jest znacząco krótszy niż po użyciu gcc ? ( na procesorach 
> intela )

Kompilator Intela stosowany do kodu na Intele (nie AMD) prawdopodobnie
jest faktycznie najlepszy - musiałbyś poszukać benchmarków (SPEC lub inne).
Średnio, cokolwiek to znaczy, może być z 1% czy może 3% lepszy od gcc.
Zazwyczaj nie ma to większego...

Jeżeli masz konkretny kod, gdzie w optymalizację wkłada się b.dużo 
wysiłku różnice mogą być większe, tak około 10% i lepiej, ale to nigdy nie 
wiadomo w którą stronę i trzeba porównywać konkretne wersje kompilatorów
i wiedzieć, jakich opcji się używa, i na jakim procesorze się 
to uruchamia, głównie pod względem zestawu instrukcji. Większość
linuksów używa zestawu instrukcji najniższego wspólnego mianownika -
poza wyspecjalizowanym kodem, czyli multimediami, memcpy itp.

No i są takie skrajne przykłady, tylko że jeden skrajny przykład nic 
nie znaczy, trzeba mieć wiedzę o dużej ich liczbie, bo nie będą wszystkie
w tę samą stronę. Twórcy kompilatorów liczą każdy procent, ale przyjmują
10% jako zmianę jakościową - inaczej użyszkodnik nie zauważy.

-- 
Edek

Adam Majewski <adammaj1@o2.pl> writes:

> W książce :Programowanie w Linuksie. Ćwiczenia
> Autorzy: Katarzyna Kuźniar, Kazimierz Lal, Tomasz Rak
> Data wydania: 2012/07
> http://helion.pl/ksiazki/programowanie-w-linuksie-cwiczenia-katarzyna-kuzniar-kazimierz-lal-tomasz-rak,cwplin.htm
>
> jest porównanie czsu wykonania programu mnożącego macierze dwuwymiarowe.
> Można pobrać przykładowy rozdział w pdf i tam jest ten przykład.
> Dla gcc czas = 1345 ms
> dla icc czas =  109 ms
>
> Czyli program skompilowany przez icc wykonywany jest 12 razy szybciej.
>
> Co o tym sądzicie ?

Łatwo sprawdzić. Nie mam niestety maszynki z Phenomem II N620 + 4 GB
RAM, najbardziej zbliżona ma nieco wolniejszy zegar i 2 GB RAM:

model name      : AMD Athlon(tm) II X2 245 Processor
cpu MHz         : 2200.000
cache size      : 1024 KB
cpu cores       : 2

Tamten ich Phenom jest podobny:
model name	: AMD Phenom(tm) II N620 Dual-Core Processor
cpu MHz		: 2800.000
cache size	: 1024 KB
cpu cores	: 2


$ gcc -W -Wall test.c -o test
test.c: In function ‘main’:
test.c:57:2: warning: implicit declaration of function ‘gettimeofday’ [-Wimplicit-function-declaration]

$ ./test 500 500 500
arg[0] = 500
arg[1] = 500
arg[2] = 500
Start
Czas: 1375 milisekund

No rzeczywiście... tyle że tak jest bez optymalizacji.

W normalnych warunkach:
$ gcc -O2 -W -Wall test.c -o test
$ ./test 500 500 500
Czas: 251 milisekund
...
Czas: 340 milisekund

Swoją drogą, spore różnice - maszynka jest w tej chwili nieco obciążona,
pewnie dlatego. Trzeba będzie się temu przyjrzeć w wolnej chwili.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
28071 named     20   0  249m  39m 2948 S 160.7  2.3   5612:36 named


Gcc 4.7.2, 64 bity. Kod 32-bitowy:
Czas: 519 milisekund
Czas: 566 milisekund
Czas: 513 milisekund

Owszem, widać wyraźnie różnicę między tymi wynikami (w najlepszym
przypadku czas gcc to 251 ms / 2800 * 2200 (różnice w zegarach CPU) =
ok. 197 ms), ale bez przesady. Nie miałem okazji przetestować z ICC,
przypuszczalnie mają tam lepszy optymalizator potrafiący przerobić
takie coś na SSE.

Złośliwie zauważę, że oni chyba pomylili program pokazujący różnice
między kompilatorami z przykładem "jak nie powinien wyglądać program
w C", zarówno jeśli chodzi o treść jak i o algorytm :-)
-- 
Krzysztof Halasa

On 09/29/2012 12:21 PM, Adam Majewski wrote:
> jest porównanie czsu wykonania programu mnożącego macierze dwuwymiarowe.
> Można pobrać przykładowy rozdział w pdf i tam jest ten przykład.
> Dla gcc czas = 1345 ms
> dla icc czas =  109 ms

ogólna zasada mówi - najpierw zmierz a potem zdecyduj. różne kompilatory
mają różne właściwości, różne optymalizacje...

w tym konkretnym przypadku ICC wypada lepiej, ponieważ automatycznie
wykrywa typową konstrukcję mnożenia macierzy i używa dedykowanych
instrukcji procesora, w miejsce "ręcznych pętli". GCC tego nie robi. też
się kiedyś natknąłem na ten konkretny przypadek.

-- 
pozdrawiam serdecznie / best regards,
bartek szurgot
/* http://www.baszerr.eu */

Dnia Sat, 29 Sep 2012 12:21:56 +0200, Adam Majewski napisal:

> W książce rogramowanie w Linuksie. Ćwiczenia
> Autorzy: Katarzyna Kuźniar, Kazimierz Lal, Tomasz Rak

Trochę OT, ale mam niejasne przeczucie, że kiedyś książki
na te tematy pisali znani specjaliści, a dzisiaj niektórzy 
wykładowcy przepisują wybrakłe skrypty do książek dodając
od siebie parę błędów.

Sam przynajmniej się naciąłem kupując dwie książki na jeden
temat, po czym się okazało, że ktoś z kogoś zrobił plagiat,
prawdopodobnie autorzy obu z trzeciej. True story.

-- 
Edek

Dnia 29.09.2012 Adam Majewski <adammaj1@o2.pl> napisał/a:
> Można pobrać przykładowy rozdział w pdf i tam jest ten przykład.
> Dla gcc czas = 1345 ms
> dla icc czas =  109 ms
>
> Czyli program skompilowany przez icc wykonywany jest 12 razy szybciej.
>
> Co o tym sądzicie ?

Kompilator Intela testowany na procesorze AMD :D
Nie mam procesora AMD, ale ustawienia kompilatora GCC
dużo zmieniają :D
Przykład ode mnie (wersja bez OpenMP) na procesorze Intel Q9550
(Core 2 Quad, 2.83GHz, 8G RAM, Debian 32-bitowy z kernelem 2.6.32)

$ gcc --version
gcc (Debian 4.4.5-8) 4.4.5

$ gcc tablice.c -o tablice
$ ./tablice 500 500 500
arg[0] = 500
arg[1] = 500
arg[2] = 500
Start
Czas: 1158 milisekund

$ gcc -O3 tablice.c -o tablice
$ ./tablice 500 500 500
arg[0] = 500
arg[1] = 500
arg[2] = 500
Start
Czas: 350 milisekund

Jedna opcja dodana do kompilatora wiele zmienia, pewnie jakbym
potuningował dokładniej, to dałoby się uzyskać coś więcej.
Dodatkowo widać, że autor programu się nie popisał znajomością
działania pamięci i sposobu w jaki kompilator C zamienia "wskaźnik
do wskaźnika" na odwołanie do tablicy dwuwymiarowej. Wystarczy
macierz 'b' trzymać w pamięci w postaci transponowanej a wtedy
w samym mnożeniu można zamienić kolejność indeksów, linia 59
będzie wtedy wyglądała tak (zamienione indeksy przy b[][]):
c[i][j] += a[i][k]*b[j][k];
i dostajemy:

$ gcc -O3 tablice.c -o tablice
$ ./tablice 500 500 500
arg[0] = 500
arg[1] = 500
arg[2] = 500
Start
Czas: 274 milisekund

Żaden kompilator nie zastąpi myślenia :D

Dnia 08.10.2012 Baranosiu <rad_n@wp.pl> napisał/a:
> Dnia 29.09.2012 Adam Majewski <adammaj1@o2.pl> napisał/a:
>> Można pobrać przykładowy rozdział w pdf i tam jest ten przykład.
>> Dla gcc czas = 1345 ms
>> dla icc czas =  109 ms
>>
>> Czyli program skompilowany przez icc wykonywany jest 12 razy szybciej.
>>
>> Co o tym sądzicie ?
>
> Kompilator Intela testowany na procesorze AMD :D
> Nie mam procesora AMD, ale ustawienia kompilatora GCC
> dużo zmieniają :D
> Przykład ode mnie (wersja bez OpenMP) na procesorze Intel Q9550
> (Core 2 Quad, 2.83GHz, 8G RAM, Debian 32-bitowy z kernelem 2.6.32)
>
> $ gcc --version
> gcc (Debian 4.4.5-8) 4.4.5
>
> $ gcc tablice.c -o tablice
> $ ./tablice 500 500 500
> arg[0] = 500
> arg[1] = 500
> arg[2] = 500
> Start
> Czas: 1158 milisekund
>
> $ gcc -O3 tablice.c -o tablice
> $ ./tablice 500 500 500
> arg[0] = 500
> arg[1] = 500
> arg[2] = 500
> Start
> Czas: 350 milisekund
>
> Jedna opcja dodana do kompilatora wiele zmienia, pewnie jakbym
> potuningował dokładniej, to dałoby się uzyskać coś więcej.
> Dodatkowo widać, że autor programu się nie popisał znajomością
> działania pamięci i sposobu w jaki kompilator C zamienia "wskaźnik
> do wskaźnika" na odwołanie do tablicy dwuwymiarowej. Wystarczy
> macierz 'b' trzymać w pamięci w postaci transponowanej a wtedy
> w samym mnożeniu można zamienić kolejność indeksów, linia 59
> będzie wtedy wyglądała tak (zamienione indeksy przy b[][]):
> c[i][j] += a[i][k]*b[j][k];
> i dostajemy:
>
> $ gcc -O3 tablice.c -o tablice
> $ ./tablice 500 500 500
> arg[0] = 500
> arg[1] = 500
> arg[2] = 500
> Start
> Czas: 274 milisekund
>
> Żaden kompilator nie zastąpi myślenia :D

I jeszcze jedna szybka poprawka, jeśli zamienimy w tej linii
59 odwołanie c[i][j] na zmienną tymczasową, to wtedy fragment
mnożenia (linie 56-62) wyglądają tak:

 int tym;
 for(i=0;i<w[0];i++){
   for(j=0;j<w[2];j++) {
     tym=0;
     for(k=0;k<w[1];k++) {
       tym += a[i][k]*b[j][k];
     }
     c[i][j]=tym;
   }
 }

Dokładając do tego wsparcie SSE4.1 (które akurat w moim procku jest)
dostajemy:

$ gcc -O3 -msse4.1 tablice.c -o tablice
$ ./tablice 500 500 500
arg[0] = 500
arg[1] = 500
arg[2] = 500
Start
Czas: 63 milisekund

Dalej już nie będę kombinował :D

On 2012-10-08, Baranosiu <rad_n@wp.pl> wrote:
> Żaden kompilator nie zastąpi myślenia :D

Przy sporze o to który samochód może pojechać szybciej
z 4 osobami i bagażami w środku też można powiedzieć, że
mój - przecież bez tych 4 osób jest najszybszy...


Wracając do tematu - jako sysadmin widzę jak sobie radzą koledzy 
opiekujący się aplikacjami. Jest to zwykle soft do obliczeń naukowych.
Czasem napisany z mocnymi optymalizacjami a czasem tak, że pierwszy
lepszy student informatyki napisałby lepszy kod. Całość to głównie C/C++
ze sporą ilością Fortrana.

O ile jeszcze 2-3 lata temu chłopakom udawało się wyciągnąć 10-20%
używając icc to w tej chwili gcc i icc idą łeb w łeb z lekkim przechyłem
w stronę gcc. To się ładnie koreluje z faktem, że 2-3 lata temu
kupiliśmy nowe procesory intela. Pewnie jakbyśmy teraz kupili coś
świeżego na rynku to znowu icc "dostałoby kopa".

-- 
Pozdrawiam
orcus

Dnia 08.10.2012 orcus@pwr.wroc.pl <orcus@pwr.wroc.pl> napisał/a:
> On 2012-10-08, Baranosiu <rad_n@wp.pl> wrote:
>> Żaden kompilator nie zastąpi myślenia :D
>
> Przy sporze o to który samochód może pojechać szybciej
> z 4 osobami i bagażami w środku też można powiedzieć, że
> mój - przecież bez tych 4 osób jest najszybszy...

Samochód może i jest nieco szybszy, ale to w jakim czasie pokonasz
trasę od punktu A do pnktu B zależy też od kierowcy :D

Co do mojego posta: od kilku lat nie używam icc i nie wiem jak on się
ma teraz do gcc, ale nigdy różnica nie była aż 12-krotna :D Autorzy
chyba "na szybko" pisali ten kod w książce (swoją drogą ja bym się
nawet wstydził opublikowac kod z takim formatowaniem :D) i trafił się
przypadek, w którym wyjątkowo icc sobie poradził kilkunastokrotnie
lepiej, więc odpisałem autorowi pytania, że "diabeł" tkwi w samym
indeksowaniu. Gdyby to były tablice zadeklarowane jako c[500][500] i
b[500][500] to szło by jak burza bo wyliczenie adresu elementu jest
proste, a skoro tablice są zadeklarowane jako **b i **c i potem
"ręcznie" są alokowane miejsca dla każdego wiersza z osobna, to te
wiersze nie muszą leżeć w pamięci "jeden za drugim", więc wyliczenie
adresu elementu przestaje być prostym mnożeniem i dodawaniem, tylko
trzeba "pobiegać" po pamięci. GCC akurat jest tak napisany, że
optymalizator lepiej sobie radzi, jeśli wewnątrz pętli zmienia się
ostatni indeks, bo wtedy nie trzeba za każdym razem wyliczać początku
wiersza (choć mógłby też zauważyć, że wyrażenie c[i][j] wewnątrz
najbardziej zagnieżdżonej pętli wskazuje zawsze na ten sam element i
nie trzeba go za każdym razem wyliczać, ale jak się okazuje, przy
niewielkim nakładzie pracy można "nieznacznie" pomóc kompilatorowi i
przyspieszyć kod nawet kilkunastokrotnie :D).

Dnia Mon, 08 Oct 2012 16:59:51 +0000, orcus napisal:

> Wracając do tematu - jako sysadmin widzę jak sobie radzą koledzy
> opiekujący się aplikacjami. Jest to zwykle soft do obliczeń naukowych.
> Czasem napisany z mocnymi optymalizacjami a czasem tak, że pierwszy lepszy
> student informatyki napisałby lepszy kod. Całość to głównie C/C++
> ze sporą ilością Fortrana.

Część studentów _po_ informatyce to nie wiedziałaby, że jest taki nowy
samochód na rynku co nazywa się Fortran.

> O ile jeszcze 2-3 lata temu chłopakom udawało się wyciągnąć 10-20%
> używając icc to w tej chwili gcc i icc idą łeb w łeb z lekkim przechyłem w
> stronę gcc. To się ładnie koreluje z faktem, że 2-3 lata temu kupiliśmy
> nowe procesory intela. Pewnie jakbyśmy teraz kupili coś świeżego na rynku
> to znowu icc "dostałoby kopa".

Gcc dostaje info i od AMD i od Intela, AMD to miało nawet zaimplementowane 
przyszłe procesory w jednej z wersji gcc. Co nie znaczy, że icc na nowych
by nie było lepsze.

-- 
Edek

http://www.phoronix.com/scan.php?page=article&item=linux_compiler_deathmatch&num=1