Musím se vždycky usmívat, když se znovu a znovu objevují příspěvky, že nějaký kompilátor či dokonce interpretr je rychlejší než C/C++.
C/C++ umožňují pracovat s registry a s přímými přístupy do paměti přes pointery. Nic rychlejšího kromě assembleru už prostě nevymyslíte i kdybyste se rozkrájel :-D. Zapnutí optimalizátoru samozřejmě není žádné cheatování ale regulérní metoda, jejíž možnost a přínosnost je naopak ukazatelem vhodnosti toho či onoho jazyka pro rychlý běh aplikací.
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é.
A je jasné, že v reálném světě u reálných dlouhých cyklů asi nebude mít kompilátor možnost je vyhodit a nahradit pouhým přiřazením proměnné.
Anebo se bude optimalizovat protože to v daném případě půjde. Což CLR dělá zřejmě automaticky (osobně nevím jak moc optimalizuje Mono CLR) a u GCC je to potřeba holt zapnout flagem.
Tipuji, že kdybych založil vlákno "C/C++ je rychlejsi ako C/C++" a rozebíralo se tam rozdíl rychlosti kódů (běžícíh pod windows) zkompilovaného
-na C/C++ kompilátoru od intelu a
-na C/C++ kompilátoru od microsoftu,
že by ty časové rozdíly (a hraní s parametry) byly dost podobné :-D