Tady se projeví výhody řízeného kódu, který je kompilován na platformu, na které má být spuštěn.

Opravdu? Nemám nic proti řízenému kódu, právě naopak, ale zajímaly by mne výsledky PRAKTICKÝCH testů. Osobně si totiž myslím, že tato výhoda je spíše teoretická. Jednak by musely kompilátory zvládat překlad s použitím spousty různých instrukčních sad, a já pochybuju, že se s tím bude někdo dělat, jednak by aplikace musely vůbec mít kód, který lze použitím SSEx nějak výrazně urychlit. Jistě, takové aplikace existují, ale je jich tak málo, že se obávám, že k žádnému reálnému urychlení nikde nedojde.

Namátkou půjde třeba o grafické aplikace, které se beztak píší v čistém C++. Velmi pochybuji, že by někdo psal konvoluční filtr v C# a pak jásal nad tím, jak mu jej překladač nádherně urychlí použitím SSEx.

Bylo by to krásné, ale pochybuju, že to doopravdy funguje. Snad mne ale vyvedete z omylu.

Pravda je, že jsem nikde testy zaměřené na využití různých sad neviděl. Nebylo by od věci nechat si předkompilovat .NET aplikaci bez optimalizací a pak porovnat. Zatím jsem narazil na jeden postarší článek.

http:­/­/blogs.msdn.com­/davidnotario­/archive­/2005­/08­/15­/451845.aspx

http:­/­/www.osnews.com­/story.php­/5602­/Nine­-Language­-Performance­-Round­-up­-Benchmarking­-Math­-and­-File­-IO­/page1­/

Sice starsi test, ale uz tam je videt ze si treba Java vede ­(az na trigonometricke funkce­) stejne dobre jako C++ kod kompilovany s maximalnimi optimalizacemi. A to je pouzita ­(dnes uz stara­) java 1.4. Ale zase je pravda, ze treba kod s castymi alokacemi­/dealokacemi pameti by asi vypadal jinak...

Nedávno jsem narazil taky na jeden zajímavej test. Není sice přímo dělán na porovnání optimalizací JIT kompilace na jednotlivých procesorech ale dá se z toho něco vyčíst... ale stejně je to 3 roky staré.

http:­/­/www.shudo.net­/jit­/perf/

Potíž je, že to nejsou praktické, ale syntetické benchmarky. Pracuji v týmu na velmi rozsáhlé a na výkon náročné aplikaci v C++. Dlouho jsme ji překládali s vypnutými optimalizacemi, protože Visual Studio při jejich zapnutí generovalo chybný kód. Pak přišly nové verze VS, optimalizace už konečně začaly fungovat, my je zapnuli a těšili se na velké zrychlení. Překvapení bylo velké ­- zrychlení totiž nebylo téměř žádné. Přesněji ­- ano, bylo měřitelné, ale při normální práci nevnímatelné. Optimalizace se ukázaly jako bezvýznamné. Ano, nějaká vnitřní smyčka v jádře nejspíš byla i mnohonásobně rychlejší, jenže aplikace jako celek se nakonec chovala pořád úplně stejně. Takže od té doby mám silné pochybnosti o reálné účelnosti větších optimalizací v normálních aplikacích. Nezapomínejte, že zrychlení o deset, patnáct procent ­(a optimalizace neudělají celkem ani tolik­) uživatel při práci vůbec nepostřehne, aplikace musí být zhruba alespoň dvakrát výkonnější, aby ji vyhodnotil jako rychlejší.

1­) pouzivat soft, co si zkompilujete na miru ­- treba linux;­)
2­) pouzivat soft, co se kompiluje az na miste ­- treba java
3­) doufat, ze se vyrobce rozhoupe a doda knihovny­/verze pro danu CPU, coz ale asi nebude vetsinovy pripad...

kazdopadne alternativy jsou;)