Portál AbcLinuxu, 27. července 2025 17:27
a prekladal nekdo s uspechem linuxove jadro jinym prekladacem??
Pokud vím, tak s několika drobnými úpravami je možné přeložit jádro pomocí Intel C++ Compiler. Na stránkách Intelu jsou další informace, hledej, šmudlo, hledej 
(Ne, vážně, myslím, že tohle bylo ono: http://download.intel.com/support/performancetools/c/linux/sb/linuxkernelbuildwhitepaper.pdf)
Bohuzel, tyto gccismy prosakly i do standardnich hlavickovych souboru, takze je treba problem prelozit aplikaci s pthredy jinym kompilerem.
spousta z tech gcc rozsireni bude v pristim C standardu.... nevidel bych to jako extremni problem, navic kazdy rozumny C frontend
dneska chape ze musi podporovat gnu extensiony (viz. clang)
Ano je to nutny napad, protoze zadny jiny prekladac se uz moc nevyviji a hlavne nereaguje na moderni pozadavky, kor pro linux/unix, dnes uz se i na unixech vse krom jejich kernelu a modulu preklada GCC, tedy i aplikace.
24.11.2008 13:33
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
>, má lepší výsledky v optimalizaci kódu.
na Inteloch ano, ale jednym z bodov obzaloby EU na Intel je to, ze kod Icc v kode pre AMD dava desiatky NOPov v kazdom cykle, ktory zbehne viac nez 10x
24.11.2008 15:51
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Nema sice dominantni postaveni, nicmene pokud jim jsou kompilovany pouzivane benchmarky a pak jsou prezentovany jejich vysledky, tak to ma tak trochu vliv na hodne veci ;)
pred casem jsem si delal srovnani a na ansi c je rychlost gcc a icc srovnatelna (obcas je i gcc vyrazne rychlejsi)... c++ nesnasim... tak jsem ani mereni nezkousel...
frontend ve smyslu "fronted prekladace", takze ten tvuj komentar nedava smysl :)
napr. ten clang (coz je fornted llvm, tj. dohromady plnohodnotny prekladac) gcc extensiony implememtuje, tj. tim
vyhledove linux zkompilovat pujde
I kdyby se vsichni programatori shodli na jednom jedinem spravnem jazyce, vzdy se pak objevi spousta tech, kteri uvedou ten svuj jeden jediny spravny jazyk, s ostatnimi nekompatibilni.
Hehe, já jsem začínal na Borlandu a když jsem pak poznal linux a začal tam zkoušet C++, tak jsem marně hledal něco jako __clusure, to bylo celkem zajímavé rozšíření na nostalgiskou dobu Win95 (Borland C++ Builder 1.0).
Ale jinak samozřejmě souhlas. Nejlepší je, když píše kód někdo, kdo zná GCC i MSVC, to je pak kód přenositelný na velmi vysoké úrovni.
Já s tím také souhlasím. 99,99% programů nepotřebuje nic víc, než je v ANSI standardu C. Nijak to nezvýší výkon programu ani nic jiného. Ono je to tím, že napříakld tady na abclinuxu.cz řada lidí dokazuje, že C, nebo C++ je špatné na gcc/g++, a neuvědomují si ani vůbec rozdíl mezi jazykem a jedním kompilátorem. Řada lidí kolem linuxové komunity včetně Linuse Torvaldse ani netuší, jak vypadá standardní programovací jazyk C, znají jenom gcc dialekt včetně extenzí, ale nebyla by vůbec schopná napsat C kód vyhovující normě.
Zisk vyplývající z gcc rozšíření se velmi vysoce nadhodnocuje (včetně výkonnostních zisků), protože často jde totéž co s gcc extenzí dosáhnout i se stadardním C kódem.
Já myslím, že po dvacetileté praxi (v C/C++ přes deset let takových 10 a více hodin denně) si tu hubu celkem otevírat můžu.
A to, že Linus Torvalds by neuměl napsat ve standardním C ani čárku si stojím. A to co vykládal o C++ mě předsvědčilo, že je v C++ naprostý hochštapler, ale o tom tu řeč nebyla.
To, že někdo umí něco citovat, neznamená, že to umí taky používat.
A některé Linusovo speciality stylu prosazování void free (const void*), z toho se mi chce zvracet.
Zisk vyplývající z gcc rozšíření se velmi vysoce nadhodnocuje (včetně výkonnostních zisků), protože často jde totéž co s gcc extenzí dosáhnout i se stadardním C kódem.Tak nám předveď, jak dosáhneš stejného výkonu bez
__builtin_expect (nápověda pro predikci podmíněného skoku)
Doufám teda, že ti dneska Mars v konjunkci s Neptunem v souhvězdí Nosorožce nepředpověděly, že úspěšnost predikce skoku nemá na výkon vliv a že se o tom tudíž nebudeme dohadovat.
Já to řeším takto:
#if defined(__GNUC__) #define CORE_LIKELY(exp) __builtin_expect(!!(exp), 1) #define CORE_UNLIKELY(exp) __builtin_expect(!!(exp), 0) #else #define CORE_LIKELY(exp) exp #define CORE_UNLIKELY(exp) exp #endif
Takto to sežere i MSVC, ale nebude optimalizovat (je nutné profilovat kód). Na druhou stranu mám zkušenosti takové, že MSVC stále produkuje rychlejší a hlavně o dost menší binárky než GCC (nastavené srovnatelné flagy pro optimalizace a generování kódu).
Na druhou stranu mám zkušenosti takové, že MSVC stále produkuje rychlejší a hlavně o dost menší binárky než GCC (nastavené srovnatelné flagy pro optimalizace a generování kódu).Jasně, ale to už se bavíme v rovině porovnání překladačů mezi sebou. Mě zajímalo, jak podle astrologa dosáhnout stejné funkce bez použití __builtin_expect, tedy jak gcc (nebo jinému překladači) říct pomocí čistého a standardního C, že tady se asi bude/nebude skákat. Profilování moc neberu, protože vím, že v kódu
p = malloc();
if (p == 0) {
je ta podmínka naprosto jasně unlikely a tudíž nepotřebuju trávit čas čekáním na výsledky profilování, aby mi to plechová huba potvrdila.
Použít kvalitní kompilátor s kvalitními optimalizačními jednotkami - tedy ne gcc.
Tak nám předveď, jak dosáhneš stejného výkonu bez __builtin_expect (nápověda pro predikci podmíněného skoku)
Víte, co je největší legrace? Že kompilátory typu msvc a icc vygenerují daleko optimalizovanější strojový kód ze zdrojáku i bez této nápovědy, než gcc s těmito nápovědami. Optimalizace byla vždy především věcí kompilátoru/linkeru a jeho optimalizačních jednotek, které analyzují kód. Zdůrazňuji, že dnes je prováděna kvalitními kompilátory optimalizace a analýza kódu jako při kompilaci, tak při linkování (když vlastně občas ani není jasné, co je která fáze, protože i linker dostává v objektovém souboru trochu více informací, než tomu bylo v dřívějších letech - gcc to ostatně částečně dělá také).
Dříve třeba byly optimalizátory C překladačů tak špatné, že třeba bylo třeba mu napovídat slovy register (což je dneska už v 99,9999% případů zbytečné a kompilátor to udělá sám). Stejně tak tyhle i dnešní nápovědy jsou v kvailtním kompilátoru kontraproduktivní, protože kvalitní analýzou to kompilátor udělá lépe, než člověk - zejména v kódu o miliónech řádků.
Je jedno, co je logičtější - jedno je ale jasné - optimalizátor kvalitního kompilátoru dává setsakra lepší výsledek, a výrazně rychlejší a optimálnější kód, než všechny biuitin nápovědy. Ona je totiž taky sranda, že leccos závisí na výsledné platformě, procesoru, ba i přepínačích kompilace. Proto kompilátory jdou jednoznačně cestou, že nápovědy ohledně optimalizace od programátora jednoduše ignorují - protože to samy svými analyzátory kódu a optimalizacemi zvládnou lépe. Až někdy (za delší dobu) zlepší GCC optimalizátor na kvalitu alespoň MSVC, pak první co udělá, že bude builtin nápovědy ve zdrojovém kódu naprosto ignorovat.
Kvalitní kompilátor poznáte tak, že si nenechá napovídat, jak má tvořit stroják - a pokud takové nápovědy syntakticky rozpoznává, pak je jednoduše ignoruje a vůbec je nebere v úvahu.
Můžete vymyslet milióny algoritmů, které byste chtěl přilepit do standardu, ale ono je lepší mít v kompilátoru pořádnou a kvalitní optimalizační jednotku, která obsáhne všechny algoritmy. Kvalitní kompilátor dává jednu možnost, jak oblivnit výsledný stroják - vložit inline assembler.
Neříkám, že všechny rozšíření stojí za to, ale při použití trochu maker, je to další cesta, jak udělat kód ve výsledku více optimalizovaný než bez nich.
Ad 1) Jste si jist?
Ad 2) Překladač to má šanci zjistit. Navíc na rozdíl od člověka se překladač obvykle neplete. Vzhledem k tomu, že kompilítor prostředky ke 100% zjištění jak to je má (analyzér kódu, optimalizátor, linker, profiler, a řadu dalších) - nepřinášejí tyhle nápovědy kromě falešných iluzí a více práce plus snížení pltfromní nezávislosti vůbec nic. A to nemluvím o tom, že při špatné nápovědě (a člověk není na rozdíl od stroje neomylný - takže jich nebude v kódech málo) dostane pomalejší kód.
Ad 3) V 64 bitech je jenom otázkou času, než inline asm bude. Stále je možnost napsat asm modul, byť s režií volání funkce.
Skoro žádné rozšíření nestojí za to. A pokud kompilátor dává lepší výsledek při použítí extenzí s nápovědou, jak má optimalizovat, je to známka toho, že to není až tak dobrý kompilátor, a že nedobře optimalizuje, Nic víc, nic méně.
Neříkám, že občas nejsou rozšíření, které mají smysl - ale nikdy to nejsou rozšíření, které pomáhají kompilátoru k optimalizaci - vyjma inline asm. Smysl mají rozšíření, které třeba předepisují volací konvenci funkcí, chcete.li se napojit na cizí API například.
Problém vidím v tom, že vy se pořád spoléhate na jeden překladač. Existují projekty, které jdou přeložit na různých platformách a různých překladačích a každá možná optimalizace ve formě maker (likely, unlikely, specifické inline funkce pro atomické operace, atd) je dobrá, protože těm méně kvalitním překladačům může pomoct vytvořit víc kvalitní kód.
1) Jsem, napsal jsem hodně grafických rutin a můžu vám říct, že překladač prostě nemá šanci zjistit, že děláte alpha blending, a že by mohl ze současnou optimalizací např. pro i586 použít MMX, atd. Vím, že je to specifická věc, ale o tom se tady bavíme, ne ?
2) K tomu bych jen napsal jednu věc. Nikdy nepotřebujete optimalizovat celý program, ale vždycky se všechno točí kolem dobře známých kritických míst, takže použít ve 20 podmínkách likely/unlikely není podle mě žádný velký problém a může to zrychlit kód. Pokud se bavíme o knihovnách pro linux, které například používá spousta dalších knihoven a programů, jsem za každou optimalizaci rád, nehledě na její původ.
3) Já jsem četl, že se to neplánuje, ale to je asi rok. Ale podle mě to ani není potřeba, compiler intrinsics se dají používat jak v GCC tak MSVC (a samozřejmě ICC), tak 32/64 bitech, takže volba pro psaní specifických věcí je jasná.
skoro žádné rozšíření nestojí za to
Přijde mi, že odsuzujete něco, o čem jste si přečetl jen málo, nebo automaticky zavrhl na základě osobního postoje. Co třeba tyto :
No, myslím že užitečné jsou. Ještě bych uvítal, aby to jako extensions podporovalo věci, které zatím nejsou v c++, ale časem budou (jako třeba reflexe a multimetody), místo toho, aby ve chvíli schválení c++0x se terpve nové věci implementovaly (lambda funkce, koncepty etc)... Bohužel jsem se ve vnitřnostech gcc raději ani nepokoušel vyznat, abych aspoň něco z toho udělal sám (stačí se podívat na gcc.gnu.org/projects/beginner.html a hledat "break up enormous conditionals"...).
Já myslím, že extenze veskrze užitečné nejsou. Kromě velmi vyjímečných případů, asi tak 1000x řidším, než se používají kolem Linuxu a gcc.
C++ nepotřebuje extenze - C++ je tak mocný jazyk, že v něm napíšete téměř cokoli, včetně skoro všech budoucích extenzí. Taková knihovna, která implementuje co bude v C++0x existuje - jmenuje se boost - a používá zcela standardního C++. Mimochodem, celý C++0x také víceméně vzniká tak, že se nové features C++ nejdříve implementují v boost knihovně (pomocí zcela standardního C++) a když se líbí a osvědčí, zařadí se do budoucího standardu C++0x.
C++ je velmi velmi mocný jazyk - umožňuje v něm (v jeho standardní verzi zcela bez extenzí) napsat velmi velmi mnoho. Většina věcí, co jste četli o C++, a většina lidí pohybující se kolem C++ zná s bídou sotva několik procent možností tohoto jazyka zcela ve standardní verzi.
Mate to stylisticky hezky napsane. Vase velmi velmi neco v diskusi ladi ke konstrukci long long int 
To mi pripomína moju obľúbenú chybovú hlášku:
pok.c:3: error: ‘long long long’ is too long for GCC
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
