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

Debian

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.

( 4fonya | 2012. 03. 01., cs – 22:46 )

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.

( prygme | 2012. 03. 02., p – 04:14 )

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ő.

Ú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

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.

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.

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.

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.

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...

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

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

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

( wince | 2012. 03. 02., p – 08:06 )

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

( emberk | 2012. 03. 02., p – 23:05 )

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.

( saxus | 2012. 03. 03., szo – 17:43 )

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