gcc & icc (diskuse)

[ajikdpoe]

Rozumiem tomu dobre ze gcc produkuje rychlejsi kod?

[miro]

To som z toho jelen, u seba som dostal podobne vysledky. Pred dvoma rokmi som si napisal nejaky benchmark (gaussova eliminacna metoda : par vnorenych cyklov...) Este pred rokom v nom gcc dopadlo mizerne (vyse 2x pomalsie nez icc), dnes je to tesna vyhra gcc.

Inak, na optimalizacie fibonacciho u mna vyhrala java.

Moje vysledky:

gcc -O3: 5.62s
icc -O3: 6.07s
java:    5.34s

Paralelizacia icc u mna bola viacmenej bez vysledkov na vykon (vramci statistickej chyby...)

icc -O3 -parallel -axT -xO          : 5.99s
icc -O3 -parallel -openmp -axT -xO  : 6.03s

[miro]

Pardon, miesal som hrusky s jablkami :-O

Java nebola rychlejsia ako gcc, vysledky gcc a icc ktore som uviedol sa tykaju gaussa, vysledky za javu sa tykaju fibonacciho.

Tu je to opravene: (vysledky pre fibonacciho)

gcc -O3: 3.18s
icc -O3: 6.68s
java:    5.34s

[deda.jabko]

to s tou javou radsi nerikejte nahlas... ;-] nebo to skonci jako obvykle... nehezkym flamem ;-]

[miro]

No ved som to rychlo opravil, chybicka se vloudila gcc je v konkretnom pripade fibonacciho o nieco rychlejsie. Ale ze je uz java pekne rychla, to je fakt. Numericku diplomku som pocital v jave, vo velkej miere v nej vyuzivam collections. Nedavno som skusal optimalizovat (uz ajtak celkom svizne beziaci kod), pustil som to so zapnutym Java Hot Spot a to bola parada. Kedze cely vypocet trva radovo hodiny a pusta sa vo velkom cykle jeden kod dookola, nejakych par sekund navyse pocas prveho cyklu sa oplatilo (u mna patnasobne zrychlenie kodu). Jeden chalan pred dvoma rokmi pocital podobne veci ako ja, robil to cele v C++, vypocet mu bezal radovo dni (5-6 dni)
Trosku som upravil algoritmus, pouzil som javu (ta ale asi nemala taky vplyv, akurat sa mi v nej lepsie pise) a dal som to na tri-styri hodiny. A teraz som zistil, ze so zapnutym hot-spot to dam pod hodinu. Parada.

[jan.xxx]

Link na diplomku by nebyl???

[miro]

Zdrojaky programu som nedaval nikam, ale casti kodu tykajuce sa prace s riedkou maticou a so sietou sa chystam spristupnit. Robil som nadstavbu nad software ANGENER, v priebehu mesiaca sa mozno po dohode s doc. Dolejsim na jeho stranke objavi odkaz na moju kniznicu. Potom dam vediet.

Samotna diplomka (pdfko) bude na nete, vecer hodim link.

[miro]

Diplomka je uz na nete, ak mas stale zaujem.

[jan.xxx]

Díky. No a kdyby nakonec byl i ten program či knihovna, tak se určitě poděl

[aa]

Ja mam tedy zkusenosti opacne. Prubezne pouzivam na preklad g95 a ifc na ulohy, jako je treba kombinatorika pocitana pres geneticke algoritmy s minimalizaci slozite funkce, vypocty numerickych integralu s minimalizaci a zpracovani velkeho mnozstvi merenych dat a vysledkem je jednoznacne vetsi rychlost ifc. V zavislosti na konstelaci hvezd i treba 5x.

Vsiml jsem si, ze ale vysledky hodne zalezi na procesorove sade. Totiz ifc si sam voli ten procesor na kterem jede, kdezdo g95 (vsechny prekladace od gnu) voli defaultne i386 komaptibilitu. Ale ani kdyz se rucne nastavi g95 konkretni procesor, tak je to porad tak o 20-30% pomalejsi.

Proste tady ma ifc navrh protoze neni multiplatformi jako gcc a navic "lip vi, jak tam ti brouci behaji". U gnu prekladacu je to dan za neuveritelnou prenositelnost.

[luky]

Nevim jestli jste studoval fungovani gcc (a prekladacu obecne) ale ta dan za prenositelnost se tady prakticky nekona. Vynechame vareni z vody ;)

[Miloslav Ponkrác]

A je tu základní problém:

1) Optimalizace mikroskopického malého kousku programu o kvalitách optimalizátoru moc neřekne - dnešní kompilátory jsou dost dobré na to, aby se to na pár řádkách kódu projevilo. Tudíž právě proto se dne optimalizuje testuje na velkých reálných programech.

