Clang-gel fordított Linux kernel immár éles rendszereken is

 ( trey | 2017. november 24., péntek - 10:52 )

A Google Pixel 2 telefonok már Clang-gel fordított 4.4-es Linux kernellel érkeznek. Számos Chromebookhoz elérhetők már Clang-gel fordított Linux kernelek a béta csatornában és a legtöbb felhasználónál telepítésre kerülnek még december hónap folyamán. További részletek Matthias Kaehlcke Google szoftvermérnök LKML-re küldött levelében.

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

Flame.
"De ha egyszer olyan baromi jó a GCC, akkor mi a francért akarma bárki is ilyet?"

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

hype

retweeted!!!444.. :)

Nem annyira flame: Miért jobb ez, mint a gcc-vel fordított?

Szerintem egyszerűen meg akarnak szabadulni a gcc-től a build környezetükben. Ehhez egy lépés, hogy ha már a kernelt is tudják
clang-gal fordítani.

"why build the kernel with Clang? To start with, the Android user space is all built with Clang these days, so Google would like to reduce the number of toolchains it needs to support"

https://lwn.net/Articles/734071/

+1.

itt egy (valszeg elfogult, de elgondolkodtató) a Clang vs GCC témában:
https://clang.llvm.org/comparison.html#gcc

Nem hiszem, hogy a "gyorsabb, mint a gcc" volt a fő döntési irány, hanem a "jobban illeszkedik a fejlesztők szükségleteihez":
"Clang is designed as an API from its inception, allowing it to be reused by source analysis tools, refactoring, IDEs (etc) as well as for code generation"

Ez mondjuk engem is érdekelne. Én eddig annyit hallottam, hogy általában gyorsabban fordít, mint a gcc...

Valamivel gyorsabban fordít és valamivel lassabb az így fordított kód. De az eltérés nem jelentős.

volt ido amikor a clang sokkal gyorsabb kodot forditott, de miutan a gcc fejlesztoi lattak hogy lett konkurenciajuk osszeszedtek magukat :)

Egyrészt a gcc fejlesztői összeszedték magukat, másrészt a clang is lassult ahogy kerültek bele új feature-ök.

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

Az, hogy gyorsabban fordít, az egy fontos, de nem elsődleges funkció. Az 1000 másik, amit korábban felsoroltak, sokkal fontosabb.

mai rohano vilagunkban az is szempont lehet. a fejlesztok nem olcsok, sot egyre dragabbak, es az esetek nagy reszeben nem szamit par % kulonbseg az eredmeny sebessegeben, az viszont nem mindegy, hogy a programozo mennyit facebookozik amig var a forditora. volt szerencsem meg 2001 korul dolgozni olyan javas projekten ami 11 perc alatt fordult le/indult el. a fejlesztesi ido jelentos resze varakozassal telt.
de pl. most egy dlib-es c++ fejlesztesnel is egy kb csucs i7 gepen (7820X @ 4.5ghz) gcc-vel kb 1 perc a forditasi ido... megnezem majd kivancsisagbol clang-al, bar nem tudom c++ tamogatasban hogy allnak most...

Ha lesz eredmény, oszd majd meg, kiváncsi vagyok :)

+1 érdekelne az eredmény, hogy az adott kódot 1 perc alatt fordító GCC mennyivel lesz rosszabb, mintha az adott kódot pl. clangos megoldás leforgatja 50s. alatt.

Kérek éves kimutatást, hogy ez a fejlesztésben mennyi hasznot is hoz :) Köszi ^^

mondjuk ha nagyságrenddel gyorsabban fordít ÉS jobb hibajelzéseket ad ÉS sokkal jobban integrálódik a toolinggal ami miatt
gyorsabban lehet fejleszteni, azért az simán kimutatható lehez.

Nincs szó nagyságrendi különbségről fordítási időben.

na tesztelgettem egy kicsit. ubi 17.10, abban 7.2-es gcc es 5.0-as clang van.

dlib es annak examples-e forditasi idok:
dlib 19.7 Release
clang-5.0 -j4
real 0m43.691s
user 2m37.732s
sys 0m4.904s
gcc-7.2 -j4
real 0m34.736s
user 2m1.984s
sys 0m6.016s

examples:
clang -j4
real 2m45.772s
user 10m7.972s
sys 0m10.212s
gcc-7.2 -j4
real 2m48.564s
user 10m34.576s
sys 0m15.640s

