"Persze tudom, vannak nagyon fejlett JIT forditok amik devirtualizaljak a hivasokat, sot akar inline-oljak oket."
Így van, pont azt csinálják meg a JVM-ek automatikusan az adott architektúrán a futás első pár másodpercében, amit kézzel végzel C/C++ esetén hónapokig. Lásd például az említett Assembly vs. C/C++ fordítók esete.
"De mindent osszerakva a C++ meg mindig gyorsabb lesz ugyanakkora biztonsag mellet."
Ez az, ami általában nem igaz... :)
"Espedig azert mert a C++-ban kozvetlen hozzaferesed van a vashoz. A kod nagy resze nallunk is magas absztrakcios szinten van megirva. De amikor kell akkor le tudunk menni alacsonyra es tudunk figyelni olyan reszletekre, hogy valami beferjen az L1 cacheline-ra es ne szoritson ki mast. Vagy hogy forro cache-el futtassunk bizonyos fuggvenyeket. Vagy agressziv inlining-al a fuggvenyhivasok nagyresze eltunik (forditaskor)."
...ugyanis ezeket a JVM elintézi.
"Vannak nagyon gyors GC-k is, sot vert izzadva ki lehet kerulni a GC-t bizonyos helyzetekben (off-heap), de teljsen nem."
Lehet low GC programot írni, ha nagyon muszáj, oda kell figyelni kicsit jobban. Pluszban a GC lényege az, hogy a takarítást későbbre tudod időzíteni, ezzel kiszolgálási időben időt nyersz. Ez szintetikus tesztekkel tökig terhelt gép esetén hátrány, mert felgyűlik a szemét, de valós workload esetén előny, mert akkor takarítasz, amikor már nagyon muszáj vagy akkor, amikor amúgy sincs más dolgod.
"Tovabba nem tagadom, hogy hibazni C++ tovabba is *sokkal* konnyebb mint Javaban. De odafigyelessel es a megfelelo eszkozok hasznalataval a kockazatokat minimalis szintre le lehet vinni."
Na, erre az odafigyelésre leszek kíváncsi, mert ezen az odafigyelésen szokott bukni a "lassú ez a Java projekt, megírom C++ nyelven és szárnyalni fog" projektek igen nagy többsége... egyszerűen azért, mert a "gyorsabb", "azonos feature set" és a "biztonságos" hármasból nagyjából kettőt tudsz választani...