GCC hacky používané v Linuxu (diskuse)

[cbvxcvb]

a prekladal nekdo s uspechem linuxove jadro jinym prekladacem??

[čtenář]

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)

[Zdenek Kotala]

Bohuzel, tyto gccismy prosakly i do standardnich hlavickovych souboru, takze je treba problem prelozit aplikaci s pthredy jinym kompilerem.

[Michal Kubeček]

I've a bad feeling about this…

[roman]

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)

[Michal Kubeček]

Frontend možná, ale co jiné překladače? Nebo je snad cílem dosáhnou toho, aby na Linuxu nešlo používat jiné překladače než ty, které implementují všechna rozšíření, která si vymyslí autoři gcc? Tohle je cesta do pekel, stačí se podívat na udělali Microsoft a Netscape s HTML.

[..... Izak .....]

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.

[Luboš Doležel (Doli)]

Stále je tu například ICC. To dokonce, pokud vím, má lepší výsledky v optimalizaci kódu.

[peto]

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

 

[Luboš Doležel (Doli)]

Ovšem tohle už mi připadá absurdní. Ten kompilátor nemá žádné dominantní postavení, které by "antioptimalizacemi" bylo zneužíváno.

[xm]

To nic nemění na tom, že praktika je to odporná a zavrženíhodná.

[kapo]

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 ;) 

[deda.jabko]

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

[roman]

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

[Michal Kubeček]

I tak trvám na tom, že využívat specifická rozšíření konkrétního překladače u široce rozšířeného software je špatné. Podívejte se, kam to (spolu s dalšími efekty) vede na platformě Windows - píše se buď pro borlandí nebo microsoftí překladač, případně ještě pro různé porty gcc, ale prakticky nic nejde přeložit více než jedním. Jsem proti přístupu "Jde to přeložit gcc, tak je to v pořádku, norma jazyka je přežitek."

[trekker.dk]

Čistota kódu a přeložitelnost všemi překladači je hezká věc, ale pokud to má negativní dopad na výkon, tak se bez toho s dovolením obejdu.

[Mti.]

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.

[Deleted [8409]]

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.

[Miloslav Ponkrác]

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.

[anicka]

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

Že Vám huba neupadne. Stavte se, až budete umět céčko jako tahla řada lidí kolem Linuse Torvaldse.

Pokud nebudete umět recitovat C99 na "chapter and verse" tak jako mnozí z nich, odpustím Vám to.

[Miloslav Ponkrác]

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.

[trekker.dk]

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.

[Deleted [8409]]

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

[trekker.dk]

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.

[Miloslav Ponkrác]

Použít kvalitní kompilátor s kvalitními optimalizačními jednotkami - tedy ne gcc.

[Miloslav Ponkrác]

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

 

[l4m4]

Přijde mi padlé na hlavu, abu se optimalizační jednotka pokoušla identifikovat všech 50 způsobů, jak může programátor implementovat __builtin_clz(), a pak to nahradit efektivním kódem pro danou platformu. Logičtější snad je nechat programátora vyjádřit, co to chce vlasntě udělat: najít nejvyšší nastavený bit. Že takové operace nejsou ve standardu, je problém, ale pro všechny výrobce kompilátorů je snad jednoduché je přidat -- rozhodně jednodušší než zlepšit optimalizační jednotku, aby dokázala identifikovat poznat všechny možné ruční implementace. Nechcete třeba taky, aby si každý programátor sám implemtoval metodu na výpočet gamma funkce a po optimalizační jednotce pak, aby ji rozeznala a nahradila efektivní funkcí?

[Miloslav Ponkrác]

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.

[Deleted [8409]]

• Překladač vám nikdy neudělá optimalizovaný  MMX, SSE, SSE2 kód. Může vám někdy udělat SSE/SSE2 při kompilaci pro tyto stroje, ale většinou to není tak dobré, jak ruční psaní pomocí intrinsics
• Překladač nikdy neví při podmínce, jaký je očekávaný výsledek. Nápověda v tomto smyslu pomůže jak GCC, tak by pomohla i MSVC, avšak souhlasím, že je možné využít profilér k lepšímu výsledku. Toto umožňuje i GCC, pokud vím.
  samozřejmě, překladač může mít databázi funkcí a jejich očekávaných výsledků (např. malloc() asi opravdu nebude vracet často NULL, atd)
• Inline asm začíná být ve vašem vysněném překladači (MSVC) minulost - při kompilaci pro 64 bitů v MSVC už nejde použít, musíte se spolehnout právě na rozšíření překladače

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.

[Miloslav Ponkrác]

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.

[Deleted [8409]]

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 :

• __attribute__ ((noreturn))
• __attribute__ ((regparm(3)))
• __attribute__ ((deprecated))
• __attribute__ ((aligned(N)))
• __attribute__ ((packed))
• __attribute__ ((visibility ("hidden")))
• __attribute__ ((init_priority(N)))

 

[YYY]

Tezko rict, jestli jsou tyto veci dobrym ukazem... Netroufam si soudit.. Tak sakra proc jsem vlastne pisu?

[vencas]

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

[YYY]

Dekuji. Docela zajimave poctenicko

[Miloslav Ponkrác]

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.

[Mti.]

Mate to stylisticky hezky napsane. Vase velmi velmi neco v diskusi ladi ke konstrukci long long int

[Miloslav Ponkrác]

[Anino]

To mi pripomína moju obľúbenú chybovú hlášku:

pok.c:3: error: ‘long long long’ is too long for GCC