sajat kod (dlib-re epul) forditasa es teszt futasi ideje:
gcc-7.2 compile:
real 0m35.300s
user 0m34.772s
sys 0m0.516s
run:
real 0m49.469s
user 1m48.492s
sys 0m39.076s

clang-5.0 compile:
real 0m25.019s
user 0m24.744s
sys 0m0.268s
run:
real 0m45.459s
user 1m38.732s
sys 0m43.664s

itt ha nem is nagysagrenddel, de kicsital mind a forditasi mind a futasi idoben a clang nyert!

de ez egy kicsit becsapos, mert a futasi ido nagy reszet az openblas lib teszi ki, ami binarisan jott deb csomagbol. ezert kiprobaltam ugy is, hogy mindent a dlib-bol hasznalok (jpeg, blas stb):
clang-5.0 compile:
real 0m25.326s
user 0m25.068s
sys 0m0.248s
clang run:
real 6m7.504s
user 5m59.392s
sys 0m8.344s

gcc-7.2 compile:
real 0m34.904s
user 0m34.296s
sys 0m0.592s
gcc run: WTF?
real 68m14.654s
user 68m11.312s
sys 0m8.152s

az addig ok, hogy a dlib sajat BLAS implementacioja nincs optimalizalva (nem is ajanlott azt hasznalni), de hogy ezt a gcc kb 10x lassabb kodra forditsa?

majd ha nagyon unatkozok megnezem mas clang/gcc verziokkal is ugyanezen a vason.

gcc 6.4.0:
dlib compile: 35 sec
sajat compile:
real 0m32.533s
user 0m32.096s
sys 0m0.416s
run time:
real 0m45.734s
user 1m48.356s
sys 0m42.556s

clang 4.0.1:
dlib compile:
real 0m35.451s
user 2m13.452s
sys 0m3.580s
sajat compile:
real 0m24.267s
user 0m24.008s
sys 0m0.248s
sajat run:
real 0m46.322s
user 1m42.528s
sys 0m41.568s

Köszi :)

Kozepesen igenyes vagy annal jobb C++ kodokat teljes magabiztossaggal fordit a Clang++. De lattam olyan projektet, amihez g++ kellett 2017-ben is :(

Azért ez nem csak mai rohanó világunkban szempont, még emlékszem az egy éjszakás "make world"-ökre, vagy épp az Openoffice (akkor még .org nélkül) kb 1 hetes fordítási idejére. OK, akkor nem volt a gépem a csúcs közelében. (Most sincs, de legalábbis van olyan gépem, ami jobb.)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Ez incremental build? Ha nem, miért nem? Ha igen, miért tart egy percig?

mert a dlib 99%-a .h fileokban van implementalva, amit minden cpp filehoz gyakorlatilag ujra parsol es fordit a gcc :(

Ezert jo a verseny ilyen helyzetben is, osztonzoleg hat :-D

Az egyik fo elonye, hogy konnyebben integralhato egyeb toolokkal (az egesz LLVM modularis). Ezt a licensz is tamogatja (beagyazhato(ak a reszei) egyeb toolokba). Ezenkivul konnyebben ertelmezhetoek a hibauzenetei.

----------------------
while (!sleep) sheep++;

A hibaüzenetekről én is tudtam. Nos, amit a g++ néha ki tud dobni magából, az tényleg tragédia. Végigolvastam az LWN cikket, és látszik az is, hogy egy csomó hasznos segédeszköz érhető el hozzá.

Ne feleddjuk, hogy a clangot az Apple tartja karban :)

... még :)
Majd jön a Google saját forkja mint Webkit > Blink forknál.

citation needed

--
trey @ gépház

2014-ig a két fő fejlesztő Apple alkalmazott volt.

Azóta viszont van mindenféle: Intel, Google, Apple, de főleg cég jelölés nélküliek.

Tehát akkor nem az Apple tartja karban. A LLVM Foundation felügyel a projektek felett. Lattner a Google-nél dolgozik, felesége van az LLVM alapítvány élén. Az Apple mint egyik fő szponzor van jelen az alapítvány mögött.

--
trey @ gépház

Licenc az egyik fontos ok. A GCC GPLv3, a CLANG BSD licencelésű.

