Linux se podařilo zkompilovat Clangem

Linuxové jádro 2.6.36 se podařilo zkompilovat Clangem, frontendem ke LLVM. Muselo se sice trochu podvádět (některé části byly zkompilovány GCC), a to i kvůli použití rozšíření GCC jako pole s proměnnou délkou uvnitř struktur. Vytvořené jádro se podařilo i nabootovat. Více na LWN.

26.10.2010 12:36 | Luboš Doležel (Doli) | Zajímavý projekt

Komentáře

[mikirc]

A k cemu je to dobre?

[Ondřej Profant]

Člověk, který nechce jen rýpat se zeptá: "K čemu je dobrý CLANG?" a bystřejší zjistí, že je to kompilátor, který má některé velmi příjemné vlastnosti. Zvláště pak pro začátečníky (a tím byl každý z nás). No a pak už ví, že je příjemné, že tento kompilátor je použitý i na tak obří a komplikovaný projekt jakým je Linux...

[jehovista]

Mezi slovy pouzity a pouzitelny je docela rozdil. Navic i to slovo pouzitelny by zde melo byt v uvozovkach.

[Bedňa]

e.g. about 3x faster than GCC when compiling Objective-C code in a debug configuration

[R]

To zaujima velmi uzku skupinu ludi. Linuxakov zaujima hlavne C.

[vencas]

C++ je ovšem taky zajímavé. Program na kterém pracuju zkompiluje clang++ 5x rychleji a spotřebuje při tom asi třetinu paměti oproti g++. To je celkem dobré, ne?

A diagnostika chyb v programu, to je nebe a dudy.

[R]

Tak to je velmi slusne. Je pravda, ze v C++ treba to zrychlenie viac ako v C.

[Miloslav Ponkrác]

„Program na kterém pracuju zkompiluje clang++ 5x rychleji a spotřebuje při tom asi třetinu paměti oproti g++.“

Já Vám klidně napíšu kompilátor, který Vám to zkompiluje 30× rychleji a spotřebuje ještě méně paměti.

Hloupí na to naletí, chytří vědí, že čím blbější kompilátor C/C++, tedy čím hůře optimalizuje a čím horší dává kód, tím rychleji a s menším spotřebou paměti kompiluje.

Tudíž, blbější kompilátor dávající horší kód obvykle kompiluje rychle a nenáročně.

Jen hlupák bude hodnotit C/C++ kompilátor předevšěím podle kritérií rychlost překladu a spotřeba paměti. C/C++ se používá právě pro dosažení kvalitního výstupního a efektivního kódu. Pokud nepotřebujete kvalitní stroják, pak je zbytečné používat C/C++ a často dosáhnete rychlejších výsledků s nějakým vyšším jazykem.

Nehledě na to, že rychlost překladu je závislá na přepínačích. Obvykle debug překlad bez optimalizací je mnohem rychlejší, než s optimalizacemi a s předpokompilovanýmií headery pak dále výrazně rychlejší.

Je také dosti pravděpodobné, že rozdíly v rychlosti překladu dvou kompilátorů často také bývají způsobeny nešikovností testujícího, který jeden z kompilátorů špatně nastavil.

[Bedňa]

Ja by som veľmi chcel ten kompilátor čo skompiluje 30x rýchlejšie. Napíšte ho, inak to berem ako blábol. Ja by som ho mal veľmi rád pri vývoji. Potom by som už na to pustil gcc.

[pc2005]

Jj kernel zkompilovaný do jedné minuty bych chtěl taky , ještě bych poprosil o ARM verzi (stačí do budoucna...).

Btw 30x to by snad bylo i rychlejší než TCC :-O.

[Miloslav Ponkrác]

Na oba dotazy:

Můžete to brát jako blábol. Protože napsat rychlé, ale nekvalitní kompilátor chce jen trochu času. Nejvíce času sežere optimalizační jednotka.

Tudíž platí jednoduchá úměra – čím kvalitnější kompilátor a čím efektivnější výstupní strojový kód, tím pomaleji kompiluje.

