- A hozzászóláshoz be kell jelentkezni
- 886 megtekintés
Hozzászólások
Ez már a vég, előbb az ia64 kódokkal se foglalkoznak, mostmár az icc -vel mi jön még ? A régi jó dolgokból nem marad semmi :D
Fedora 42, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
Életemben nem vetemedtem olyasmire, hogy Intel fordítóval fordítsak kernelt és valószínűleg ennek az az oka, hogy sose gondoltam, hogy kétes hatékonyságú vélt optimalizálások oltárán fel kellene áldozni egy százezrek által használt, kitesztelt fordítóprogramot. Valójában sosem értettem, hogy mi célja volt annak, aki az ICC támogatás beolvasztását kisírta. Mármint, hogy az Intel-en kívül ez kinek hozhatott volna bármit is.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Nem Linux kernel, de a napokban gondolkodtam el egy másik projekt kapcsán, hogy vajon mennyit tudna optimalizálni (sebesség, méret), ha ICC-vel fordítanám. A hosszabb fordítási idő nem lenne kritikus, ha kompaktabb, gyorsabb fordítási egységeket hozna létre.
- A hozzászóláshoz be kell jelentkezni
Gondolati szinten ragadtam vele, de ezek után csak azért is előveszem a projektet és gyakorlatban is kipróbálom ICC-vel. :D
- A hozzászóláshoz be kell jelentkezni
Ennek az eredménye erősen érdekelne engem is!
- A hozzászóláshoz be kell jelentkezni
https://developer.ibm.com/articles/gcc-profile-guided-optimization-to-a…
Ha a progidat keresztul tudod vinni ezen, akkor gyorsabb mint az icc, legalabbis az volt a reges regen.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Nem az ICC támogatást kellene dobni, hanem végre bekapcsolni a -pedantic -ansi opciókat...
De esetleg még a -std=c99 is lehetne.
Apropó, mi a helyzet a tcc-vel? Azzal fordul még?
- A hozzászóláshoz be kell jelentkezni
10 tonna fos kódot nem könnyű egyik napról a másikra átmonyókolni, szóval szerintem ez elég felejtős.
- A hozzászóláshoz be kell jelentkezni
A bekapcsolással az a baj, hogy a fordítási kimenet mérete nagyságrenddel nőne. :D
- A hozzászóláshoz be kell jelentkezni
Most komolyan, mikor fordítanád tcc-vel? Szerintem senki nem forgatná azzal. Persze értéke lenne elméletileg ha szigorúan C99 kompatiblis lenne, de annyit munkát nem érne. Nincs rá senkinek oka, hogy ne a gcc-vel vagy llvm/clang-gal fordítsa, azokat a fordítókat legalább a mai napig aktívan fejlesztik, optimalizálják.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Azért fordítanám tcc-vel, mert lehet. A szabvány arról szól(na), hogy lefordíthatod bármelyik fordítóval.
Nem tudom elképzelni, hogy mi lehet az a baromi sok GNU extension, amik nélkül nem lehet egy kernelt megírni. Ugyanakkor nem is vagyok kernelfejlesztő (bár néha bele kell tákolnom, de hát az a kernel 0.000000001%-a lehet).
- A hozzászóláshoz be kell jelentkezni
De, meg lehet írni, csak használnak újabb C sztenderdet, plusz gondolom az is számít, hogy a gcc/clang toolchain jobban egyben van, mindenféle tool. Mondom, nekem pedig tetszene is, ha tcc-vel lefordulna, jó kis minimalista, anti-bloat fordító, csak kérdés, hogy az elméleti megelégedésen kívül mennyi haszna lenne, kinek mennyi munkát érne meg.
A tcc-t már nem fejlesztik, meg nincsenek hozzá extra optimalizációk, amik a modern hardver extra utasításkészleteit kihasználnák. Valami nagyon retró gépen biztosan coolabb, de modern platformokon, ahová a Linux kernelt szánják, ott nem sokat adna hozzá, sőt, lehet visszalépés lenne teljesítményben.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni