C# je rychlejší než C/C++?

[Jakub Galgonek]

Tohle odporuje strict aliasing rules

Ale strict aliasing je v C až od verze C99, ne? Prostě se přidalo omezení v tom, co může programátor dělat, aby se mohlo lépe optimalizovat. To jen tak na okraj k té poznámce C vs. assembler, co tu zazněla.

[Reklama]

[gamer]

Ale strict aliasing je v C až od verze C99, ne? Prostě se přidalo omezení v tom, co může programátor dělat, aby se mohlo lépe optimalizovat. To jen tak na okraj k té poznámce C vs. assembler, co tu zazněla.

Je to až od C99, což je ale už poměrně stará verze. gcc -O2 s tím počítá a kód který nedodržuje strict aliasing nefunguje, nicméně většina lidí to neví.

[prezek]

Zkus do zdrojáku přidat volatile (volatile int n = 0;) a pak to C přeložit s optimalizací. Tím by se mělo zabránit kompilátoru, aby zahodil celý cyklus, Jinak se to moc porovnávat nedá.

[Jakub Galgonek]

Zkus do zdrojáku přidat volatile (volatile int n = 0;) a pak to C přeložit s optimalizací. Tím by se mělo zabránit kompilátoru, aby zahodil celý cyklus, Jinak se to moc porovnávat nedá.

Když zapne volatile, tak se bude n neustále synchronizovat s pamětí - v každé iteraci se přečte aktuální hodnota n z paměti, přičte se jedna a výsledek se zase zapíše do paměti. Tím to totálně pohřbí.

[prezek]

může dát volatile do C i C#, nebo ne? Já nemám možnost C# vyzkoušet, ale k nějakému zrychlení C připsáním volatile a optimalizací došlo. Ještě lepší výsledek má ale:

Kód: [Vybrat]

int main() {
  int n = 0;
  for (int i = 0;  i < 999999999;  i++) {
  __asm("nop");
    n++;
  }
} u mě vychází zhruba poloviční čas s optimalizací -O2 oproti původnímu zdrojáku bez optimalizace.

[Reklama]

[Jakub Galgonek]

u mě vychází zhruba poloviční čas s optimalizací -O2 oproti původnímu zdrojáku bez optimalizace.

Ono je hlavně to, o co se tazatel pokouší, docela kravina. Porovnávat dobu běhu, ale házet optimalizátoru klacky pod nohy je na nic.

[Ivorne]

Úplně nesmyslné téma. Chtěl bych rozepsat proč, ale to fakt nemá cenu. Sry za zbytečný příspěvek, něco jsem napsat fakt musel

[pravdokop]

Ano, zapnutie optimalizatora v tomto pripade je skutocne cheatovanie, pretoze ucel testu je porovnat KTORY PROGRAM VYKONA DANY CYKLUS RYCHLEJSIE. Kedze optimalizator dany cyklus ODSTRANI, je test uplne na prd. V inom pripade, ked by cyklus mal skutocny zmysel by sa to nedalo takto osalit.
Preto stale za jediny spravny test povazujem test bez optimalizacie, v ktorom je C# 4-5x rychlejsi ako C (aj s pouzitim registrov).

A to jste právě vedle! Prázdný test nikoho nezajímá, snad jen reklamní panáky. O co jde, je rychlost reálných programů, které mají pro reálné uživatele skutečný význam. A tam zvítězí ten, kdo optimalizuje a je proto rychlejší. Ale pokud chcete být úmyslně pomalejší, pak samozřejmě "necheatujte"! :-))))

Mimochodem, i kdybyste nastavil optimalizaci běžného kompilátoru C/C++ o stupeň níže tak, aby cyklus rovnou nevyhodil, tak dosáhnete rychlosti, kterou už žádný jiný jazyk Z PRINCIPU nepřekoná. Prostě proto, že při kvalitě dnešních C/C++ překladačů byste jej většinou nepřekonal ani assemblerem. Zkuste si  disassemblovat nějaký jednoduchý kód, vygenerovaný např. gcc při O3 a zkuste jej ručně urychlit! Téměř jistě se Vám to nepovede.

[Mirek Prýmek]

A já jsem myslel, že tuhle stránku

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=csharp&lang2=gpp

zná už úplně každý...

[pravdokop]

Musím se vždycky usmívat, jak mají někteří lidé zafixováno, že nejrychlejší je assembler a C je skoro tak rychlé jako assembler a všechno ostatní je pomalejší.
A když to platí, tak to přece musí platit i u tak malého kousíčku kódu, jako je jeden for cyklus.

Pokud máme program který je celý tvořen pouze for cyklem ve kterém je pouhá jedna inkrementace celočíselné proměnné, tak neporovnáváte rychlost jazyka jako takového, ale porovnáváte pouze kompilátory a jejich nastavení. U takovéhoto kódu prostě záleží, jestli tam ty kompilátory nechají cyklus. Pokud by ho tam nechaly - pak je docela možné, že GCC i CLR JIT kompilátor vyplivnou stejné instrukce - a pokud pomineme CLR režii, tak budou oba programy limitně stejně rychlé.

Dobýváte se do otevřených dveří... Řekl jsem v podstatě totéž co Vy: Že nic RYCHLEJŠÍHO nevymyslíte. NE, že všichni ostatní musí být POMALEJŠÍ!

[Trident]

To je vsechno moc super co tu pisete, ale nemaje vysokych skol ni programatorskych party (a tudis se plazim pred vama kanalama), tak mi tu v komentarich schazi:
1. Otazka v subjectu zni jestli je jazyk x rychlejsi nez y. Vzapeti tazatel uvadi konkretni compilery/interprety. Oddelme prosim jazyk a implementaci compileru/interpretu.