2) Intel kompilátory jsou velmi citlivé na parametry překladu, tedy na parametry příkazové řádky - výsledek se brutálně liší i maličkými změnami parametrů. Prostě buď překládáte rychle, nebo optimálně, zvolíte si procesor i řadu optimalizací přímo na příkazové řádce. Pokud chce někdo testovat kompilátory, měl by si s nastavením parametrů kompilace dát přeci jenom trochu práci.

Já už testy několikařádkových programů a jejich rychlost neberu za seriózní test.

[deda.jabko]

1) zkousel jsem to i na jinych aplikacich a vysledek nebyl taky zrovna oslnivy, vetsinou gcc a icc podavali velice podobne vysledky...

2) muzete mi ty parametry poradit? zkousel jsem navic -mtune i nektere dalsi volby, ale bez zadneho relevantniho zlepseni.

3) toto se nesnazi byt serioznim testem, jenom poukazuje na to, ze neni vsechno zlato co se trpiti. btw. jaky test povazujete za seriozni...

4) pokud delate test na necem vetsim, je problem oprostit se od vlivu vnejsiho prostredi -- vliv vstupnich dat, vliv beziciho systemu, vliv cekani na jine udalosti (napr. db, filesystem), atp. takze napsat nenapadnutelny test je nerealne. presto budu rad, kdyz nejaky navrhnete a provedete. btw. pokud resite ulohy opravdu narocne na vypocet, je optimalizace i takto malych kodu vysoce relevantni.

5) osobne me slo hlavne o tu paralelizaci... ten zbytek je jenom vedlejsi produkt...

[Miloslav Ponkrác]

No když poukazujete, že není všechno zlato, co se třpytí, tak musíte u toho taky trochu přemýšlet. Jinak dojdete k hovadinám, jako se Vám právě povedlo.

Paralelizace, o kterou Vám šlo má dvě stránky - jednak urychlení výpočtu paralelním prováděním a naproti tomu jsou tu náklady - režie na paralelní běh. Je jasné, že čím kratší kód vyzkoušíte, tím více se projeví hlavně ty náklady a ta režie (tedy cena za paralelizaci), tedy paralelizace nemá šanci ukázat co v ní skutečně je.

[deda.jabko]

prominte, ale hovadiny (s prominutim) pisete vy nebo mate problemy s interpretaci textu a vysledku, viz:

icc -O3 -ipo fib.c	        14.640s
icc -O3 -ipo -parallel fib.c	8.935s

je zrychleni o cca 40%, coz je na dvoujadrovem procesoru na hranici praktickych moznosti (kvuli rezii hardwaru i softwaru). a proto pisi: ,,ta paralelizace ma docela hezke vysledky''

v dalsim testu jsem se ji pokusil rozhodit side-effecty, aby se ukazalo, jak to zvladne... a s tim uz si nedokazal poradit, ale to neni rezie -- jinak by to nefungovalo ani v prvnim pripade... navic je zrejme, ze icc zvlada jen paralelizaci smycek a ne volani.

[ondracch]

A jaká byla velikost binárek u jednotlivých překladačů?

[deda.jabko]

tuto hodnotu jiz dneska neberu jako relevantni... (jelikoz nemam vlastni distribuci, kterou bych rval na cd/dvd/net, aby me to zajimalo) a hlavne u tak malych programu se projevi vliv kodu, ktery tam ,,musi byt vzdycky'' -- ale jinak to je gcc -O3: 7487B a icc -O3 -ipo: 19927B

[Jirka P]

No jo, intel nějak nezvlád tu téměř tail-rekurzi. Když jsem to přepsal na

int fib1(int x, int i)
{
        if (i <= 2) return x+1;
        return fib1(fib1(x, i - 2), i - 1);
}

tak jsem dostal +- stejný výkon od gcc i icc (= stejný jako gcc a původní program).

MMCH, kdo dokáže říct co ten asm pro původní program skompilovaný gcc dělá, je fakt dobrej.

[deda.jabko]

pokud gcc dokaze odhalit i neco takoveho, tak je to velky bod pro nej...

[kaaja]

Moc se nedivte, že paraelizace nepomohla. Protože program, který se snažíte paraelizovat neobsahuje žádný dobrý paraelizovatelný cyklus. Vyzkoušel bych napsat kód který by násobil velké matice. Tam by to při paraelizaci mělo být znát.

[deda.jabko]

program obsahuje dobre paralelizovatelny cyklus... v prvnim pripade, zvladl zlepsi rychlost o nejakych 40%, coz se velice blizi praktickym limitum. problem je, ze se ta paralelizace da velice snadno rozhodit side-effectama... (coz me potesilo, protoze muj paralelizujici interpreter schemu se s tim vyrovnal bez vetsich ztrat ;-])

