Szerdán érkezik a clang/LLVM a FreeBSD HEAD-be

FreeBSD

Roman Divacky tegnap közölte a current@ levelezési lista tagjaival, hogy a clang/LLVM páros június 9-én, azaz jövő héten szerdán kerül importálásra a FreeBSD HEAD-be. A clang lefordítása amd64/i386/ppc platformokon alapértelmezetten engedélyezve lesz, más platformokon azonban tiltva.

A clang "clang"-ként kerül telepítésre, így feltehetően nem fog ütközni semmivel. Lesz kapcsoló (WITH_CLANG és WITHOUT_CLANG) amivel befolyásolni lehet, hogy a clang leforduljon-e vagy sem. A felhasználók szempontjából semmi más változás nem lesz, minthogy a következő buildworld/installworld után eggyel több alkalmazás települ majd. A következő lépés az lesz, hogy a fejlesztők fokozatosan bevezetik azokat a változtatásokat, amelyek ahhoz szükségesek, hogy a clang-gel meg lehessen csinálni egy buildworld-öt, de ezzel kapcsolatban még folyamatban van némi vita.

A bejelentés itt olvasható.

A szekrenyes reszt nem igazan ertem (vagyis de, de hagyjuk).
Az, hogy hany platformot tamogat a clang, csak egy tenyezo a sokbol. A legtobb BSD usert jobban erdekli az, hogy az FSF licenszpolitikai fegyverkent tekint a gcc-re, vagy az, hogy mekkora a ket compiler sebessegenek kulonbsege.
Fejlesztok jo reszet is inkabb az erdekli, hogy a fordito mennyire ertelmes figyelmezteto-/hibauzeneteket dobal.
A helyedben a clang erettseget hoztam volna fel, vagy ennek kapcsan azt, hogy talan korai volt a HEAD-be emelni.
En egyet ertek azokkal, akik szerint a gcc elobb-utobb nyomorult modon el fog pusztulni - a clang elonyei vilagosak.

Hát mondjuk nem pár nagyságrenddel gyorsabb, de apró csúsztatás még belefér. És igen, az a baj, hogy GPL-es. Eddig is baj volt, de nem nagyon lehetett mit csinálni. A GPLv3 pedig már nagyon nem tetszik.

(Amúgy érdekes módon, amikor arról van szó, hogy Linux alatt ilyen vagy olyan licencet szerenek használni, akkor az nem baj. Amikor meg BSD-n mást, akkor az baj. A fene se érti.)

Nem, nem olvastam a szalat, igy csak sajat velemenyem van. Valaki - asszem az undeadly-n - azt mondta, hogy a CLANG/LLVM boszme allat, es nekik az oprendszer szempontjabol a PCC lenne a megfelelo, hisz atlathato meretu, aprocska a kodja (a CLANG/LLVM-mel szemben nyilvan), stb. En szemely szerint a PCC-nek jobban orultem volna ugyanezek miatt (nekem speciel a forditasi sebessege nagyon imponalt anno), de azt el kell fogadni, hogy az oprendszer egeszenek a minel jobb teljesitmenyu kodot eloallitani kepes fordito a jo. Mivel a GPLv3-ra valto GCC elfogadhatatlan a FreeBSD-s hangadoknak, igy egy forditovaltast meg kell lepni. En speciel azt nem latom, hogy mikor lesz ebbol teljes valtas, hisz ha jol olvastam, meg a Tier-1 architekturak mindegyiket se tamogatja (egyebket egyik se a most emlegetett alternativak kozul), a Tier-2-rol nem is beszelve. (Nyilvan valahol ennek - GPLv3 - koszonheto, hogy folyik a textprocessing unGPL-esitese is, de hogy pl. a groffot mikor valtjak ki, azt elkepzelni se tudom.)

