A Debian archive csomagjainak újrafordítása clang-gel

 ( trey | 2012. március 1., csütörtök - 21:28 )

A Debian fejlesztő Sylvestre Ledru nemrég azon munkálkodott, hogy újrafordítsa a Debian archive csomagjait clang-gel. Az újrafordítással több célja is volt. Egyrészt, hogy kiderüljön, hogy a clang egy életképes alternatíva vagy sem. Másrészt haszna van annak, hogy szoftvereket különböző fordítóprogramokkal is lefordítanak, hiszen azok különböző ellenőrzéseket hajtanak végre, illetve különböző hibaüzeneteket adhatnak. Ezek az adatok pedig végső soron hozzájárulhatnak a jobb minőségű kód előállításához.

A teszt során 15 658 csomag került újrafordításra. Ebből mindössze 1381 csomagnak a fordítása végződött hibával. Ez a csomagok 8,8 százaléka.

Amikor Sylvestre úgy döntött, hogy újrafordítja a Debian csomagokat, akkor arra számított, hogy a clang-gel számos bugba és problémába fog belefutni. Ehhez képest pozitívan csalódott. Szerinte a clang elég stabil és jó ahhoz, hogy újra lehessen fordítani a Debian csomagok többségét, még akkor is, ha többnél szükséges kisebb módosítás a sikeres fordításhoz.

Sylvestre szerint a clang néhány éven belül akár alapértelmezett fordító lehet BSD-kben és Linux disztribúciókban.

A teszt részletei itt. Sylvestre blogbejegyzése itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Remek hír. Akkor hozzá lehet fogni a gcc gányolások kitakarításához. Persze ha ezt a Debian-nál megteszik és másutt nem akkor szép kis kavarodás lehet a forráskódok között.

Ha ilyenhez áll neki a debian, akkor úgyis patchként szállítja az upstream mellé...

Csak én félek a Debianos patchektől? :)

----------------
Lvl86 Troll

Igen tudom, de a kollégák reakciói elárulják a lényeget. :-)

Sylvestre csak a fordítási időből indult ki. abban valóban gyorsabb a clang a gccnél. de a lefordított binárisok közül már a gccvel fordított a gyorsabb. márpedig ez utóbbi jóval fontosabb, mint a fordítási idő.

Szeretem az univerzalis igazsagokat, segitenek elviselheto szintre csokkenteni a valodi vilag tulzott bonyolultsagat.
--
zsebHUP-ot használok!

Úgy általában igazad lenne, de jelen esetben viszonylag könnyű gcc clang benchmark összehasonlításokat találni a neten, és a tesztelt programok nagy többsége a gcc-vel 5-10%-kal gyorsabb.

Tehát a fenti állítás sem rosszabb, mint hogy az icc általában gyorsabb kódot generál mint a gcc.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Nem, ezek a kijelentések egyszerűen tévedések. Valóban könnyű teszteket találni, és az eredmény legalábbis vegyes. prygme nagy bölcsessége kb. 3 éve fedhette a valóságot, vagy már akkor sem.


[ NeoCalc - Earnings Calculator for NeoBux ]

Hat anno amikor szantog bemutatta, mikre [nem] kepes a clang (pl. egynel tobb regisztert hasznalni egy ARM prociban) akkor ket dologban ingott meg a hitem:
- hogy nem kell tobbet assembly-vel foglalkoznunk, a c fordito elintezi
- hogy a clang egy erett fordito, ami alkalmas mobilalkalmazas-fejlesztesre

Lehet hogy 2011 majusa ota valtozott a helyzet, de akkor es ott nem gondoltam azt hogy jo otlet volt az apple-nek osszeveszni gcc-ekkel.

Jo otlet volt.

---
pontscho / fresh!mindworkz

nem "veszett össze" az Apple a GCC fejlesztőkkel, csak arról volt szó, hogy az Applenek stratégiájában központi szerepe van az ObjectiveC nyelvnek, még a GCC fejlesztésénél ez csak alacsony prioritást kapott.

sikerült olvasás nélkül belinkelned egy phoronix cikk egyik oldalát.
pedig ha el is olvastad volna a teljes cikket tudhatnád, a DragonEgg GCC számára nyújtott előnyeiről szól. egyetlen tesztben bizonyult csak elsőnek a Clang, az összes többiben vagy DragonEgg+GCC ill DragonEgg+GCC+-fplugin-arg-dragonegg-enable-gcc-optzns opció, vagy a mainstream GCC volt a legjobb.

természetesen az a szempont sem hagyható figyelmen kívül, hogy a Clang csak négy programnyelvet támogat két architektúrán, ill három ha az AMD64et külön számoljuk. ezzel szemben a GCC több mint 10 programnyelvet támogat ~50 architektúrán.
így még jó ideig zero esélye van annak, hogy a Clang alapértelmezett fordító lehessen a nagyobb Linux disztribúciókban.

Es kulonosen pikansa teszi a szitut, h az llvm-bol vett optimizer a gcc altal generalt kodon jobban teljesit, mint a gcc sajatja alapbol. Ez a kulonbseg ledolgozhato es jo utemben haladnak efele.

---
pontscho / fresh!mindworkz

Még érdekesebb kérdés, hogy ugyanez az optimizer vajon miért nem teljesít ugyanolyan jól clang frontenddel...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Valoszinuleg azert, mert a clang kozteskod generatoran meg van mit csiszolni es azon nem hoz annyit a dragonegg, mint a gcc altal eloallitotton, nem veletlen volt egy jo ideig a gcc az llvm frontend. Az mar egy eleg jo fel siker, h az llvm-ben levo optimizer viszont jobban teljesit, mint a gcc-e, igy mar elsosorban csak a c/c++/objc compileren kell huzni egy kicsit. A logok szerint rajta vannak a sztorin.

---
pontscho / fresh!mindworkz

Ja értem, tehát ha a cikk a dragonegg-et mutatja be, akkor a clang rész érvénytelen. A ferdítés is kurvajól megy, mivel nem első helyről beszéltünk, hanem GCC vs. Clang teljesítményről ("a lefordított binárisok közül már a gccvel fordított a gyorsabb", mondod te), és konkrétan 4 esetben veri meg a Clang a GCC-t, a többi esetben pedig (egy kivétellel, ami szinte biztosan bug) totál elhanyagolható a különbség.

Az meg kurvára mindegy, hogy a gecicé hány arch-ot támogat (ami pont a hátránya a sok, évtizedek óta magával cipelt fos miatt), ha a clang által támogatott 2 arch lefedi a piac 99%-át. A maradék 1%-kal (a "futottak még" kategória) meg kitörölheted a segged.


[ NeoCalc - Earnings Calculator for NeoBux ]

"Az meg kurvára mindegy, hogy a gecicé hány arch-ot támogat (ami pont a hátránya a sok, évtizedek óta magával cipelt fos miatt), ha a clang által támogatott 2 arch lefedi a piac 99%-át. A maradék 1%-kal (a "futottak még" kategória) meg kitörölheted a segged."

Az llvm nem pont azért jó, mert különválasztja a forráskód fordítását a konkrét architektúrára való bináris előállításától? Azaz ha kell egy új arch, akkor annak támogatását nem kell minden nyelvhez külön megírni, hanem megírom egyszer, és minden nyelvvel működni fog.

Igazából tökmindegy, hogy hol és mit kéne bővíteni, a lényeg, hogy az x86 és ARM támogatva van, és ez bőven elég.


[ NeoCalc - Earnings Calculator for NeoBux ]

AFAIK de. Meg hogy az optimalizert is elég egy nyelvhez megírni.

----------------
Lvl86 Troll

Akkor a gcc-vel fordított clang gyorsabban fut de lassabban fordul, mint a clang-gal fordított clang?

A nap beszólása/aranyköpése!!!!

Tied a Nobel-csont!

Továbbgondolva, clang-gal kell fordítani a gcc-t, amitől az még lassabb lesz. Ez a tesztekben még jobban kiütközik, így a gcc-fejlesztők elkezdenek végre a fordítási idő sebességének javítására gyúrni, aminek eredményeképp még nagyobb bugokat építenek a fordítójukba. És ekkor a világ elfelejti végre a gcc-t.

mi bajotok a gccvel?

Nem értenek hozzá/nem is akarnak.
Pontscho meg mintha macfag lenne :-)

Nyilvan csak es kizarolag ez lehet az oka, hogy ez elobb nem jutott az eszembe basszus!!1111elevenhold

---
pontscho / fresh!mindworkz

látod, megéri itt flémelni!!!!1.emelet

Mint ami a legtobb opensource takolmannyal: not the right thing.

Kicsit más téma, de nézzétek meg a binutils forráskódját. Főleg a bfd.h-ban a bfd_vma és a bfd_boolean kommentjeit.
Meg az addr2line forrását, hogyan alkalmaz globális változókat oda, ahova nem kéne, mert könnyen megoldható lenne anélkül is...

Csak mert mostanság ezen fogtam a fejem, mert libbfd programozásra vetett engem a sors keze...

mi bajotok a gccvel?

Ez.

(tudom regi szal, de a video mindenkeppen megerdemli)

Viszont fejleszteni clanggal erdemes, gcc egy fapados hulladek ahhoz kepest. Ha kell az a kraft a ket compiler kozotti kulonsegbol adodoan ami jelenleg meg a gcc mellett szol (ez a differencia is durvan kezd az elhanyagolhato savba esni es/vagy megfordulni, a 3.0final mar teljesen korrekt) akkor a final buildet gcc-vel forditom es amen. Remelem a clang/llvm/csa trio vegre levaltja a gcc-t es az a veszelyes hulladek oda kerul ahova valo.

---
pontscho / fresh!mindworkz

+1

az a veszelyes hulladek oda kerul ahova valo

Nem fűznek érzelmi szálak a gcc-hez, de mi ez a harag? :) Bele kellett nézned a forrásába? :)

A remek minosegu generalt kod, a jo minosegu parser es a hibatlan, jol mukodo debugger kozos munkajara volt szukseg ahhoz, h kialakuljon nemi utalat. Mert amelyik stabilnak kikialtott compiler meg a htons() makrot sem kepes konzisztensen hibatlanul leforditani az menjen a fenebe. :)

---
pontscho / fresh!mindworkz

miért nem küldted be a bug trackerbe?

Mert az ujabb verziokban ez mukodott, azokban mast kurtak el, masreszt idom kimelese vegett inkabb valtottam egy jobb - bar multi altal tamogatott, de szinten opensource - compilerre. Ismerven az altalaban vett opensource projecteknel mukodo customer service minoseget, ez a verzio nagysagrenddel jobb hatasfokkal kecsegtetett.

---
pontscho / fresh!mindworkz

Korrekt, köszi.

A hibák 1/3-a hiányzó szimbólumokról szól.
Ez most a csomag vagy a clang hibája?

Nem, ez az alma vs. körte esete. Az egyik fordítóval C89-el, a másikkal C99-el fordítanak, nem meglepő, hogy elromlik. Legalább azonos standard szerint illene felparaméterezni a két fordítót.

--
joco voltam szevasz

Jól jönne ez a vérfrissítés. Jó ez a gcc, de iszonyatosan patkolt már. Megérett egy méltó örökösre. Sok sikert.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Ez az egész arra emlékeztet, mikor a TFT-k megjelentek és mindenki szidta őket, hogy mekkora szar képük van (kezdeti TN+Film, ugye), aztán valamiért mégiscsak továbbfejlődtek és kisöpörték a CRT-ket ;)

----------------
Lvl86 Troll

Mindig jön egy új. A csúcson maradni meg elég nehéz: "...a győztes sokkal fáradtabb..." (Az LGT valamelyik nótájából.)

Persze, csak az emberek mindig meglepettek, hogy az új kihívó szinte sosem jobb elsőre, egyből a fejlesztés nulladik lépésétől, mint azt, amit csillió éve reszelnek. De ugyanez megvan több másik területen.

----------------
Lvl86 Troll

Es ez igy is van rendjen. Ha mindig minden uj megoldast elfogadnank, akkor egy sem terjedhetne el annyira, hogy kiforrotta valhasson.

Ez a gondolkodásmód talán a rohanó, elkényelmesedett korunk terméke. Gyorsan, ingyen a legjobbat. :-(

Off: nem LGT, Zorán (persze a zeneszerző és a szövegíró közös, de az most lényegtelen)

sub