Kompilace Qt pomocí Clang (diskuse)

[Limoto]

Taky to porovnávají se starým GCC na Linuxu a s historickým na OS X...

[David Watzke]

U GCC lze v novějších verzích očekávat zlepšení, takže by to podle mě výsledek stejně moc nezměnilo...

[Limoto]

No, třeba ta velikost binárek na OS X by s tím IMHO souviset mohla.

[Vykook]

Mozna to je tim, ze za clangem stoji Apple a pro nej rozhodne linux neni prioritou...

[Ondrej 'SanTiago' Zajicek]

Co jsem slysel, tak Apple dodava historickou verzi spolu s OS X, protoze nema rad GPLv3, pod kterou jsou novejsi verze.

[Boris Dušek]

Ano, u LLVM reimplementace standardní C++ knihovny je to dokonce explicitně zmíněné ("Why a new...", druhý bod).

[Ondroid]

IMHO rozdíly v rychlosti kompilace mezi kompilátory jsou docela nepodstatný parametr. Důležitější je kvalita kódu co z toho vyleze.

[zoul]

Pro zaverecny build mozna, ale ty bys nechtel, aby ti to behem vyvoje prekladalo co nejrychleji?

[andree]

ked zrusis optimalizacie a mozno dalsie veci, tipol by som ze potom aj gcc bude celkom rychlo kompilovat...

[vencas]

Bohužel ne vždy; pokud je v kódu hodně šablon, je clang++ několikrát rychlejší (než g++) i bez optimalizací.

[chrono]

Gcc 4.5 je pri veľkom počte šablón rýchlejšie ako staršie verzie.

[vencas]

To je pravda, ale ne o moc. Sice říkali, že míst O(n^2) to teď je O(n), ale clang++ stejně nedotahuje; nevím ale jestli je to jen šablonami, možná to zpomaluje něco jiného.

[chrono]

Niektoré optimalizácie v gcc potrebujú veľa času a pamäte. Je veľmi pravdepodobné, že pri zakázaní niektorých optimalizácií by gcc kompilovalo výrazne rýchlejšie pri menšej spotrebe pamäte a rýchlosť a veľkosť výsledného programu/knižnice by bola stále porovnateľná s clang. (ale netuším, či je niekde kvalitný popis parametrov pre optimalizáciu aj s tým, ako veľmi ovplyvňujú spotrebu pamäte a záťaž CPU)

[Saljack]

Vysvětlí mi někdo, proč se v poslední době všichni snaží všechno zkompilovat Clang?

[Limoto]

Protože (není) GPL...

[David Watzke]

No, on je v některých směrech lepší než GCC, třeba chybový hlášky (jako chyby v kódu). Ale teď jak se na to tak koukám, přijde mi to ještě dost mladý a pekelně zabugovaný. Uvidíme jestli a kdy to překoná GCC ve všech směrech.

[zoul]

Zas tak pekelne zabugovany byt nemuze, uz ho nejakou dobu pouzivam jako produkcni prekladac Objective-C a Apple ho pouziva v Xcode 4, ktere by mely kazdou chvilku vyjit.

[vencas]

Protože c++ program na kterém pracuju zkompiluje 4x rychleji (nepřeháním) a spotřebuje na to 2x méně RAM (4 jádra, 12GB RAM, gcc potřebuje 4GB/proces, takže nemůžu využít všechna jádra). Když si chci pustit skutečný výpočet, překompiluju gcc, přitom si vyřídím maily, a pustím.

[Bilbo]

4 GB/proces? Co to je za zdrojáky? Já osobně jsem se zatím dostal max tak na cca 350 MB (ve chvíli kdy jsem includnul CImg, což je 2 MB header plný templatových funkcí), na "běžných" zdrojácích tak 100 až 200 MB

[vencas]

https://launchpad.net/yade -- v deklaraci každé třídy desítky atributů přes makra, která vytvářejí kód pro ukrutné šablony schované v boost::python a boost::serialization. Souborů se kompiluje dohromady (kvůli velikosti binárky a rychlosti) třeba 20, takže to opravdu dává necelých 4GB/proces.

Vím že by se to dalo udělat aby to RAM žralo méně (třeba dát implementace boost::serialization a boost::python do .cpp místo .hpp), ale tím by se muselo mnoho dat duplikovat, zatímco záměr byl přesně opačný; ukázka zdrojáku.

[Ivan]

jj, mam podobnou zkousenost s boost::spirit. gcc ma nekdy exponencialni pametovy a casovy naroky kdyz to kompiluje. Takze a = b | c | d; Zkompilovat jde. Ale a = b | c | d | e; uz vyzaduje 4GB RAM na kompilaci.

Ivan

[Bedňa]

NOGPL a pružný vývoj.

[JoHnY2]

Na Linuxu jsou release binarky o 5% vetsi a predbezne o 16% pomalejsi proti GCC 4.4.3, to mi na C++ kompilator ve stavu alfa verze prijde jako malej zazrak.