Kvalitní kompilátory si proto musí pomáhat triky – inkrementální kompilací, inkrementálním linkováním, předkompilovanými hlavičkami a další, aby rychlost byla přijatelná.

Napsat ARM kompilátor bych nechtěl. Instrukční sada ARM je docela jednoduchá, čistá, ale nepříliš vhodná pro kvalitní kompilaci. Není pro mně problém napsat v asm výrazně efektivnější a rychlejší kód pro ARM, než dokáže jakýkoli překladač. Mapování C příkazů a ARM sady není úplně přímé.

Napsat v x86 něco v asm tak, aby to mělo smysl je navýsost těžké. Kompilátory jsou zde většinou velmi kvalitní a C/C++ kompilátory vygenerují velmi efektivní kód.

Snadno to vidíte třeba na rychlosti ARMu na vstupy a výstupy, nebo na přerušení. Žádná sláva.

Navíc ARM nedokáže pracovat s jakoukoli 32bitovou konstantou, a další omezení. Ne, efektivní a optimalizovaný kompilátor C/C++ pro ARM opravdu psát nechci. Ledaže bych dostal velmi dobře zaplaceno.

[pc2005]

Radši pomalej ARM než rychlej x86, kde je málo registrů a dokonce nejdou použít libovolně na libovolnou instrukci.

Rychlost ARMu není moc problematická, kámoš provozuje na BeagleBoardu bez problému Ubuntu.

Jinak moc jsem nepochopil to, že pro architektura, která je složitá, to generuje lepší kód než pro architekturu, která složitá není :-/.

[Miloslav Ponkrác]

Já jsem netvrdil, že rychlost ARMu je problematická.

Jen že napsat optimalizovaný kompilátor pro ARM není sranda.

Psal jste někdy něco v ARM assembleru?

ARM má méně registrů, než x86 v 64 bitovém módu a navíc jsou ty registry dřevěnější.

Zbytek si dostudujte, nebo napiště něco v ARM asm, pochopíte.

ARM je RISC, jinak řečeno, instrukce jsou slabší. Je problém už jen s takovou prkotinou, jako přesunout 32bitovou konstantu do registru. To implikuje řadu nepříjemností nejen ohledně konstant, ale i ohledně adres u pointerů, kde se to různě flikuje a látá. Neexistuje možnost přímé operace s pamětí, musíte to rozložit na tři operace – natáhnout do registru, udělat operaci, uložit do paměti a vzhledem k nemožnosti jakékoli adresy v pointerech často ještě před to další instrukce.

Jinak řečeno, pokud se překládá C do ARM strojáku, kompilátor to musí trochu obcházet, protože některé C příkazy nejsou zcela přímé.

Jako člověk snadno upravím algoritmus tak, aby byl šit na míru ARM možnostem, a pak je asm výrazně lepší, kratší a výkonnější, než cokoli, co kdo honí přes C/C++ kompilátor.

Ovšem v C kódu ty možnosti nejsou, není to tam dost dobře jak zapsat. Algoritmus píšete pro C kód.

Stroják x86 je naprostý luxus. A instrukční sada je poměrně dobře zvolena z hlediska C/C++. Nejsou tam nijak výrazné nerovnoměrnosti, takže příkazy C/C++ poměrně přímo překládáte do x86 strojáku. Jediná starost je využít naplno paralelní zpracování instrukcí a cache.

Snad Vám dřevěnost ARM asm aspoň připomene to, že i Linux měnil binární rozhraní pro volání kernelu pro ARM, protože není snadné najít model, který by byl efektivní.

Rychlost ARMu není kritická, ale jen proto, že ARM má pro většinu aplikací výkonu nazbyt. A jen tam dost velká neefektivita právě obcházení příliš chudých možností ARM instrukcí.

[pc2005]

