SIMD-et több helyen használják, mint gondolná az ember.
Ugye kapásból ott kezdődik, hogy nem is lehet teszem azt AVX512-esre fordítani a binárist, mert ahol meg nincs, ott el se indul. Tehát kell egy futás közbeni check, hogy van-e vagy nincs, és a megfelelő kódot használni.
Pont ezért a legtöbben öntudatlanul használnak SIMD-et: pl. a numpy bináris részeiben, vagy egy erre szolgáló lib részeként, pl. videó de/encoding libek csinálják előszeretettel ezt az autodetect-et.
Ebben az a rossz, hogy ha egyszer úgy kezdtük el, mondjuk Javában amit C-ben kellett volna
Meglepődnél, milyen effektív a java C2 compilere. Keress rá bátran, de a helyzet az, hogy a legújabb java-kkal könnyebben írsz jobb kódot, mint C-ben. Mert java21 -el bejött a project loom, ami automatikusan async-await modellbe fordítja a tradicionális single-threaded kódot. A másik, hogy ugye a JIT miatt képes a procihoz igazítani a gépi kódot. Ezzel együtt a GC és a memóriapazarló dolgok továbbra is bejátszanak, és erősen érezhető a hatásuk, a különbség teljesítményben már korántsem olyan meghatározó/egetverő, mint 20 éve; konkréten 20-30% körül mozog.
A másik, mivel a java ugye gépi kódot fordít, már 10+ éve best practice-nek számít, hogy ahol lehet, használj sima ArrayList-et. Miért? Mert a linkedlist kvázi random memória-hozzáférést jelent, és bizony ahogy írod, 10x lassúbb, mint a sima ArrayList, ami ugye végső soron egy sima malloc() -ba pakolja az elemeket. Vagy pl. a GC is tud "compression"-t, vagyis a fragmentált memória-területeket összefésüli időnként - ezt spec. még a malloc() se tudja. Illetve a java best practices bizony javasolja a stack használatát, vagyis amit tudsz, tegyél már lokál primitívekbe, mert a stack hozzáférés szinte biztosan cache-ből jön ugye.
Ezen felül az igazán durva arcok olyat is tudnak, hogy GC-free kód, vagyis nem foglalnak heap-en semmit. Ennek eredménye, hogy konkrétan a GC-t akár ki is lehet kapcsolni, és úgy fog futni a JVM.
Szóval tl;dr, a java-ban ismertek az alacsony szintű optimalizációs trükkök, és használják is őket - ami ugye a library-k elterjedtsége miatt azt jelenti, hogy bizony java alatt is a CPU idő 80+ %-a bizony csutkára optimalizált kódon fog futni.
Nem olyan gáz az, mint sokan hiszik...
Hogy fog 128 core osztozni a memória buszon?
Hatalmas L2/L3 cache-el. És jó kóddal: ahogy írod, a memória hozzáférés drága. Tehát csak akkor forduljon memóriához, ha kell.
Nyilván 128 core-on nem egy win11+steam fut :) oda specializált webszerver meg hasonlók kellenek, különben tetű lassú lesz.