Különben egyértelmû, hogy a .NET a Windows világban sokkal jobb mint a Java, és én a Java-t csak a non-Windows világban támogatom, azért mert ott nincs .NET, a Mono ugyan fejlõdik, de legyünk komolyak, jelenleg nem igen fejleszt rajta senki sem komolyabb üzleti alkalmazást.
A másik dolog, pedig ha már a kód hordozhatóságának és optimizálásának a kombinációja a fõ téma, akkor az igazság ott van, hogy habár a fordítók verzióról verzióra jobbak, még mindég nem lehet tényleg optimális kódot írni, ha nem célozzuk meg az adott architektúrát, processzorcsaládot. Pl. nézzük a követlezõ peldát - na itt most C/C++ és ASM fánok mind meglesznek elégedve :)
int i;
i = i / 4;
a fordtító a következõ kódot generálja...
mov eax, i
cdq
and edx, 3
add eax, edx
sar eax, 2
mov i, eax
na most tegyük ugyanezt a következõ képpen...
unsigned int i;
i = i / 4;
a fordító megtakarít egy csomó ciklust...
shr i, 2
tehát ismerve az x86 architektúrát, amikor lehet használom az unsigned tipust, másik architektúrákon ez lehet, hogy szintén jó lesz, de nem biztos, azokat is ismerni kell.
Na a baj ott van, hogy ha nem tudom ezt, és persze lusta vagyok gondolkodni, hogy az adott változónak csak pozitív értekei lehetnek vagy esetleg kell negatív is, akkor ezt én kihagyom és ezáltal lasabb tehát optimizátlanabb kódot írok.
Na most ide bejön a MSIL a közepébe vagy a JVM kód, és most akkor itt sok minden magától a JIT-tõl függ, na a .NET elõnye itt éppen abban rejlik, hogy a JIT x86-ra optimizálódik, míg a Java esetében biztos, hogy szintén törekszenek az optimizálásra, de mivel több architektúrán kell, hogy dolgozzon ez vagy extra idõbe kerül a Sun fejlesztõinek, vagy egyszerûen kihagyják. Na szerintem ez is hozzájárul a Java és .NET közötti teljesítménykülönbséghez. Érdekes, de ha a fenti peldát C#-ban megírjuk a fordító jó MSIL kódot generál és a JIT is ugyanezt teszi, tehát megkapjuk az optimizált gépi kódot éppen úgy mintha sima C-ben írnánk, vagy ha akarjátok ASM-ben is.