Nn v ARM assembleru jsem nepsal (nemám vlastní hw), ale za to jsem psal před týdnem něco v čistém x86 (16bit) assembleru a je to hrůza. Vím, že to je redukování velikosti instrukčního slova, ale nutnost používat jen DX a AX pro dělení a násobení je hrůza. Taky je celkem naprd použití pouze CX registru na dekrementační smyčky, zvlášť, když se CX nedá adresovat. Taky třeba řetězcové operace nad pevně danou kombinací registrů. Instrukce OUT a IN jsou pak vtipně omezeny na DX,AX (nebo spíš ). Vzhledem k nemožnosti 8bit přístupu k indexovým registrům pak už moc registrů na práci s daty není .

Pak taky když jsem si před prázdninama hrál a tvořil "parser" strojového kódu, tak se objevovaly takový vtipný věci jako dvojčata nebo i trojčata (různý opkód, stejná funkce).

Stroják x86 je naprostý luxus. A instrukční sada je poměrně dobře zvolena z hlediska C/C++.

To bych bral teda spíš jako nevýhodu .

Snad Vám dřevěnost ARM asm aspoň připomene to, že i Linux měnil binární rozhraní pro volání kernelu pro ARM, protože není snadné najít model, který by byl efektivní.

Jj něco jsem o tom zaslechl...

Rychlost ARMu není kritická, ale jen proto, že ARM má pro většinu aplikací výkonu nazbyt. A jen tam dost velká neefektivita právě obcházení příliš chudých možností ARM instrukcí.

No tak ARM je RISC, pokud je opkód hnusnej, ale aplikace běží rychlejc, tak je to i tak plus. Nehledě na to, že jak jsem psal cokoliv bude IMHO lepší než x86. Jinak instrukce ARMu chudé nejsou, zvlášť když má ARM někde 4 emulační módy (jazelle, thumb atd.).

[Martin Mareš]

Ve 32-bitovém nebo 64-bitovém módu už to zdaleka taková hrůza není (i když pevné parametry instrukcí pro násobení a dělení zůstaly).

Co se smyček týče, zapomeňte na to, že nějaká instrukce loop existuje, stejně se na čemkoliv modernějším nevyplatí.

ARM je samozřejmě daleko elegantnější, ale dnešní implementace x86ky jsou proklatě dobré, takže téměř všechny nevýhody architektury obejdou. Za to se samozřejmě platí mnohem větší komplikovaností a tím pádem i spotřebou procesoru.

[pc2005]

No, tak je pravda, že v 32bit režimu je možný adresovat pomocí ECX, což má ale zase nevýhodu v nutnosti naplnit jí 4 bajty. Taky nechápu proč se nemůže do segmentovejch registrů zapisovat přímo.

Loop není sám, zajímavý je třeba REP, který podle CX opakuje následující instrukci (používá se na kopírování paměť-paměť).

A to je víceméně pořád na úrovni 486. Pak jak se začaly přidávat věci jako MMX, SSE, tak se musely dít věci . Je docela možný, že 64bit je o něco lepší, ale pořád musí být kompatibilní s tou starou architekturou. V případě toho zpětně nekompatibilního módu bych uvažoval spíš o jiné architektuře už.

Jinak ještě k té strojové optimalizaci kódu kompilátorem. Nepoužívá náhodou x86 instrukční sada už někde od P2 překlad na RISC mikrokód? Rozhodně se mě nezdá, že by konverze C→CISC x86→RISC mikrokód byla v principu nějak účinnější než C→RISC ARM.

[Miloslav Ponkrác]

Já bych chtěl jenom říct, že ARM trpí nutností kompatibility daleko víc, než x86.

ARM instrukce jsou šity tak, aby se daly přímo vykonávat pomocí hw. To plodí jednak ta omezení ARM strojáku. A jednak je to koule na noze.

x86 je od začátku dělaná tak, že je to v zásadě virtuální stroj, který emuluje nějakou sadu instrukcí. x86 instrukce se nevykonávají přímo, ale emulují uvnitř cpu. x86 instrukce jsou rozloženy do mikroinstrukcí, které se pochopitelně mohou měnit a zdokonalovat s každým modelem cpu.

