Vlákno názorů k článku
Překladač C pod BSD licencí nyní v NetBSD a OpenBSD
od Lukáš Turek - Důležité není ani tak jak rychlý je kompilátor,...
-
Lukáš TurekStříbrný podporovatelDů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. -
Clock (neregistrovaný)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 :) -
TomBA (neregistrovaný)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. -
TomBA (neregistrovaný)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). -
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. :)
