GCC bude automaticky paralelizovat

Zkoušel jsem hledat pojem "paralelizace" ve slovníčku pojmů (tady na Rootu) a nenašel:-(

V podstatě jde o to, že kromně už tak zbugovanýho kódu, co GCC už tak produkuje, bude bugovat ještě víc a to na více CPU najednou :) Už se těším, jak rozloží algoritmy na paralelní.... Přibude další "must use" volba --disable :D

R.

Můžete uvést nějaký (jednoduchý) příklad toho zbugovaného kódu vyprodukovaného GCC?

Jen co nekde najde ten vnitropodnikovy obeznik z Reedmondu ...

Redmondu, samozrejme ...

jaktoze mas porad auru 71?

???
PS: asi jsem dobre zaplatil...

Mno když nejaka lamka zapina optimalizaci kodu, tak se pak nemuze divit, ze to generuje zbugovanej kod :-D (btw to dela i VS)

jo, obcas se stava napr. to, ze gcc nedogeneruje funkce a podobne. Bohuzel pro lidi bez dostatecnych znalosti v oblasti prekladacu se to muze jevit jako bug a pak zacnou rvat kolem sebe, ze gcc je nahouby.

Kazdy prekladac ma sve bugy, nejen gcc. Ale rekl bych ze MSCC je pri optimalizovanem kodu mirne stabilnejsi, hlavne pri okrajovych volbach typu optimalizace na rychlost/velikost ma gcc tendenci produkovat nefunkcni strojovy kod. Ale nerek bych ze GCC je na houby, v podstate je docela jedno ktery C++ prekladac pouzijete, na neco temer urcite narazite, pokud je to trochu vetsi/komplexnejsi kod. (i kdyz neni toho moc, odhadem bych rekl ze tak pod 0.5% bugu se ukaze jako chyba kompilace, vetsina je na strane zdrojaku)

"VS generuje rychlejsi kod" s novejsim 4.x gcc uz to nemusi byt tak pravidelne, kdyz uz z gcc vyleze neco funkcniho, tak to ma obcas lepsi vykon nez MSCC, nektere veci se povedou gcc zkompilovat lip. A taky zalezi na konkretnim CPU. Ale proste automaticky predpokladat ze MSCC v release udela rychlejsi binarku nez gcc uz nejde, pokud cloveku chybi i opravdu poslednich par procent vykonu, tak je nutne zkusit oboji a merit, merit, merit.
Hlavne VS6 (C++) bylo opravdu hodne stabilni, jenom obcas se sesype cely kompilator kdyz je .cpp moc velky/slozity nebo ma spoustu vnitrnich cyklu v jedne funkci, ale kdyz prezije bez padu, tak vysledni kod byl snad pokazde co pamatuji spravny. Novejsi MSCC jsem uz tolik nepouzival, nemam dost zkusenosti na hodnoceni. Ale problemy s neaktualnimi predkompilovanymi hlavickami byly obcas i u VS6, v pripade podivneho chovani bylo "Rebuild All" prvnim krokem lazeni.

"nedogeneruje funkce"
WTF?!

No rekl bych ze vsechny nebo alespon vyssi stupne (od O3 jsem si na 99% jisty, ale jsem liny si to overit) optimalizace v gcc jsou salamounsky v dokumentaci oznacene jako experimentalni, takze svym zpusobem je v poradku kdyz to nefunguje, experiment se proste nepovedl.
Ale z pohledu uzivatele ktery si kompiluje nejaky projekt do release verze mi to prijde jako spatny vtip.

sak vpoho..

Mno když nejaka lamka zapina optimalizaci kodu, tak se pak nemuze divit, ze to generuje zbugovanej kod :-D (btw to dela i VS)

Kompilátor, který při zapnuté optimalizaci je chybný a chybně pracující kompilátor. Dobře pracující kompilátor nesmí generovat chybný kód při zapnuté optimalizaci.

Z mých zkušeností je -O2 v GCC bezpečné, -O3 v GCC 3 ne (blbne -frename-registers, v GCC 4 jsem nezkoušel)

Odpověď jsem našel v devátém výsledku hledání fráze "paralelizace cyklu".

Takže paralelizace cyklu znamená jeho rozdělení na části které mohou být u víceprocesorového systému provedené na více procesorech a tím pádem rychleji.

Jedná se o paralelizaci kompilace nebo následného provádění kódu?

nasledneho provadeni kodu.... paralelizaci kompilace uz muzete zkusit dnes parametrem -jx u prikazu make, kde x je pocet jader + 1

S tím už ale programátor, co dělá s vláknama, bude muset počítat a volby podle toho upravit.
Defaultně to imho právě kvůli tomuto nebude.

Ne, tohle opravdu nema nic spolecneho s vlakny. Jediny problem, ktery muze realne vzniknout je snizeni vykonu dusledkem cache ping-pongu.

Samozřejmě může jít i o vlákna. Nevím, jak přesně to má Graphite implementované, ale autoparalelizaci lze dělat i ve vláknech (a podle nástinu, že to bude používat OpenMP, na Wiki GCC bych řekl, že i dělá).

Ano, může, ale tak, aby to ten program pokud možno nepoznal.

Konkrétně jaké zajímavé situace by mohly vzniknout?

No ona paralelizacia buildovacieho procesu prepinacom -jx nieje zase az taka super vec. Clovek si pri pisani makefile musi davat pozor na zopar veci. Inak mu make v najlepsom pripade skonci s chybou. V tom horsom vypluje chybny kod.

Tohle ale dělá paralelizaci na úrovni Makefile (spustí se několik gcc s různými zdrojáky), ne na úrovni gcc (a jednoho zdrojáku).

Já bych to trochu upřesnil:
Graphite nemá dělat jen autoparalelizace, ale všemožné HL transformace smyček - štěpení, fúzi, záměnu pořadí, peeling, unswitching atd., takže se bezpochyby jedná o užitečnou věc. Podobné věci dělají například Intelské překladače. Autoparalelizaci moc nevěřím, a mám s ní bídné zkušenosti. On programátor má většinou lepší povědomí o tom, které smyčky za to stojí.

Vetsina programatoru ani nevi, jak se multithreading pouziva :(.

To jsou lepici kodu, ty se nepocitaj. Je jich teda velka vetsina, ale nema vyznam kvuli nim neco delat na toolsech, at jim das cokoli, tak to urcite znasilni takovym zpusobem, ze cloveku zustava nad tim hlava stat.