Překladač C pod BSD licencí nyní v NetBSD a OpenBSD

Důležité není ani tak jak rychlý je kompilátor, ale jak rychlý je kód který produkuje. Až tam přidají podporu pro víc architektur (a tedy pořádně oddělení frontendu a backendu) a složitější optimalizace, budou na tom stejně jako GCC.

Nemate pravdu ... pri vyvoji aplikaci by casto rychly kompilator usetril slusnou porci nakladu. Samozrejme pro finalni produkt by bylo idealni kdyby dosahl takove urovne kompatibility, ze se pak jednoduse vymeni PCC za GCC/MSCC a udela se finalni binarka.

Jo, to je fakt, kdyz jsme delali rocnikovy projekt tak kompletni prekompilovani cele aplikace (make clean;make) mohlo trvat az 10 minut. I kdyz porad lepsi nez mamuti veci typu mozilla nebo wine, ty se kompiluji nekdy i pres hodinu ... rychly kompilator by se hodil :)

"nekdy i pres hodinu" :-) ..openoffice 11h, 5GB tmp souborů (Sempron @1,6GHz, 512MB RAM) ..sranda ;-D

On nespominal OpenOffice. A ked sme pri nom - u mna sa kompiloval 3 hodiny (C2D T7400@2.16GHz, 2GB RAM)

neviem co riesite - kompilacia openofficu v ramdisku - 1GB je otazkou par minut (cca 10): procak C2D E6300. Teraz ked ramka stoji par supov a chcete kompilovat velke projekty staci dokupit.

11h OpenOffice? Ronja se kompiluje tejden nebo dva. Tam ale tu hlavni praci nedela gcc, ale rt z BRL-CADu z U. S. Army Research Laboratory, Aberdeen Proving Ground, Maryland. U. S. A.

Jestli to PCC neprodukuje GCC skvosty typu mov eax, ebx; mov eax, ecx tak to by se i celkem hodilo :)

Ako často kompilujes celú aplikáciu?? Asi je ten projekt zle navrhnutý, lebo obyčajne nerobíš zásahy do všetkých častí programu...
Rýchle kompilátory majú za dôsledok, že sa programátori nezamýšľajú nad rozumným členením programu a pre zmenu v jednom riadku často kompilujú celú aplikáciu.

Druhá veta odporuje prvej....
Ak má kompilátor dosiahnuť Vami spomínanú úroveň kompatibility, bude rýchlosť podobná....
Ak má auto premávať po normálnej komunikácii, má používať štandardné palivo, spaľovací motor a má byť bezpečné, nemôže chodiť desaťnásobnou rýchlosťou (ako sa predpokladá v článku).

Ale to je prece naprosto nesmyslny priklad! U auta se daji najit parametry, kdy pri splneni zakladnich podminek (prepravi 1-5 cestujicich po silnici podle predpisu = bude kompatibilni) bude rozdil desetinasobny (napr. spotreba mezi malym autem a nejakou sovetskou limuzinou)

Neodporuje. Uroven kompatibility, t.j. schopnosti prelozit ten isty zdrojovy kod do binarky nijak zasadne nesuvisi s rychlostou kompilacie. S tym suvisi hlavne kvalita vysledneho kodu, ta bude samozrejme niekde uplne inde, malo optimalizovany kod moze byt kludne aj 10x pomalsi ako ten optimalizovany.
Ale pri vyvoji mnohych aplikacii vobec nevadi ak bezi pocas testov 10x pomalsie, ak by sa tym usetrilo kazdy den niekolko hodin na kompilacii.

Len to chce ten spravny kompromis. :)

"Rychle" umí kompilovat i gcc, stačí vypnout optimalizace.

The big benefit of it (apart from that it's BSD licensed, for license geeks :-) is that it is fast, 5-10 times faster than gcc, while still producing reasonable code.

1. malo by to znamenat, ze binarka bude podobne velka a podobne rychla ako binarka, ktora bola skompilovana z tych istych zdrojakov inym kompilatorom.

2. je to stale vo vyvoji, vela veci nefunguje, pockajme si na vysledny projekt

3. myslim, ze cim viac kompilatorov, tym je to len lepsie pre vsetkych, hlavne ked su open source.

Snad už brzo nebudeme závislí na GNU a jejich omezující licenci GPL

V com ta obmedzuje GNU/GPL???

Třeba v nemožnosti použít jej v closed-source programu? Netvrdím že je špatné, že to GPL neumožňuje, ale tvrdím, že je (v tomto směru) omezující.

tak vsichni chytraci by si meli precist diskusi na undeadly.org k tomu kompilatoru, aby vedeli o co jde.