En amugy ugy erzem, hogy megint(*) egy politikai dontes szuletett, es nem is a legjobb fajtabol - korai volt meg, de (A'rpi egy korabbi mplayer-es utalasat kolcsonozve) igy nagy valoszinuseggel gyorsabban fognak a hibak kibukni. De en ugy gondolom, hogy 10-es verzio elott nem sok ertelme lesz alapnak betenni. Vagy pedig tegyek a 9.sokX-ben alappa, de ne most, pontosabban akkor nyujtsak meg a 8-as fejlesztesi ciklusat. (Jelenleg nem kovetem, hogy mi az a nagyon extra a 9-esben, amit ha nem backportolnak az nagyon fajdalmas, de nekem az is elfogadhato lenne, ha a 9.0 mondjuk csak 2 ev mulva jelenne meg.)

(*) szamomra hasonloan ertelmetlen politikai(?) dontes volt anno az eredeti csh helyett a tcsh-t, illetve a BSD-s more helyett a less-t beemelni a rendszerbe. (Epp a napokan nezegettem az oldalt, ahol a contrib kodokat tartjak nyilvan, hat van egy-s-mas, ami iszonyat erosen le van maradva, es van ami nagy esellyel a budos eletben nem eri utol az eredeti, azota rendesen tovabfejlesztett verziot. Az a furcsa, hogy a konnyebb karbantartas erdekeben ki tudtak dobni a perl-t, de evek ota megy a gyokoles pl. a Heimdal-lal.

"igy nagy valoszinuseggel gyorsabban fognak a hibak kibukni."

Aki kritizálja a lépést, az szerint pont ez a baj. Nem azt vitatja, hogy a clang/LLVM-nek helye lesz a FreeBSD-ben, hanem azt, hogy miért pont most kell importálni. Ráadásul úgy, hogy előtte azt ígérték azok akik nyomatják, hogy publikus vita lesz róla, helyette pedig tényként közölték, hogy 9-én import lesz. (itt)

--
trey @ gépház

Az a kevés amit olvastam, azt írja, egyelőre az import annyit tesz, lesz még 1 plusz települő utility. Gondolom a következő lépes az lesz, hogy lesz egy flag, amit ha beállítok, akkor clang fordít alapból. Ezt nyilván sok 9.x-et használó megteszi, hogy beállít, és gondolom a sok-sok (kevés-kevés) visszajelzés függvényében egyszer ezt a jelzőt átbillentik. Aztán kb 3 év múlva kidobják a gcc-t (valszeg több is lesz az 3-nál, hisz amíg nincs minden támogatott architektúrához llvm kódgenerátor, addig semmi értelme).
A nagy kérdés, hogy mikor billentik a jelzőt. Ha már egyébként bekerül, én jó ötletnek tartanám a 8-as backportot is, azért azt több ember nyúzza. (Desktopon simán bevállalnám a clang-ra áttérést, szerveren egyelőre nem; viszont egyelőre egyetlen embert ismerek, akiről tudom, hogy 9.x-et használ desktopként.)

kemény érvek ezek. a gcc azért szar mert gplv3 licences. gratulálok!:)
linux kernel alapú rendszerből eléggé sok van a BSD világ hagyományaival szemben. igen sok disztribúció nagy ívben tesz a licencekre, és a hatékonyság a kiemelt szempont. még olyan fura mutánsok is vannak, mint a sta.li, amely nélkülözni próbálja a glibc használatát is.

Gartulalj annak, aki azt mondta, hogy azert szar, mert gpl-es. (szar != baj) En - szerintem - azt mondtam, hogy nem annyival jobb, mint azt fentebb allitottak, es mivel van alternativaja (vagy legalabbis vannak akik annak latjak) - es raadasul gpl-es is, ami *itt* sajnos negativum, tehat ki szeretnek valtani.

ha ezt te érvelésnek nevezed, csak sajnálni tudlak.
mellesleg eléggé bezárhattad magad a saját világodba, ha úgy gondolod ez a "diplomázás" téged jobb színben tüntet fel. még ha vannak is problémák a mai felsőoktatással, elsősorban bologna miatt, ettől még a széles többség szemében igenis van értéke a diplomának.

A GPL "osszeferhetetlenseg" habar a fo, de nem egyetlen oka a valtasnak. Az llvm kodja tiszta, modularis, jol olvashato (vo. gccvel). A generalt kod minosege pedig javul, a kerdes csak az, hogy mikor eri be a gcc-t; (a par nagysagrenddel gyorsabb reszt szerintem te sem gondoltad komolyan).
A gcc "jo volt" 25 evig, de nem fog meg 25ot kihuzni - clang/llvm-rol ilyet nem mondanek.

én az ilyen kijelentéseid alátámasztására gondoltam, mint
llvm kodja tiszta, modularis, jol olvashato (vo. gccvel). A generalt kod minosege pedig javul.
a benchmark pedig épp a gcc előnyét hozta ki futási időben. bár ezt valóban nem is említetted a clang/llvm előnyei között.

Vagy az zavar teged ossze, hogy konzekvensen atvettem Lory tevedeset, es a kod minoseget azonositottam a futasi idejevel, vagy nem tudod kulonvalasztani azt, hogy az llvm/clang-nek tisztabb, egyszerubben olvashato a kodja (mint a gccnek), attol, hogy az altala generalt kod minosege javul (gyorsul is - a gcc-nel nagyobb utemben).
Valoszinu en fogalmaztam pongyolan.

a futási idő kérdését eddig is külön választottam. gyengének tartom azt az érvelést, hogy a z llvm/clang-nek tisztabb, egyszerubben olvashato a kodja (mint a gccnek), mert c4nn1b4l ezt nyilatkozza. ne vedd személyeskedésnek, bárki állítaná csak úgy ez lenne a válaszom. a kódminőség egyébként is amorf, szubjektív fogalom.
a jó kódminőség ismérvei imho,
jó áttekinthetőség
logikus felépítés
tömörség, természetesen a feladathoz mérve

ezek egyik következménye a könnyű portolhatóság platformok között. az összehaxxolt, gányolt, spagettikódokat jellemzően nem, vagy csak igen nehezen lehet portolni egy újabb platformra, legyen szó akár más software vagy más hardware platformról.
a megbízható működést azért nem írtam, mert annyira alapvető, beugró feltétel is lehetne.
vannak kódelemző eszközök, már ezek objektivitása is gyakran vitatható.
de bármi konkrétum jöhet, ami alátámasztja a fenti állításodat. természetesen objektív, megismételhető mérésen alapuljon, legalább részben. különben ez a kijelentés csak a levegőben lóg.

már megfogadtam, nem fogok egy érettségis megmondóemberke, Nagyapa szintjéhez konvergáló szösszeneteire válaszolni. itt most csak a szál átláthatósága érdekében, az előzőekhez kapcsolódva,

a NICTA majd egy éve, formális módszerekkel igazolta, a seL4 mikrokernel 7500 C kódsorának helyességét. ez már garantálja az objektív szemléletű "jó kódminőséget" is. de hasonló igazolás egyik fordító esetében sem áll rendelkezésre, és a közeljövőben nem is várható.
ezért a "kódminőségről" való további vitának nem látom értelmét. szubjektív érveket nem érdemes ütköztetni ebben a témában.

Egyaltalan nem veszem szemelyeskedesnek.
"jo attekinthetoseg"
"logikus felepites"
"(..)objektív, megismételhető mérésen alapuljon, legalább részben. különben ez a kijelentés csak a levegőben lóg."
Ahogy lentebb is irtad, nem valoszinu, hogy a kozel/tavoli jovoben barki is formalis modszerekkel igazolja valamelyik forditot, a "kodelemzo eszkozok eredmenye is vitathato", ugyhogy nem tudom, hogy mit varsz.
Ennek ellenere szemikvantitative te is megnezheted a kodjukat - mennyire olvashato, mennyire "elegans"; esetleg kinyomtathatod - megnezni melyik compiler kodja fogyaszt tobb nyomtatofesteket/papirt, etc.
Konkretummal nem tudok szolgalni - marad minden velemeny szinten.

tesztelgettem kicsit:
http://thot.banki.hu/arpi/hdaudio/source_v27beta/
(a libdca-t is az alabbi compilerekkel forditottam, es statikusan linkeltem)

time ./resample -pal 1.dts /dev/null

llvm-2.8.r104832 clang-al forditva:
real 3m50.096s
user 3m49.906s
sys 0m0.200s

gcc 4.3:
real 3m27.410s
user 3m27.109s
sys 0m0.256s

gcc 4.4.4:
real 2m50.119s
user 2m49.895s
sys 0m0.232s

hangsulyozom: ez a leforditott kod futasi ideje (tehat melyik compiler mennyire jol optimalizal), es nem a forditas ideje! mindegyiket 2x futtattam, az elteres 2s-en beluli volt.

a futasi ido kb felet a dts dekoder (libdca) teszi ki, ebben nincs semmi asm kod, pure C. az ido masik fele a resample resz, ez a http://www.mega-nerd.com/SRC/ libsamplerate kodja kicsit optimalizalva, de ez is pure C, semmi asm.

ez alapjan a clang engem nem gyozott meg, a gcc 4.4 annal inkabb.

A'rpi

megprobaltam de nem akarodzik lefordulni... a pcc meg lefordul de a pcc-libs nem, anelkul meg a pcc nem mukodik. include fileokkal all hadilabon, es lehetetlen errorokat ir ki, pl:

/usr/include//asm-generic/siginfo.h, line 58: array size cannot be negative
bits64/softfloat.c, line 332: cannot recover from earlier errors: goodbye!

meg a masik, mikor a limits.h 150. soraban lat errort, pedig az egy 30 soros file...

A'rpi

igen, a 20 evhez kepest nagyon jol allnak mar most is, kb a 4.1-4.2-es gcc-vel van egy szinten, ami azert nem olyan regi. nagyobb baj, hogy par fontos gcc extensiont nem implementaltak es nem is nagyon tervezik, pl. nested functions, #pragma align stb.
igy azert nehez lesz a gcc-t lecserelni teljesen.

A'rpi

Ezert szallit minden toolchain magaval sajat libc-t, GCC/MinGW nem tudja megenni a Visual C libjeit erdekes modon, aminek nem is orulok, szallitja a sajat .a es .o filejait pluszban. Pedig C alatt standard az ABI, mig C++-nal a name mangling miatt sem keverhetok a forditok (ezzel is milyne szivasaim voltak mar...)

wtf?
visual c libjei != libc. es ponthogy a mingw meg tudja enni, csak le kell tolteni a microsofttol az SDK-t, mert azt hasznalja. a cygwin ami sajatot szallit, de az egy komplett linux emulacios reteg, nem csak egy libc.

szerintem amire te gondolsz, az a libgcc / pcc-libs / msvcrt stb, ami egy mininal kod (par kB) es az exe inicializaciojat es a main() meghivasat tartalmazza, na ilyen van minden compilernek, de ennek meg 0 koze van a libc-hez.

A'rpi

direkt olyan kodot valasztottam a tesztre, ami gyakorlatilag 99%-ban matekolas, szamolasbol all, es az is pure C, nem assembly betetek mint pl. egy ffmpeg/mplayer lenne.

raadasul jol optimalizalhato dolgok, dct, matrix muveletek, 6 csatornan parhuzamosan (tombon) vegzett ugyanolyan muveletek. ezt egy jo compiler nagyon meg tudja optimalizalni.
pl. megneztem -O0 opcioval gcc 4.4.4-el, es ugy 8 perc alatt fut ugy le, tehat kb 3x lassabb mint -O3-al.

libc hivas nyilvan van egy par, de az elnyeszo, foleg mivel egy kis (200mb) filet olvasok ami egyebkent is cacheben van, es devnullba irok.

A'rpi

( therion | 2010. 06. 05., szo – 19:02 )

Amúgy lehet hogy hülyeség, annyira nem értek hozzá, de éppen nemrég jutott eszembe, hogy mivel ugye az LLVM (ahogy a neve is mutatja) képes a bájtkódot is interpretálni (mondjuk azt nem tudom mennyire van erre optimalizálva), akár managed operációs rendszert is lehetne rá építeni, hasonlóan az MS-féle Singularity-hoz.

( arpi_esp v | 2010. 06. 05., szo – 22:36 )

"jövő héten szerdán került importálásra"

Roman Divacky egy idoutazo? :)

A'rpi