Pont ezért van OpenBSD kernel az Android alatt is a GPL licences Linux helyett.
Ops! Mégsem.

Valószínűleg a Google-nél kevesebb licenc-fetisiszta van mint a hup-on. Pedig jó sokan dolgoznak a G-nél.

Android esetén az a szabály, hogy a kernelen kívül nem lehet benne GPL-es kód.
Bionic libc, Toybox, mksh - egyik sem GPL.

----
"Kb. egy hónapja elkezdtem írni egy Coelho-emulátort, ami kattintásra generál random Coelho-kompatibilis tartalmat."

Szabály?!
Akkor te többet tudsz mint egy Google fejlesztő. :)
De akkor mi van a Chrome böngészővel vagy a WebView-al, az eléggé alapvető része az Androidnak. És mi van ezekben? Gnu LGPL licencű Blink kódok.
Valami nem ok ezzel a "szabállyal" :-)

Nem tudok többet, csak azt, amit a Google ír:

"We are sometimes asked why Apache Software License 2.0 is the preferred license for Android. For userspace (that is, non-kernel) software, we do in fact prefer ASL2.0 (and similar licenses like BSD, MIT, etc.) over other licenses such as LGPL."

https://source.android.com/setup/licenses

A Chromium nagyobb részt nem-LGPL licenc alatt van:

http://metadata.ftp-master.debian.org/changelogs/main/c/chromium-browser/chromium-browser_62.0.3202.89-1~deb9u1_copyright

A Blink a WebKit forkolása, onnan hozta magával az LGPL licencet.

----
"Kb. egy hónapja elkezdtem írni egy Coelho-emulátort, ami kattintásra generál random Coelho-kompatibilis tartalmat."

"prefer" != "nem lehet benne"
Még szabad fordításban sem.

Akár olyan hibák is kiderülhetnek a kódban, ami eddig gcc-vel nem tűnt fel. Amúgy sem baj, ha többféle fordítóval is lefordul rendesen.

Bizony!
A Linux kód minőségének egyfajta igazolása, hogy gcc mellett clang-gel is lefordítható.

??? Még ha -Wall -Werror flag-ek bekapcsolásával kapcsolatban mondanál ilyet. De csak úgy a levegőben lógva... Erős túlzás, hogy az, hogy 2 fordító is meg tud vele birkózni, az bárminemű minőséget jelentene. (Amúgy pedig fenti elmeveszett ötleted alapján a FreeBSD sokkal jobb minőségét jelzi, hogy ott nem csak a kernel, hanem az egész OS build környezetét sikerült GCC-ról LLVM/Clang-ra migrálni. Az persze nem kérdés, hogy jobb minőségű szoftver a FreeBSD ;-) De hogy nem ezért, az is biztos.)

Az amúgy érdekelne, hogy szerinted megengedhető-e egy kódban a GCC-izm ahhoz, hogy jó minőségűnek tekintsük. Ha valami csoda folytán a "nem" lenne a válasz, akkor melyik C-nyelvi szabvány legyen az elfogadott alap. (Egy mai fordító - még az is lehet -, hogy hibásnak jelezne egy átlagos K&R-féle C-kódot.)

OT: anno volt egy főnököm, aki némi maximalizmustól hajtva szerette volna megkövetelni, hogy olyan kódot adjunk le, amelyiket a lint csont nélkül megeszik. Ez csak addig volt így, míg nem produkáltam neki egy teljesen szabályos "Hello world"-öt, amire morgolódott a rendszer. Ugyanis elég sok múlik a libc és a hozzá tartozó include-fájl gyűjtemény "jóságán" ahhoz, hogy egy ilyet mennyire lehet teljesíteni.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Előbb döntsd el mi a hivatalos álláspontod!
" Erős túlzás, hogy az, hogy 2 fordító is meg tud vele birkózni, az bárminemű minőséget jelentene."

"Ha valami csoda folytán a "nem" lenne a válasz, akkor melyik C-nyelvi szabvány legyen az elfogadott alap. (Egy mai fordító - még az is lehet -, hogy hibásnak jelezne egy átlagos K&R-féle C-kódot.)"

Trivialitás, hogy egy nagy és komplex szoftver módosítások nélkül lefordul két különböző fordítóban, vagy szerencsés kivétel. :)