Vaše úvahy o účinnosti a efektivitě překladů jsou zkresleny programátorským myšlením. Jakmile si dokážete v mozku představit, že hw umí masívně paralelně dělat mnoho operací najednou, a že překlad instrukcí se děje paralelně a naráz, nikoli sekvenčně jedno po druhé, budete jinde.

A jakmile si ještě přidáte, že každý příkaz C/C++ má svůj téměř přímočarý ekvivalent v x86 sadě. Zatímco některé příkazy C/C++ se prostě přímo do ARM sady přeložit nedají, protože ARM sada pokrývá jen část C/C++, zbytek se musí nahradit delší sekvencí, pak to pochopíte.

Rozdíl mezi x86 a ARM je jednoduchý: ARM přenáší na programátora omezení hw a low level přístup. ARM sada je dělaná tak, aby elektronika byla co nejjednodušší a zákonitě přenáší řadu omezení na asm programátora, či na kompilátor – jinak to nejde.

x86 sada naproti nemá téměř žádný vztah ke skutečné architektuře cpu. x86 cpu si dělá své vlastní vnitřní mikroinstrukce (které jsou tím pádem efektivnější a rychlejší, protože jsou dělány pouze s ohledem na co nejlepší míru architektuře cpu, a asm programátor je nikdy neuvidí, tudíž se nemusí ohýbat = zpomalovat pro něho).

Překladem x86 sady do mikroinstrukcí dosáhnete výhod obojího. Máte příjemný asm pro programátora, zároveň cpu vykonává mikroinstrukce šité mu na míru, a tedy je schopen podat vyšší výkon. Jediné, čím se zato platí je vyšší složitost cpu = vyšší spotřeba.

[Vskutečnosti Saýc]

Pouzivani mikroinstrukci tak jak to dela i386 sice usnadnuje praci tvurcum kompilatoru, ale

1) Ukazuje ubastlenost puvodni i386 instrukcni sady. proc by ji jinak bylo potreba prekladat? A proc jit napul cesty? Konec koncu JIT preklad javy nebo pythonu je principielne to same (a pripada mi ironicke ze jedno povazujete za super vec a druhe za ztelesneni Satana).

2) Stoji tranzistory. Proc v iPhone neni Atom misto ARMu? Protoze Atom musi venovat tranzistory (tedy plochu cipu a spotrebu) prekladu instrukcni sady i386 do neceho rozumneho, zatimco ARM ma ty instrukce v rozumne podobe od zacatku. A proto muze mit pri stejne funkcnosti mene tranzistoru (tj. mensi plochu cipu a spotrebu).

[Martin Mareš]

Ad 1: Jasně, ubastlená je, o tom není pochyb. Ale má i své výhody (chová se tak trochu jako Huffmanovo kódování, takže kód je prostorově dost efektivní). Překládat efektivně byte-kód Javy je řádově těžší problém než překládat x86 (zkuste si to ručně ). S jinými VM by to mohlo jít snazší, třeba Parrot vypadá nadějněji.

Ad 2: To samozřejmě ano – proto se ARM skvěle hodí na různé embedded aplikace, ve kterých záleží na každém miliwattu příkonu. Ale pokud chcete stavět opravdu výkonný procesor, tak vám obvykle záleží na jiných věcech a ukazuje se, že x86 (poměrně překvapivě, když uvážíme, jaký děsný bastl to je) se na to hodí docela dobře.

[pc2005]

x86 je od začátku dělaná tak, že je to v zásadě virtuální stroj, který emuluje nějakou sadu instrukcí. x86 instrukce se nevykonávají přímo, ale emulují uvnitř cpu. x86 instrukce jsou rozloženy do mikroinstrukcí, které se pochopitelně mohou měnit a zdokonalovat s každým modelem cpu.

To je pak s podivem, že je instrukční sada tak neortogonální. Jinak imho je lepší updatovat kompilátor než updatovat procesor.

