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

[noef]

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.

spatna argumentace. kdyz OP nedokaze rucne optimalizovat konkretni kod, tak to neznamena, ze to plati obecne.

vim celkem jiste, ze rucne optimalizovany kod je vzdy ten nejrychlejsi. nejaky prekladac na to nikdy mit nebude, protoze "nevi" co ma kod delat. nemuze preskladavat slozitejsi bloky, podminky a cykly tak, ze v zaveru nejsou ekvivaletni se vstupnim kodem v c++, ale delaji to, co se od nich ceka (napr. i uzitim vedlejsich efektu instrukci).

java i c# pro normalni uzivatelske (a casto i servrove) aplikace se nyni pouzivaji imo nejvic. vyvoj v c++ je drazsi - podstatne delsi doba ladeni. casto je levnejsi si poridit lepsi hw, nez platit nasobne vic za sw. a samozrejme optimalizace na urovni assembleru se skoro uz nedelaji. ta narocnost jak na znalosti a zkusenosti programatora, tak na cas (i o nekolik radu vic, nez napr. v c/c++), je nepredstavitelna.

tohle vlakno mi pripomnelo klasiku, The story of Mel: http://www.pbm.com/~lindahl/mel.html 

[Reklama]

[gamer]

Psal jsem o Javě a tam se od verze 5 volatile už pro synchonizaci mezi thready použít dá.

No moc bych tomu nevěřil, měla by tam být memory bariéra, ale zdá se, že to v SUNu nedokážou implementovat správně:
http://stackoverflow.com/questions/10620680/why-volatile-in-java-5-doesnt-synchronize-cached-copies-of-variables-with-main
V Java 5 to zavedli a v Java 7u6 build b14 to opravili, takže to už možná opravdu funguje.

[Luaan]

No, pro ilustraci přikládám ASM, které ten .NETový prográmek spouští na procesoru (pozor, aplikace se nesmí pustit přímo přes VS, jinak je JIT optimalizace úplně vypnutá; je nutné pustit aplikaci zvlášť a attachnout se k ní z debuggeru až po spuštění).

00000006  xor         eax,eax
{
00000008  inc         esi
00000009  inc         eax
0000000a  cmp         eax,5F5E0FFh
0000000f  jl          00000008
}

Je tu jasně vidět, že ano, .NET skutečně umí používat registry (to je mi překvapení). C++ kompilátor je skutečně odvážnější (například otočil cyklus tak, aby mohl používat jne místo jl), ale skutečně nedochází k ničemu tak tragickému, jako že by se inkrementace integeru prováděla v paměti.

Nutno podotknout, že jsem toto skoušel na MS JIT, nikoliv na Mono. Mono je rozhodně ve spoustě kódu mnohem pomalejší.

A velká část .NETu (včetně C#) je napsána v C#, většina v Simple Managed C (také .NET jazyk) a jen pár kritických míst v C/++ resp. ASM. Mono je napsané v C# celé, a i MS má kompletní C# kompilátor napsaný v C# (Roslyn).

Největší nevýhoda C# je zároveň i v jiných věcech velkou výhodou - a jde o ten JIT kompilátor. To znamená, že záleží na konkrétním JIT kompilátoru jak chytře bude kód optimalizovaný, a navíc musí JIT šetřit optimalizacemi, protože na ně má málo času. Windowsácký MS JIT kompilátor je výborný, Mono je na tom výrazně hůř. Každopádně tam pořád zůstává to kritické - .NET umožňuje napsat 99% aplikace snadno a bezpečně, a pro to 1% výkonově kritického kódu dokáže používat stejné prasárny, jako C/ASM.

[Jakub Galgonek]

C++ kompilátor je skutečně odvážnější (například otočil cyklus tak, aby mohl používat jne místo jl), ale skutečně nedochází k ničemu tak tragickému, jako že by se inkrementace integeru prováděla v paměti.

Ale jo, gcc s vypnutými optimalizacemi to v paměti dělal:

Kód: [Vybrat]

.L3:
   addl   $1, -8(%rbp)
   addl   $1, -4(%rbp)
.L2:
   cmpl   $999999998, -4(%rbp)
   jle   .L3