Már eldöntöttem, és leírtam. Én badarságnak tartom. Tőled meg azt várom, hogy a saját véleményedet próbáld kicsit jobban megmagyarázni, hátha meghajlok érveid súlya alatt.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Te írtál a teljesen szabályos "Hello world"-ödről, amire morgolódott a rendszer. Akkor ez mi volt? Offtopic nosztalgiázás, vagy egy személyes emlék arról mégsem annyira triviális 'A' fordítóval fejlesztett kódot 'B' fordítóval lefordítani?!

Majd gyere vissza, ha utána néztél annak, hogy mi a lint. Ééés igen, offtopic nosztalgiázás volt.

Amúgy még mindig várom a terelések helyett azt, hogy a te definíciód szerint egy kód jó-e, ha van benne GCC-izm.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Itt te terelsz nosztalgiázással, meg a saját kreált fogalmaiddal.
A "GCC-izm" is a saját kreálmányod, válaszold meg magadnak.

Ja, hogy nem érted. Akkor másként kérdem:

szerinted jó kód-e, ami kihasznál olyan nyelvi elemeket, amelyeket semmilyen szabvány nem ismer?

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Cuki érvelési technika amikor saját magad által kreált fogalmakat pufogtatsz, majd a vitapartnered szemére veted, hogy nem érti.

"szerinted jó kód-e, ami kihasznál olyan nyelvi elemeket, amelyeket semmilyen szabvány nem ismer?"

A Linux kernel nem ilyen. Microsoft szokása volt a szabványidegen nyelvi tájszólásokban való fürdőzés. Semmiképp sem tartom jó kódnak az ilyeneket. De például nagyon sok jó Java nyelven fejlesztett szoftver van annak ellenére, hogy máig nem szabványosított a Java.

Amit a szemedre vetettem, az a lint nem ismerete volt. (Hint, wikipedia, lint software). Mihelyt kiderült hogy nem érted a gcc-izmet, leírtam, hogy mit jelent. Tudtommal a gcc-izm / bashizm nem általam kitalált fogalmak, sajnálom, hogy egy ilyen nagy ember, aki megfellebezhetetlenül ki tudja jelenteni, hogy a Linux-kernelben nincs nem-szabványos nyelvi elem, még nem hallott róla. (Akkor már csak az lenne egy idevágó kérdés, hogy ha nincs ilyesmi, akkor mi a francot keresnek ifdef __GNUC__ sorok a kernelben. 4.13.14-es forrást nézek.) Ellenben mivel te ezt ilyen jól tudod, akkor azt is meg tudnád mondani, hogy jelenleg melyik C-szabványt kell követnie annak a földi halandónak, aki ebbe a nagyszerű projektbe be szeretne dolgozni? K&R, vagy épp C++11? Vagy mi?

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

"A Linux kernel nem ilyen."

Hahahaha.

Nyilván nincsenek benne GCCizmusok, ezért telt kb. 4 évbe, mire a Google mérnökei kiírtották belőle azokat, és patcheket adtak, hogy miként lehet egy vanilla Linux kernelforrást clanggal lefordítható állapotba tenni.

A Linux kernel nem teljesen szabványos C-ben van írva, egy, csak a szabványos C11-et ismerő fordító nem tudja lefordítani helyesen a Linux kernelt.

nekem ugy remlik nem a C koddal van a baj, hanem a beagyazaott assemblyt forditja maskepp a clang. ez amugy a gcc-nel is verzionkent valtozik, emlekezzunk meg a gcc 2.96-rol :)

Szabványos C-ben nincs is beágyazott assembly ;)
Azaz bármelyik fordító beágyazott assembly támogatását használod, fordítófüggő és nem szabványos kódot alkotsz.

Sima C esetén nem írja elő a szabvány, de a mellékletben szerepel, C++ esetén a szabvány része, lásd itt.

Tudom én ezt.
A C++ megint más téma.
A melléklet is megint más téma.
Nem bízhatsz benne, hogy ha van egy asm blokkot használó C kódod, akkor azt mindegyik szabványos C fordító lefordítja.

nyilvan a kernel fejlesztoit nem is erdekli mas fordito, nekik boven eleg volt hogy gcc-vel fordul...

https://docs.oracle.com/javase/specs/jls/se8/jls8.pdf

Vagy milyen szabványra gondolsz, ANSI? ISO?

Ezt most csak úgy beírtad ide, vagy van bármilyen alap mögötte?
--
ne terelj