Rozdíl mezi x86 a ARM je jednoduchý: ARM přenáší na programátora omezení hw a low level přístup. ARM sada je dělaná tak, aby elektronika byla co nejjednodušší a zákonitě přenáší řadu omezení na asm programátora, či na kompilátor – jinak to nejde.

Rozhodně, to je podstata RISC. CPU pak může jet mnohem rychleji.

x86 sada naproti nemá téměř žádný vztah ke skutečné architektuře cpu. x86 cpu si dělá své vlastní vnitřní mikroinstrukce (které jsou tím pádem efektivnější a rychlejší, protože jsou dělány pouze s ohledem na co nejlepší míru architektuře cpu, a asm programátor je nikdy neuvidí, tudíž se nemusí ohýbat = zpomalovat pro něho).

Tak to se mě nezdá, minimálně nese zpětnou kompatibilitu (s periferiemi) někde až z dob 8080. Což například znamená věci jako 8bit přístup... Když jsem porovnával třeba čítače/časovače OMAPu s čítači/časovači PC, tak to bylo nebe a dudy .

Jinak by teda mělo být možný sestavit v kompilátoru ten převod C→ARM asm, stejně jako to dělá mikrokód v x86.

[Martin Mareš]

x86 je od začátku dělaná tak, že je to v zásadě virtuální stroj, který emuluje nějakou sadu instrukcí.

To není pravda. První procesory řady x86 sice měly mikroinstrukce, ale instruční sada byla velmi těsně svázána s architekturou procesoru.

překlad instrukcí se děje paralelně a naráz

To sice ano, ale se spoustou omezení (instrukce na sobě závisejí; kvůli proměnlivým délkám instrukcí je těžké dekódovat několik instrukcí dopředu atd.). Některým procesorům řady x86 se běžně stávalo (třeba u AMD K6), že vykonávání instrukcí bylo bržděné rychlostí dekodérů.

x86 sada naproti nemá téměř žádný vztah ke skutečné architektuře cpu.

Dnes už ne. Je totiž navržena podle dávno již neexistující architektury CPU a dodnes na autory překladačů přenáší omezení té dávné architektury.

Máte příjemný asm pro programátora

Cože? To asi každý programujeme na jiné x86

[Martin Mareš]

Taky nechápu proč se nemůže do segmentovejch registrů zapisovat přímo.

Na segmentové registry zapomeňte. To je dědictví minulosti, které už dneska nikdo soudný nepoužívá. Ve 64-bitovém módu prakticky neexistují. (Dobře, existuje jedna výjimka, a to používání GS k relativní adresaci per-thread dat.) Takových obskurností se v x86 za těch 30 let značně křivolakého vývoje nahromadila spousta.

Loop není sám, zajímavý je třeba REP, který podle CX opakuje následující instrukci (používá se na kopírování paměť-paměť).

To je pravda, ale naštěstí hustota takových přesunů v kódu je poměrně malá, takže to při alokaci registrů moc velkou paseku nenapáchá.

Pak jak se začaly přidávat věci jako MMX, SSE, tak se musely dít věci .

A děly Ale třeba takové SSE je docela hezky ortogonální instrukční sada. (Jen kdyby uměla počítat zbytky po dělení … to by se implementovala reziduová aritmetika …)

Nepoužívá náhodou x86 instrukční sada už někde od P2 překlad na RISC mikrokód?

On to není mikrokód v tom klasickém smyslu, spíš sada jednodušších instrukcí.

Rozhodně se mě nezdá, že by konverze C→CISC x86→RISC mikrokód byla v principu nějak účinnější než C→RISC ARM.

Ta konverze má jednu velkou výhodu, totiž že strojový kód x86 vychází výrazně kompaktnější než u ARMu, což šetří paměť a hlavně místo v cache. (Ostatně u ARMů to už také objevili a vymysleli Thumb.)

(Svatý Tučnáku, ono to asi vypadá, že si myslím, že x86 se mi líbí! No to opravdu ne, ošklivější instrukční sadu aby jeden pohledal. Jen už jsem po letech pochopil, že to zase takové zlo není a že vytvořit něco, co by bylo natolik lepší, že by to mělo šanci nad x86 na trhu vyhrát, nedovedu.)

