Vlákno názorů ke zprávičce GCC bude automaticky paralelizovat od Karásek - Zkoušel jsem hledat pojem "paralelizace" ve slovníčku pojmů...
-
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) -
anonymník VS od MS. stava sa mi s zeleznou pravidelnostou ze ich inkrementalne skompilovana binarka robi uplne blbosti. Clovek sa divi co mu to z debugera lezie, ked zistuje kde je problem. no jo... zmazat a zbuildovat cele znovu... V starsom vs 6.0 sa mi to nestavalo.
na druhej strane myslim, ze VS generuje rychlejsi kod, C++ builder cca 10x pomalsi ako VS. gc++ este zmeriam. -
"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. -
anonymníMe u MSCC vytacelo, ze hlasi nepodporovane konstrukce jako chybu syntaxe, takze se takova chyba opravdu vyborne hleda... GCC v takovem pripade napise neco jako "sorry, not implemented".
Meril jsem rychlost behu vysledne binarky na jednom nasem pocitacim programu a jak GCC tak ICC udelalo rychlejsi kod (muze byt rozdil i v tom, ze binarku z ICC a GCC jsem poustel na linuxu, kdezto z MSCC ve win). -
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-vectorizeA 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).
