"Szerintem egy kicsit tul sokat gondolsz a JVM es a JIT-forditok kepessegirol."
Mintha egy Assembly programozót hallanék, amikor a C++ fordító tudásáról lenne szó... :)
"Ezzel szemben a valosag az, hogy a C* clustereket majd harmadaval tul kell meretezni, hogy valahogy megbirkozzon a rettenet hosszu GC szunetekkel es mindenki kicsi es olcso gepeken futtatja mert a nagy gepeket egyszeruen keptelen kihasznalni, mert csak 10-20% os loadon jaratja oket."
Azt azért sejted, hogy ezek nem azért vannak, mert a Scylla inline beleteszi az L1 cache-be az optimalizált metódusokat... :)
Ezek azért vannak, mert lehet ugyan low GC programot fejleszteni, de a Java runtime tudhatna azért még GC takarékosabb lenni, illetve lehet ezen JVM paraméterekkel jelentősen javítani, csak nem feltétlen szoktak, mert kevés a hozzáértő, aki tudja, hogy mi történik, miért történik és hogy lehet rajta javítani. Ötletszerűen csavargatni JVM paramétereket pedig nem mindig célravezető.
Ezen túl vannak a Java nyelvre jellemző runtime idejű ellenőrzések, ami miatt _leginkább_ kialakul ez teljesítmény különbség.
Röviden (és nem kizárólagosan) ez azt jelenti, hogy Java esetén se fordítási időben, se futási időben nem tudod megtenni azt, hogy:
int[] x = new int[10];
float y = 0.0f;
x[15] = y;
Mert a környezet nem engedi, ez például le se fordul így ebben a formában, de ha le is fordul, akkor a tömb túlcímzésének a vizsgálatához nyilván kell néhány plusz CPU utasítás, hogy ezt ne tudd megcsinálni. Nem tudod megkerülni, nem tudod rábeszélni a fordítót és a futtatót, hogy te teljesen biztos vagy benne, hogy nem fogod túlcímezni. Ezen túl az a szép, hogy ha teljesen biztos a helyzet, hogy nem lehet a tömböt túlcímezni, akkor a fordító és a futtató és kihagyja ezeket az ellenőrzéseket.
C/C++ esetén pedig ez lefordul és a környezet vígan végrehajtja a programot:
int x[10];
float y = 0.0f;
x[15] = y;
Csak vagy `Segmentation fault` lesz belőle vagy pedig egy csinos támadási vektor, amely során mondjuk egy preparált blob-on keresztül futtatási jogot tudnak kapni a gépen a támadók...
"Egy olyan nyelv ahol meg az integer is objektum ha tombben akarod tarolni."
Azt ugye tudod, hogy ez kétszeresen is hülyeség? Egyrészt a tömbben tárolt int az bizony primitív int lesz, egy 1000 elemű int[] tömb mérete a memóriában 4016 bájt. Másrészt a tömbben tárolt Integer objektum a tömbben primitív int lesz és konvertálódik a használat során (Autoboxing), egy 1000 elemű Integer[] tömb mérete a memóriában meglepő módon 4016 bájt...