2. Nikdo z vas tu nezminil paralelismus a optimalizaci interprety kodu na vic svabiku.

3. Kdyz uz jsme u gcc. Prectete si:http://sunsite.ualberta.ca/Documentation/Gnu/gcc-2.95.2/html_chapter/gcc_toc.html#TOC98
A to odstavec 5-7. To co jsem cetl cca pred 10ti lety stale plati. gcc neni uplnej blbecek ani pri -O0. Prestanme predpokladat chovani jako u starych kompileru co byly jen hloupe prepisovace kodu.

4. Proc lidi ztracej cas tim aby dokazali ze compiler prechytraci? A zrovna v dnesni dobe kdy si nektere compilery pomalu uvedomuji samy sebe:) Pokud danou konstrukci lepe zmakne kod v asembleru tak ho delam v asembleru. Pokud Ccko tak pouzivam Ccko. Vzdyt se to da sesroubovat dohromady. Ze to tomu jankovi nepujde na vice platformach to uz je jina vec. Tim se musi vytrestat sam. Jinac se to nenauci.

[pravdokop]

Nedalo mi to, a otestoval jsem si testovací program na svém kompu běžným linuxovým g++ kompilerem (bez jakýchkoliv úprav typu vložení klíčových slov "registry" apod.):

Bez optimalizace, tj. s g++ -O0:  time = 3,225 s
S nejnižší optimalizací, tj. s g++ -O1:  time = 0,564 s
S vyšší optimalizací, tj. s g++ -O2:  time = 0,003 s

Je zde krásně vidět, že již základní optimalizce "urychlí" C++ program cca 6x, čímž se minimálně vyrovná C#. Ještě lepší optimalizace vyhodí (naprosto správně) celou smyčku pryč jakožto zbytečnou.
Dále je z disassembleru vidět, že další urychlení je prakticky nemožné, celá smyčka jsou pouhé dvě instrukce (dekrementace registru a podmíněný skok při nenule s blízkým offsetem):

000000000040072d:   sub $0x1,%eax
0000000000400730:   jne 0x40072d <main+9>

Nejde o nic jiného, než že zjevně C# kompiler optimalizuje tento program podobně jako g++ s volbou O1. Možná je tak nastaven defaultně, možná ne, to je celkem jedno. Moje teze, že "nic" není rychlejší než C/C++ tímto pokusem zůstala nezpochybněna. Naopak doměnka, že C# je rychlejší, byla tímto vyvrácena.

[student]

Mimochodem, i kdybyste nastavil optimalizaci běžného kompilátoru C/C++ o stupeň níže tak, aby cyklus rovnou nevyhodil, tak dosáhnete rychlosti, kterou už žádný jiný jazyk Z PRINCIPU nepřekoná. Prostě proto, že při kvalitě dnešních C/C++ překladačů byste jej většinou nepřekonal ani assemblerem. Zkuste si  disassemblovat nějaký jednoduchý kód, vygenerovaný např. gcc při O3 a zkuste jej ručně urychlit! Téměř jistě se Vám to nepovede.

To zalezi hlavne od urovne toho kodu. Ak ludia nepouzivaju restrict u pointerov, pouzivaju signed datove typy, volatile atd, tak tam sa da nahnat par instrukcii.

Inak o neprekonani "Z PRINCIPU" to nemusi byt az tak uplne pravda, hlavne pre "exoticke" pripady. Ak ma napriklad Java ovela viac pamati ako C, tak casto dokaze jej GC pracovat lepsie ako malloc / free uz po dokonceni JIT kompilacie (na to treba nieco ako 10k priechodov cez 1 miesto).

[pravdokop]

To zalezi hlavne od urovne toho kodu. Ak ludia nepouzivaju restrict u pointerov, pouzivaju signed datove typy, volatile atd, tak tam sa da nahnat par instrukcii.

Inak o neprekonani "Z PRINCIPU" to nemusi byt az tak uplne pravda, hlavne pre "exoticke" pripady. Ak ma napriklad Java ovela viac pamati ako C, tak casto dokaze jej GC pracovat lepsie ako malloc / free uz po dokonceni JIT kompilacie (na to treba nieco ako 10k priechodov cez 1 miesto).

Jasně, určitě se dají najít exotické případy, které člověk vyřeší lépe než sebelepší AI. Ale vyjímka, jak známo, potvrzuje pravidlo. 

[Ivan]

Jasně, určitě se dají najít exotické případy, které člověk vyřeší lépe než sebelepší AI.

Nekdy ty pripady nemusi byt ani nijak exoticke. Jave lezi vsechny objekty na heapu a promenne jsou jen reference na ne - zadna jina moznost neexistuje. Zamco v C++ existuje spousta moznosti. Nedavno jsem neco podobneho resil v jednom OS projektu v QTcku. V QTcku maji objekty tzv. thread-affinity kazdy objekt patri k nejakemu vlaknu a v kontextu toho vlakna prijima signaly a v kontextu toho vlakna taky musi byt znicen. To pridavalo tolik problemu s race-conditions v MVC ze se nakonec vsechno predavalo hodnotou a QStringy(a jiny QObjekty) se porad dokola kopirovaly. Nakonec ten kod byl pomalejsi nez byt byl v Jave. Popravde receno neexistuje zadny realny duvod proc by melo byt C++ obecne vyrazne rychlejsi nez Java.

PS: pokud by to nekoho zajimalo tak muzu dodat dva identicke parsery SQL vygenerovane pomoci ANTLR. Ten Javovy je 2x rychlejsi nez ten v C++, zatim jsem neprisel na duvod proc tmu tak je.