Vlákno názorů ke zprávičce 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.

Co je to "nedogeneruje funkce" -co si mám pod tím představit? Ptám se se seriozně, protože jako člověk neznalý překladačů nechci roztrubovat, že GCC je na houby. :-)

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)

Děkuji za vysvětlení.

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

Nesmysl! Pokud byste nebyl líný napsat "man gcc<enter>/-O3<enter>nnn", dozvěděl byste se:

-O3 Optimize yet more.  -O3 turns on all optimizations specified by -O2
    and also turns on the -finline-functions, -funswitch-loops,
    -fpredictive-commoning, -fgcse-after-reload and -ftree-vectorize

A pokud byste se podíval do zdrojového kódu, zjistil byste, že žádná vyšší optimalizace než -O3 tam není. Uživatel si sice může napsat třeba -O9999, ale stále je to jen (optimize > 2).

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.

Nemusí nutně jít rozdělení na více procesorů, i jeden procesor dokáže rozvětvit kód do více procesů/vláken.