[pc2005]

Na segmentové registry zapomeňte. To je dědictví minulosti, které už dneska nikdo soudný nepoužívá. Ve 64-bitovém módu prakticky neexistují.

Aha, já se k 64bitu ještě nedostal a když to porovnám třeba právě s OMAPem, tak se asi ani nedostanu .

To je pravda, ale naštěstí hustota takových přesunů v kódu je poměrně malá, takže to při alokaci registrů moc velkou paseku nenapáchá.

Jo ovšem pokud člověk neprogramuje BIOS, kde je vše 16bitové a ještě třeba neexistuje paměť .

Jen už jsem po letech pochopil, že to zase takové zlo není a že vytvořit něco, co by bylo natolik lepší, že by to mělo šanci nad x86 na trhu vyhrát, nedovedu.

Tak to není problém, stačí vytvořit něco co bude levnější a rychlejší , třeba ten ARM s thumbem a jazelle má dost šancí.

[Martin Mareš]

Jo ovšem pokud člověk neprogramuje BIOS, kde je vše 16bitové a ještě třeba neexistuje paměť .

Míst v BIOSu, kde by paměť neexistovala, je naprosté minimum. Obvykle se používá nádherný trik: L2 cache se přepne do módu, kdy nekomunikuje s RAMkou a nic nevyhazuje, takže do ní můžete zapisovat jako do RAMky, i když ještě není inicializovaný řadič paměti.

Tak to není problém, stačí vytvořit něco co bude levnější a rychlejší , třeba ten ARM s thumbem a jazelle má dost šancí.

Moc bych mu to přál. Ale realistická část mého já tomu moc velké šance nedává. Hlavně proto, že rychlejší sotva bude; jediné, v čem má šanci vyhrát, je spotřeba.

[pc2005]

Jo o tý cache vím, ale nezdá se mě to moc regulérní, ten komp tuším L2 nemusí mít vůbec.

Já bych řekl, že výpočetní výkon je dost dobrý, myslím, že jsem viděl dualcore 1GHz + c64x s příkonem okolo 1W. Ten celek je imho tak třikrát rychlejší než muj komp s asi desetinovou spotřebou . Škoda, že spousta těch ARMů nemá nějakou pořádnou sběrnici (třeba PCI) nebo ještě lépe CPU2CPU.

[Martin Mareš]

Jo o tý cache vím, ale nezdá se mě to moc regulérní, ten komp tuším L2 nemusí mít vůbec.

Pssst, už je rok 2010 L2 cache bývá v x86kovém světě už pěkných pár let uvnitř procesoru.

[pc2005]

No v inkriminovaném stroji je ve formě DIL pouzder . Jinak jasný na novým kompu bych prostě nainstaloval coreboot a hotovo. Ono taky ty nový procíky jsou blbě dokumentovaný, osobně by mě třeba zajímal assembler mikrocode patchů.

[Bedňa]

Já Vám klidně napíšu kompilátor, který Vám to zkompiluje 30× rychleji a spotřebuje ještě méně paměti.

Ja chcem ten kompilátor. Inak vás nikto nebude brať vážne po takých šplechoch. Optimalizáciu mám na háku, tú mi spravý gcc.

[Filip Jirsák]

Pro vývoj ovšem potřebujete hlavně rychlý kompilátor, pomalé optimalizace můžete zapnout až pro testy a finální build.

[Martin Mareš]

Moc tomu nevěřím. Když vyvíjím, naprostou většinou času trávím prací na nějakém konkrétním modulu, takže se překompilovává jen ten a pak se celý program přelinkuje. Čas stávený kompilováním během jednoho dne vývoje počítám maximálně na minuty.

[Sten]