[Jirka P]

muj paralelizujici interpreter schemu se s tim vyrovnal bez vetsich ztrat

Smím se zeptat jak? Spoolujete ty side-effecty a třídíte podle času, kdy měly nastat? Nebo je jen vykonáte v nějakém pořadí a tím změníte sémantiku programu? Co děláte, když např. čtete hodnotu, která teprve bude zapsána?

[deda.jabko]

vyuzivam funkcionalniho charakteru schemu, kde jde velice snadno urcit poradi a zavislost jednotlivych operaci na case, takze jde zachovat semantika u side effectu a tim eliminovat spousta patologickych jevu, napr. zminene cteni hodnot pred jejich zapsanim... a paralelizovat jenom potencialne zajimave casti kodu...

o par blogspotu najdete i jednu ze starsich verzi intepretru, bohuzel text kde popisuju jak to funguje, me bylo doporuceno stahnout... :-/

[Jirka P]

Našel jsem toto, ale z toho mi vyplývá, že u side-effectů vpodstatě zastavíte vykonávání, což moc paralelní není... to co se píše v tom odkazu už neplatí?

[deda.jabko]

jj, ten kod je trochu starsi verze a v nekterych vecech jsem dnes o neco chytrejsi ;-]

s tim zastavenim vykonavani je to trochu slozitejsi... jedine operace, ktere je potreba synchronizovat jsou prave ty s vedlejsimi efekty -- ostatni operace jsou na sobe nezavisle a tudiz interpreter muze pokracovat libovolnou casti redukcniho stromu, ktera tim neni ovlivnena... takze i kdyz treba ceka na provedeni I/O operace, muze resit ulohy, ktere budou nasledovat...

[Michal]

Nechte me hadat- stejne to je drtive pomalejsi nez C ekvivalent

[deda.jabko]

jo, jasne, ja to taky nezatajuji... ono to plyne uz z podstaty, ze je to interpreter... ;-] na druhou stranu se s nimi da vyrazne lepe pracovat -- zavadet nove prvky, zkouset ruzne pristupy, atp. a to nemluvim o portabilite....

[kaaja]

Omlouvám se, máte pravdu. Ještě mě napadla jedna věc. Když jsem naposledy psal něco paraelniho (už je to par let) tak bylo potřeba před spuštění programu nastavit nějakou proměnnou prostředí, která určovala kolik paraelnich thredu použít. Bohužel to bylo na Sunu a SGI a stejně si ji nepamatuji. Ale pro OpenMP jsem našel, že existuje OMP_NUM_THREADS.

[miro]

OpenMP: v pripade icc a nenastavenia premennej OMP_NUM_THREADS sa uvazuje pocet procesorov (jadier) v systeme. Trochu som s tym experimentoval, ale asi nepisem pre paralelizaciu spravny kod, pretoze zlepsenie vysledkov sa nedostavilo

[Michal Vyskočil]

Já osobně jsem měl dojem, že je icc lepší hlavně v případě optimalizace C++ kódu . Pro C je gcc šikovné už teď. Ohledně C++ začalo být použitelné teprve od čtyřkové větve.

Možná by to chtělo vzít několik velkých projektů (třeba zaměřených na numerické výpočty) a pustit testy na nich.

[miho]

nbench 2.2.2, kod v C, testuje razeni ciselne a retezcove, operace nad bitovymi poli, FFT, huffman, sifru idea, neutonovou sit...

gcc -march=nocona -O3

MEMORY INDEX        : 27.356
INTEGER INDEX       : 25.623
FLOATING-POINT INDEX: 42.247

icc -O3 -axT -xT

MEMORY INDEX        : 22.976
INTEGER INDEX       : 32.503
FLOATING-POINT INDEX: 78.696

icc -O3 -axT -xT -parallel

MEMORY INDEX        : 23.318
INTEGER INDEX       : 32.532
FLOATING-POINT INDEX: 78.393

-ipo vykon vyrazne snizilo...

Prevaha icc v necelociselnych vypoctech je brutalni.

[deda.jabko]

tak i v tomto pripade je gcc velice dustojny souper

[luky]

Je pravda, ze spousta veci by se dala vylepsit a nektere techniky v gcc uplne chybi. Take je pravda, ze pro cloveka, ktery problematice rozumi, jsou nedostatky opravdu hodne protivne. Ale vyraz "mizerne optimalizujici" u gcc rozhodne neni na miste.

Pokud jde o zapisek konkretne, tak nevypovida vubec o nicem.