A ClangBSD mostantól "self-hosting", tesztelők kerestetnek

FreeBSD

A ClangBSD a FreeBSD egyik ága. Célja, hogy integrálja a clang-et a FreeBSD-be annak érdekében, hogy az leváltsa a jelenlegi alapértelmezett rendszerszintű fordítóprogramot, a gcc-t. A ClangBSD a napokban egy fejlesztési mérföldkőhöz érkezett, mostantól "self-hosting".

Self-hosting-ról akkor beszélünk, amikor egy program képes önmagát előállítani (például egy fordítóprogram képes a saját forráskódját megfelelően lefordítani), vagy nagyobb projekt (például egy operációs rendszer) esetében, amikor az alkalmazott fordítóprogram képes az egész operációs rendszer lefordítására. A ClangBSD ág esetében a "self-hosting" most azt jelenti, hogy a clang képes az egész FreeBSD world-öt (beleértve az összes C++ programot is) és egy bootolható kernelt lefordítani i386 és amd64 platformon.

Éppen ezért a fejlesztők most azt kérik a FreeBSD közösség tagjaitól, hogy segítsenek a szélesebb körű tesztelésben.

A tesztelés egyelőre chroot környezetben ajánlatos. Egyelőre nem javasolt a ClangBSD valódi root környezetben való felhasználása, mert még nincs ennyire kitesztelve.

A tesztkörnyezet felállításához szükséges lépések leírása megtalálható a bejelentésben.

(A linkért köszönet pinyo_villany olvasónknak.)

A gyakran előforduló kriptikus hibaüzenetek. Például tipikusan ha lehagysz egy pontosvesszőt egy osztálydeklaráció után, akkor kanyarba nem ott jelzi a hibát, hanem teljesen meggajdul. Az más kérdés, hogy a gyakorlott szem könnyen kiszúrja, hogy hamisak a hibák, és már tudja is, hogy mi a baj, de mindig több kezdő lesz, mint nem kezdő. Emellett még egy gyakorlott programozónak is jobb, ha egyértelmű a hibaüzenet.

Itt van két link arról, hogy miket tud:

http://clang.llvm.org/diagnostics.html
http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html

Emellett van a clangban static analyzer, valamint a felépítése is olyan (moduláris C++ könyvtárak), hogy könnyebben hozzá lehet nyúlni, mint egy GCC forráshoz.

Nem mellesleg az Apple komolyan fejleszti (a fő fejlesztők nagy része az Apple-nél dolgozik), ezért az ObjC support eléggé jó benne. Feltehetőleg középtávú cél az Applenél, hogy kidobják a GCC-t, és clangra állnak át. Az XCode-ban alternatív fordítóként már most is elérhető.

Üdv,
Gergely

Leginkább azért lehet ez, mert az LLVM eredetileg a gcc-t használja frontendnek, azaz ami gcc-vel fordul az ezzel is (C és C++ legalábbis, de talán a többi is).

A clang "csak" egy C (Obj-C, C++) frontend az LLVM-hez, és emlékeim szerint gcc kompatibilisre tervezik, azaz elméletileg sose kell amiatt aggódnod, hogy belefutsz egy clang only forrásba...

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

A példa jó is meg nem is.
Jó, mert tényleg idióta hibaüzeneteket produkál, és rossz, mert szerintem minden fordítóval ezt csinálja...
De ha valaki megcáfol annak csak örülök...

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

llvm ha jol tudom bsdl, igy ha csinalsz egy sajat rendszert, es be akarod zarni, akkor bezarhatod minden kotelezettseg nelkul, ez az elsodekeges szempont a valtasra. A masodlagos szempont, hogy jelenleg license dolgok miatt a freebsd alaprendszerek es portok nagyresze gcc 4.2.1-gyel fordul, aminek a megjelenese ota kijott par optimalizacio ujabb cpu-khoz, amikre ez a verzio meg nem tud optimalizalni... 


 ~> cc --version
cc (GCC) 4.2.1 20070719  [FreeBSD]
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

___
info

> Az llvm még nem hozza a gcc szintjét (sem), de közel van.

# size linux-2.6.33.2-pax/vmlinux
text data bss dec hex filename
9201385 9907021 3941284 23049690 15fb5da linux-2.6.33.2-pax/vmlinux