Pokud nevíte, co je to LLVM, tak vám to asi přijde k ničemu. Jakmile zjistíte, že je to Low Level Virtual Machine a umí to takové věci, jako profilování kódu a jeho optimalizace za běhu nebo multiplatformní zkompilované C/C++ aplikace (včetně automatické kompilace do strojového kódu), zjistíte, že je to hodně zajímavý projekt.

[Vykook]

K tomu, ze to neni pod gpl.

[YYY]

A je nekde k dispozici treba srovnani rychlosti behu gcc verze a clang verze? To by byl imho velmi zajimavy udaj.

[František Bártík]

Ten test jsem provedl na rozsáhlém náhodném C kódu; viz můj bývalý blog, který jsem zrušil kvůli excesům redakce. Test na realných aplikacích prováděl například Phoronix.

[Ladicek]

Něco málo vyšlo i na linuxsoftu (1, 2, 3), výživné jsou zejména komentáře uživatele "Miloslav Ponkrác" pod třetím dílem

[Vskutečnosti Saýc]

Jojo, ponkrac je ztelesnenim humoru. Takovej linuxovej Hulan.

[Miloslav Ponkrác]

Ponkrác holt je nepříjemný, protože kazí iluzi o dokolanosti některých linuxových projektů.

Ponkrác se klidně vsadí, že z llvm pršet nebude, a že časem po něm pes neštěkne.

Ponkrácovi bohatě stačí, když mu dává za pravdu realita. To je pro něho jediný etalon pravdy, jiný neexistuje.

Musíte si uvědomit, že ročně se objeví mnoho projektů a řada z nich se vyzdvihuje jako něco, co změní svět a udělá díru do světa. V reálu ovšem většina z nich zapadne a po pár letech si nikdo nevzpomene, že kdy existovaly.

Většinou to lze odhadnout předem, pokud se na věc podíváte věcně. LLvm bude přesně takový propadák. Ten projekt má už v principu taková omezení, která z něj nemohou nikdy udělat dobrý C/C++ překladač. Časem se to zjistí, ale nadšení nikomu neberu.

Ony fyzikální zákony jaksi platí pořád stejně. A na rozdíl od společnosti a přání mého kolegy nahoře jsou nepodplatitelné. Nezmění se ani tím, že budete někoho zesměšňovat, ani tím, že je popřete v novinách, či na internetové diskusi.

Dál se vyjadřovat nebudu. Jen si tohle zapamatujte a za pár let si vzpomeňte a jen se ptejte, kde je ten úžasný projekt llvm. Llvm má dobré možnosti stát se kompilátorem a interpretrem řady jazyků, ovšem nikoli pro C/C++, kde nemůže nabídnout co tyto jazyky potřebují.

Takže počkejte pár let a pak se smějte. Více diskutovat není třeba. Může pak třeba vyrobit R.I.P. LLVM – to bude tak nějak důstojné situaci.

[Vskutečnosti Saýc]

Ponkrac o sobe taky rad mluvi ve treti osobne.

[pc2005]

Zajímavý, takže další kompilátor, kolik jich už vlastně je? Tři, čtyři?

Rychlostní benchmark by mě taky zajímal.

[Miloslav Ponkrác]

Rychlostní benchmark není pro llvm příznivý (s několika výjimkami). Takže se manipulují zprávy o llvm zdůrazňováním jiných vlastností doufajíc při tom, že na rychlost výsledného kódu se nikdo nebude ptát.

[pc2005]

Benchmark table needed.

[Miloslav Ponkrác]

Tento odkaz se nachází v této diskusi.

[pc2005]

Ten na Živě? Ale ten je přes 2 měsíce starý a není zaměřen přímo na kernel.

Jinak na debuggovací účely rychlost zkompilovaného programu opravdu není potřeba, mnohem důležitější je ale rychlost samotné kompilace. A jestli bude výsledná aplikace v paměti zabírat 200MB místo 100MB je u debuggingu taky jedno. A z toho textu na živě vyplývá, že je Clang rychlejší.

Jedinej problém je v tom, že to nezkompilovalo jádro celý, což bude hodně čas žeroucí. Ale já tu zprávičku beru jako takovej trailer .

