Felveszi a C++ vedo kesztyut
Eloszor is (habar ezzel magamat is labon lovom) a JVM is C++-ban van irva es pont azert szortak ki a bongeszokbol mert tarva nyitott sebezhetosegek tatongtak rajta. Ennyit a JVM altal garantalt biztonsagrol.
Ironikus, hogy egy benchmarkkal akarsz meggyozni amikor megbeszeltuk, hogy barki tud szamara kedvezo szintetikus benchmarkot kesziteni. :D
Elorebocsatom, hogy nem vagyok Java es JVM szaki tehat fenntartom a tevedes jogat, tovabba az osszehasonlitast a scylla vs. C* kodbazisra kivanom leszukiteni. Vannak nagyon szar C++ kodbazisok amiket nem kivanok vedeni (volt egy parhoz szerencsem karrierem soran).
En a kovetkezokre gondoltam amikor at mondtam, hogy a JVM sulyosan korlatolt sebesseg teren:
* virtualis hivasok
* cache pollution
* GC
* inlining hianya
* altalanossagban veve a vashoz valo hozzaferes teljes hianya
* memoria es tomb ellenorzesek
Tehat sokkal tobbrol van itt szo mint arrol, hogy menyi kockazatot viszel be a rendszerbe. Egyszeruen a Java kod annyival a valos HW felett fut, hogy keptelenseg azt a foku optimalizalast elerni amit egy jol megirt C++ kod tud, *ugyanakkora* biztonsag mellet is akar!
Persze tudom, vannak nagyon fejlett JIT forditok amik devirtualizaljak a hivasokat, sot akar inline-oljak oket. Vannak nagyon gyors GC-k is, sot vert izzadva ki lehet kerulni a GC-t bizonyos helyzetekben (off-heap), de teljsen nem.
De mindent osszerakva a C++ meg mindig gyorsabb lesz ugyanakkora biztonsag mellet.
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). A GC-pause-ok teljes mertekben el vannak kerulve (pedig mi is hasznalunk menedzselt memoriat).
Es erre adodik ra a shared-nothing design, ahol minden core-on egy dedikalt thread fut, a sajat kornyezeteben. A teljesen aszinkron kodbazis (direct IO, DMA-val), sajat coroutine implementacival => nem kell 10000 thread, mindegyik egy IO requesten blockolodva. A sajat CPU es IO scheduler ahol az alkalmazas intelligens donteseket tud hozni (pl. compaction, repair hatterben fut, a query-k nagyobb prioritast kapnak).
Lehet, hogy feluletes energiabefektetessel legalabb olyan gyors vagy gyorsabb kodot lehet irni Javaban mint C++ ban de ha nem sajnalod az idot es energiat, tovabba megvan a szakertelem akkor szerintem a C++ verhetetlen egyelore (ki tudja a JIT forditok fejlodese mit hoz, valamikor az ASM volt verhetetlen de ma mar az optimalizalo forditok jobbak).
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.
--
:wq