# size linux-2.6.33.2-pax-llvm/vmlinux
text data bss dec hex filename
9689844 7718024 3550276 20958144 13fcbc0 linux-2.6.33.2-pax-llvm/vmlinux

es ez qemu alatt bebootol userlandig, bar azert gyanus, hogy hova tunt el 2MB adat, mert ennyire csak nem tud optimalizalni (bar durva dolgokat lattam, mire idaig eljutottam vele). mindenesetre ranezve a generalt kodra nem jelentenem ki rola, hogy nem hozza a gcc szintjet, de majd ha beindul igazi hw-en is, akkor meg is merem.

Az azért érdekelne hogy néztél rá a generált kódra úgy, hogy bármit mondani tudj a teljes kernel sebességéről. :)

Fordíts le szinte bármilyen benchmarkot és láthatod, hogy az LLVM kódja egy kicsivel lassabb mint a gcc-é. Legalábbis az LLVM 2.6 lassabb volt mint a gcc 4.4. Ennyit állítok és nem többet.

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

> Az azért érdekelne hogy néztél rá a generált kódra úgy, hogy bármit mondani tudj a teljes kernel sebességéről. :)

egyreszt a teljes kernel sebessegerol nem allitottam semmit, max azt, hogy majd lemerem, ha eljut odaig, hogy bebootoljon rendesen, masreszt meg mondjuk ugy, hogy van nemi gyakorlatom disasm olvasasban es sok mindent megmondok ranezesre ;).

attol fugg, mi okozza. ha egy adott fv-re/blokkra generalt kod (ami hotpath es ezert eredoben nagy az impact-ja), akkor siman megmondom, ha meg sok kicsi dolog szetszorva 10000 fv kozott, akkor meg nyilvan nem (pontosabban nem fogok vele idot tolteni, inkabb lemerem). amugy meg az 5-10%-ok mar az a hatar, ami engem nem erdekel kulonosebben, mert ennyi evolucio a gcc-ben is volt az ev(tized)ek alatt, az llvm meg a ra epulo eszkozok fiatalok meg, tehat boven be fogjak majd hozni. amit viszont a gcc sosem fog behozni, az a kod hackelhetosege, az llvm (ranezesre ;) nagysagrenddel kevesebb idot igenyel.

Kernelről beszéltünk...

llvm sem mai csirke sőt. Csak a clang ami új. Persze nyilván lehet még fejleszteni rajta, de a gcc-t sem hagyták abba.

Hackelés szempontból az LLVM valóban erős (nem véletlenül épült rá az eddigi összes OpenCL implementáció, sőt még a Gallium3d is). De a gcc is sokat javult ezen téren az új plugin rendszerrel...
(Az egyik első plugin pont az LLVM)

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

> Kernelről beszéltünk...

ja, en is, nem ertem, miert emelted ki ;).

> llvm sem mai csirke sőt. Csak a clang ami új. Persze nyilván lehet még fejleszteni rajta, de a gcc-t sem hagyták abba.

az llvm kb 10 eves, anno Chris Lattner diplomamunkaja volt, a gcc meg oregebb, mint az atlag hupper, ami szamitastechnikaban eg es fold kulonbseget jelent ;). de nem is az abszolut eletkor az erdekes, hanem az, hogy a 'mit lehet meg kihozni a processzorbol' fejlodest leiro gorbe nem linearis (ekkor lenne erdekesebb az abszolut eletkor), hanem valami telitodest ir le inkabb. es itt a gcc nyilvan kozelebb all a telitodesi folyamat vegehez, mint az llvm, erre mondom en azt, hogy az elkovetkezendo evekben az llvm-tol sokkal tobb fejlodest lehet varni, mint a gcc-tol, pont azert, mert az egyiknek meg van hova javulnia, a masiknak meg mar nem olyan sok. ha meg nem a kodgeneralas minoseget nezem, akkor meg a hackelhetoseg miatt mindenkepp az llvm-nek van elonye, mondhatni behozhatatlan, es ezen egy gcc plugin rendszer sem segit, mert attol meg a gcc belso felepitese nem lesz egyszerubb (nem beszelve arrol, hogy pluginban sem lehet mindent megcsinalni). egy harmadik, szamomra fontos dologban is az llvm vezet: forditasi sebesseg (kernelt forditva az llvm gyorsabb vmware-ben, mint gcc igazi hw-en).

