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

Kernel

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.

( manfreed (nem ellenőrzött) | 2017. 11. 24., p – 12:35 )

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"

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

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

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?

( Hevi v | 2017. 11. 24., p – 20:35 )

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

( uid_6201 v | 2017. 11. 25., szo – 13:38 )

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

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-browse…

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

( xian v | 2017. 11. 25., szo – 23:20 )

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.

??? 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. :)

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?

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.