- A hozzászóláshoz be kell jelentkezni
Hozzászólások
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?
- A hozzászóláshoz be kell jelentkezni
hype
- A hozzászóláshoz be kell jelentkezni
retweeted!!!444.. :)
- A hozzászóláshoz be kell jelentkezni
Nem annyira flame: Miért jobb ez, mint a gcc-vel fordított?
- A hozzászóláshoz be kell jelentkezni
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"
- A hozzászóláshoz be kell jelentkezni
+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"
- A hozzászóláshoz be kell jelentkezni
Ez mondjuk engem is érdekelne. Én eddig annyit hallottam, hogy általában gyorsabban fordít, mint a gcc...
- A hozzászóláshoz be kell jelentkezni
Valamivel gyorsabban fordít és valamivel lassabb az így fordított kód. De az eltérés nem jelentős.
- A hozzászóláshoz be kell jelentkezni
volt ido amikor a clang sokkal gyorsabb kodot forditott, de miutan a gcc fejlesztoi lattak hogy lett konkurenciajuk osszeszedtek magukat :)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Az, hogy gyorsabban fordít, az egy fontos, de nem elsődleges funkció. Az 1000 másik, amit korábban felsoroltak, sokkal fontosabb.
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
Ha lesz eredmény, oszd majd meg, kiváncsi vagyok :)
- A hozzászóláshoz be kell jelentkezni
+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 ^^
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Nincs szó nagyságrendi különbségről fordítási időben.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Köszi :)
- A hozzászóláshoz be kell jelentkezni
Kozepesen igenyes vagy annal jobb C++ kodokat teljes magabiztossaggal fordit a Clang++. De lattam olyan projektet, amihez g++ kellett 2017-ben is :(
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
Ez incremental build? Ha nem, miért nem? Ha igen, miért tart egy percig?
- A hozzászóláshoz be kell jelentkezni
mert a dlib 99%-a .h fileokban van implementalva, amit minden cpp filehoz gyakorlatilag ujra parsol es fordit a gcc :(
- A hozzászóláshoz be kell jelentkezni
Ezert jo a verseny ilyen helyzetben is, osztonzoleg hat :-D
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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á.
- A hozzászóláshoz be kell jelentkezni
Ne feleddjuk, hogy a clangot az Apple tartja karban :)
- A hozzászóláshoz be kell jelentkezni
... még :)
Majd jön a Google saját forkja mint Webkit > Blink forknál.
- A hozzászóláshoz be kell jelentkezni
citation needed
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Licenc az egyik fontos ok. A GCC GPLv3, a CLANG BSD licencelésű.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
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" :-)
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
"prefer" != "nem lehet benne"
Még szabad fordításban sem.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Bizony!
A Linux kód minőségének egyfajta igazolása, hogy gcc mellett clang-gel is lefordítható.
- A hozzászóláshoz be kell jelentkezni
??? 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?
- A hozzászóláshoz be kell jelentkezni
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. :)
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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?!
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
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 :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
nyilvan a kernel fejlesztoit nem is erdekli mas fordito, nekik boven eleg volt hogy gcc-vel fordul...
- A hozzászóláshoz be kell jelentkezni
https://docs.oracle.com/javase/specs/jls/se8/jls8.pdf
Vagy milyen szabványra gondolsz, ANSI? ISO?
- A hozzászóláshoz be kell jelentkezni
Ezt most csak úgy beírtad ide, vagy van bármilyen alap mögötte?
--
ne terelj
- A hozzászóláshoz be kell jelentkezni