"ha egy adott fv-re/blokkra generalt kod (ami hotpath es ezert eredoben nagy az impact-ja), akkor siman megmondom, ha meg sok kicsi dolog szetszorva 10000 fv kozott, akkor meg nyilvan nem"

Erre mondtam, hogy kernelről beszéltünk... Gyanítom, hogy a kernel az utóbbi...

"itt a gcc nyilvan kozelebb all a telitodesi folyamat vegehez, mint az llvm"
Ezzel egyet tudok érteni, szerintem is rövidtávon megközelíthető a gcc-icc szintje (most sincsenek távol), megelőzni őket viszont nem látok sok esélyt.

"hackelhetoseg miatt mindenkepp az llvm-nek van elonye, mondhatni behozhatatlan, es ezen egy gcc plugin rendszer sem segit, mert attol meg a gcc belso felepitese nem lesz egyszerubb"
Alapvetően egy fordító belső felépítése nem egyszerű, és ezen nem segít az sem, hogy a gcc-t C-ben írták.
Egyébként a plugin rendszer lényege pont az, hogy nem kell ismerned a teljes belső felépítést. Mint ahogy LLVM előnye is a modularitás, azaz ott sem kell mindent megértened pl egy új frontend írásakor.

De egyetértünk abban, hogy az LLVM hackelhetőbb.

"szamomra fontos dologban is az llvm vezet: forditasi sebesseg"
Ez számomra akkor lesz szempont, ha ismeri majd a teljes C++98 szabványt, sőt lehetőleg minél többet a C++0x-ből. Jó úton halad, de 2.9 előtt nem várom...

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

> Erre mondtam, hogy kernelről beszéltünk... Gyanítom, hogy a kernel az utóbbi...

nem, mindket resz a kernelrol szolt (de igaz altalaban is). azaz attol fuggoen, hogy hol rejtozik a gyorsabb kod titka, vagy megmondom disasm-bol, vagy lemerem es utana nezem meg a disasm-ot ;). azon kernel kod alapjan, amit eddig neztem, nem latom okat, miert lenne az llvm altal generalt kod lassabb, meg csak akar 5-10% erejeig sem, de majd a meresek eldontik, ha eljutok odaig vegre.

> megelőzni őket viszont nem látok sok esélyt.

ilyet nem is lehet, mert a telitodes miatt majd az lesz (ill. mar van reszben), hogy ez az egydimenzios 'gcc jobb kodot gyart, mint az llvm' dolog atvalt tobbdimenzios 'gcc jobb X-re, de rosszabb Y-ra' dologra, ahol a 'jobb' maga tobbdimenzios lesz (pl. kod meret vs. sebesseg), es ki ebben, ki abban lesz 'jobb'.

> Egyébként a plugin rendszer lényege pont az, hogy nem kell ismerned a teljes belső felépítést.

ez sajnos feladattol fugg, speciel ahhoz, amit en akarok csinalni, muszaj lesz ismerni majdnem minden reszet, akkor is ha nem fogok belenyulni, de legalabb azt meg kell tudnom mondani, hogy az adott forditasi fazis interferal-e azzal, amit en csinalok.

( Chronos | 2010. 04. 18., v – 12:20 )

Jó kis munka lehetett, gratula nekik és jó ünneplést. Nem egyszerű egy mérföldkő :)

( al3x v | 2010. 04. 18., v – 22:51 )

Ha johiszemuen allunk hozza lehetseges, hogy nincs opcio arra, hogy AMD-re optimalizaljon es alap esetben mindent Intel szemszogbol fordit.

--
http://bsdbased.com

( turul16 v | 2010. 04. 19., h – 07:08 )

llvm/clang tema igeretes volt amig gcc nem tudott forditasi egysegek kozott optimalizalni. llvm legutobb probalt valtozataval ez a lehetoseg nem javitott a teljesitmenyen, ellenben gcc 4.5 -el amibe bekerult es gyorsabb lett.
Ujra nem latom ertelmet valtani.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