[Miloslav Ponkrác]

Je tu odkaz na linuxsoft. Navíc s velkou ctí, že mi kdosi dělal reklamu, aby se na mně nezapomnělo.

Když se vybírá kompilátor, pořadí důležitosti je toto:

1) 100% soulad s normou jazyka

2) spolehlivost. jako programátor jste zcela závislý na spolehlivosti a bezchybnosti generování výsledného kódu

3) kvalita výsledného kódu. ať už si myslíte cokoli, předpokládám, že cílem programátora je nakonec udělat release verzi. C/C++ nemá smysl, pokud nemáte kvalitní kompilátor. pokud nepotřebujete efektivní kód, proč to neudělat třeba v javě?

4) to ostatní

U clangu se řeší to ostatní, a schválně se zamlčují tyto první tři body.

Jinak dále už tuto diskusi nebudu sledovat.

[pc2005]

No já měl na mysli jen benchmark jádra Linux nejvyspělejší (asi) verzí clangu.

1,2) Souhlasím, ale s tím můžou být problémy kdekoliv.

3) Ale jen finální kompilace, to je tak <1% celkového času stráveného kompilacema. Například pro věc co jsem dělal není efektivita kódu nijak potřeba, kód pouze nastavuje hw .

[František Bártík]

Jako autor zmíněného článku se musím ohradit. Výsledkem testu bylo, že kompilace v LLVM (resp. vzniklá binárka) je rychlejší pouze bez optimalizací. Při provádění optimalizací, což je důležité, dominuje GCC. (U vysoce optimalizovatelné kódu GCC vytvořilo téměř dvakrát rychlejší kód.) To je vcelku logické; GCC je mnohem robustnější produkt, který využívá mnohem více pomocných dat...

Proto je pro praxi výhodnější GCC. Vysokou rychlost kompilace bez optimalizací ocení asi jen úplní začátečníci a ctrl-v programátoři, kteří intenzivně zkouší, zda program už bude fungovat.

[pc2005]

Tak důležité je zda je GCC s optimalizací rychlejší než LLVM bez nich.

Rychlost kompilace ocení i ti, kteří se snaží vyházet z jádra co nejvíc věcí a kvůli nějaké šílené závislosti to po vyhození něčeho zdánlivě nedůležitého přestane fungovat a je třeba udělat rekompilaci všeho.

[petris_]

Pole promenne delky uvnitr struktury neni rozsireni gcc, ale vlastnost C99.

[Miloslav Ponkrác]

Ona sama zpráva lže. Linux se nepodařilo zkompilovat clangem, protože clang to nedokázal sám o sobě. To bez gcc nešlo. Tudíž zpráva o zkompilování linuxu clangem je lež. Ale koho to zajímá.

[Shadow]

Priznam se, ze mne osobne se take nadpis zpravicky nelibi, neb vyvolava mylny dojem, tj. ze clangem lze zkompilovat cele jadro, coz samozrejme neni pravda, kdyz na nejake kusy bylo pouzito GCC.

[MMN]

Jenže linux není psán v C99 ;)

[Martin Mareš]

Linux je psán v nadmnožině C99.

[MuadDib]

Soudruzi, tady se zcela zbytečně hádáte, Miloslav Ponkrác to vyjádřil naprosto jasně; kromě toho, komu je k čemu ta zatraceně rychlá kompilace? Jasně, pokud programujete perturbační metodou, tak to můžete ušetřit něco málo času. Ale jinak argumentovat spotřebovanou pamětí je dost ujeté, jelikož slušně napsaný program bude mít asi více jednotek, a nejvíce paměti pak sežere nikoliv překlad, ale sestavování.

(Jo, a abychom se z toho všichni nepodělali, tak si uvědomme, že snad největší zájem na zbožšťování Clang+LLVM mají různí trollující apploidi kteří považují tu předraženou intelovskou sračku v extravagantní bedně s kočkovitou šelmou za 8. div světa.)

[Vykook]

:-*