> gcc magahoz kepest lett gyorsabb, nezd a gcc 4.5 cikket.

ize, akkor nem ertem, mire fel mondtad, hogy nincs ertelme llvm-re valtani. elso olvasatban ugy tunt, hogy te lemerted mindket forditot, es a gcc jobb lett (lto-val), de akkor ezek szerint ez nem tortent meg? akkor viszont tovabbra is all a kerdes, hogy miert ne lenne erdemes llvm-re valtani? kerdezem ezt azert, mert minel tovabb jatszom az llvm-mel, annal inkabb hajlok ra, hogy a PaX jovobeni dolgait llvm-re irjam meg csak.

Fel eve gcc-hez kepest lassab volt az llvm szinte minden teszten az osszes probalt modon.
lto volt az a feature ami miatt lenginkabb tetszett az llvm, de nem lattam semmi eredmenyet.

Most gcc 4.5 -ben megjelent es lattam, hogy javult tole a tobb forditasi egysegbol allo kod.

Mai llvm-et nem probaltam, es jo par napig nem is lesz ra idom.

llvm/clang, ha ugyan olyan jo, mint gcc nekem az meg nem lenne ok valtani, mert csak szivas van vele.
Erezhetoen jobbnak kell lennie. Most semmilyan adatom sincs ami azt mondana mostansag barmiben is jobb.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Én pl LLVM 2.2 óta minden verziót kipróbálok, összehasonlítva az épp aktuális gcc-vel, a tesztprogram az lzma, mert a kód nem triviális, van beépített benchmarkja, és egész számokkal dolgozik (SSE téren még nagyobb az LLVM lemaradása).
Ez alapján mondhatom, hogy az llvm lassabb, emlékeim szerint 5-10%-kal.

(A JIT-et szerettem volna eredetileg kipróbálni, de azt nem sikerült...)

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

Majd biztos válaszol ő is, de véleményem szerint minden váltás szívás. Itt is igaz a mondás, hogy nyertes csapaton ne változtass.

Esetenként egy egyszerű gcc minor verzió ugrás is sok bonyodalommal jár, gondold el mi minden történhet egy teljes fordítóváltásnál.
Az ember csak akkor vállalkozik ilyesmire ha tényleg nagyon megéri.

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

Ohh nyilván. Hiszen van egy működő kódod gcc alatt, ami legjobb esetben is csak egy ugyanúgy működő lesz, rosszabb esetben pedig megmakkan.
Rengeteg esélyt látok a "megkönnyebbült sóhajtás"-ra...

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

> Majd biztos válaszol ő is, de véleményem szerint minden váltás szívás. Itt is igaz a mondás, hogy nyertes csapaton ne változtass

ilyen alapon soha senki nem valtana semmilyen programbol ujabb verziora, megallna a fejlodes. persze ez nem igy tortenik, es pont azert, mert a mondas nem is ezt mondja, hanem arrol szol, hogy mukodo rendszeren folosleges valtoztatni, epp azert, mert mukodik. ha viszont valami nem mukodik megfeleloen (ami lehet siman feature hianya, nem feltetlenul hibakra kell gondolni), akkor nincs mas valasztas, mint tovabblepni, valtoztatni. az llvm is errol szol, legalabbis egyre tobb ember szamara.

> gondold el mi minden történhet egy teljes fordítóváltásnál.

atgondoltam, es nem latom, mi tortenhet meg, ami gcc verzio valtasnal nem. szerinted milyen rettenetes dolgok tortenhetnek ilyenkor?

> milyen rettenetes dolgok tortenhetnek ilyenkor?

pl ilyen hajmeresztő események:

(; gtar cf - ../../openssl | ./bzip2-gcc -9fc > /dev/null; )
32.63s user 0.49s system 101% cpu 32.743 total

(; gtar cf - ../../openssl | ./bzip2-scc -9fc > /dev/null; )
27.41s user 0.49s system 101% cpu 27.468 total

sunstudio-val forgatott bzip2 20%-al gyorsabb mint gcc-vel

"ha viszont valami nem mukodik megfeleloen (ami lehet siman feature hianya, nem feltetlenul hibakra kell gondolni), akkor nincs mas valasztas, mint tovabblepni, valtoztatni. az llvm is errol szol, legalabbis egyre tobb ember szamara."

Pont erről beszélünk, hogy jelen pillanatban szerintem még nincs olyan feature benne ami miatt annyival jobb lenne a gcc-nél, hogy váltsak.
Ha majd lesz, hidd el, váltok. Nem poénból követem a fejlődését 2.2 óta (amikor még clang nem is volt.)

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

( tr3w v | 2010. 04. 19., h – 10:56 )

A clang honlapja szerint se a Boost se a Qt nem fordul rendesen.
Vagy a honlapot nem frissítették, vagy a FreeBSD world-ben nincs túl sok C++ kód...

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


SLOC Directory SLOC-by-Language (Sorted)
2837531 sys ansic=2778251,asm=48503,yacc=4203,awk=3382,lex=1953,
sh=906,python=203,perl=126,sed=4
2676231 contrib ansic=2363184,cpp=141879,sh=95158,yacc=31001,perl=23157,
asm=6552,lex=4836,awk=2681,csh=2123,lisp=1985,tcl=1124,exp=745,python=653,objc=422,sed=324,fortran=321,pascal=86
525144 crypto ansic=476935,perl=22624,sh=11378,asm=9276,yacc=3050,
cpp=1060,lex=711,java=51,awk=35,lisp=24
316583 lib ansic=298532,asm=15470,sh=904,perl=840,yacc=445,
lex=242,csh=141,pascal=9
264874 usr.sbin ansic=253617,sh=6976,yacc=2519,lex=1108,tcl=285,
ruby=268,perl=101
189819 usr.bin ansic=178672,yacc=6450,lex=3178,sh=1456,awk=63
112192 sbin ansic=108366,yacc=1514,cpp=1124,sh=708,lex=431,perl=49
108530 tools ansic=72467,sh=29699,perl=2615,python=1619,ruby=743,
cpp=449,sed=443,asm=267,tcl=191,awk=24,lisp=12,csh=1
84438 cddl ansic=75150,java=3019,sh=2599,perl=1812,lex=860,
yacc=697,asm=301
60793 gnu ansic=58820,sh=1568,perl=284,awk=121
38276 bin ansic=36766,yacc=798,sh=439,lex=154,csh=119
27794 libexec ansic=25546,yacc=1572,asm=580,sh=96
15150 secure asm=12493,ansic=2657
11142 release ansic=8232,sh=2204,perl=537,python=147,awk=22
8824 etc sh=8778,perl=46
8789 include ansic=8789
5935 share ansic=3804,sh=1859,awk=166,tcl=85,perl=13,sed=8
5251 top_dir pascal=5251
4595 games ansic=4517,python=50,sed=13,sh=10,csh=5
1080 kerberos5 ansic=1080
0 rescue (none)

Totals grouped by language (dominant language first):
ansic: 6755385 (92.50%)
sh: 164738 (2.26%)
cpp: 144512 (1.98%)
asm: 93442 (1.28%)
yacc: 52249 (0.72%)
perl: 52204 (0.71%)
lex: 13473 (0.18%)
awk: 6494 (0.09%)
pascal: 5346 (0.07%)
java: 3070 (0.04%)
python: 2672 (0.04%)
csh: 2389 (0.03%)
lisp: 2021 (0.03%)
tcl: 1685 (0.02%)
ruby: 1011 (0.01%)
sed: 792 (0.01%)
exp: 745 (0.01%)
objc: 422 (0.01%)
fortran: 321 (0.00%)

Total Physical Source Lines of Code (SLOC) = 7,302,971
Development Effort Estimate, Person-Years (Person-Months) = 2,278.79 (27,345.50)
(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 10.11 (121.33)
(Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule) = 225.39
Total Estimated Cost to Develop = $ 307,833,712
(average salary = $56,286/year, overhead = 2.40).

suckIT szopás minden nap! iPhone-ból iPad olcsón, házilag

Én ebből azt látom, hogy mennyiségileg sem tartalmaz sok C++ kódot (2%), de én inkább arra gondoltam, hogy amiket tartalmaz azok sem lehetnek túl "bonyolultak".
Mármint C++ compiler szempontból...

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