fw1 schrieb am 20.09.2023 21:33:
Ich stelle mir vor, dass GraalVM mit LLVM Java wie C-Code compiliert und optimiert. Demnach wird "normales Java" in Maschinencode mit SIMD-Instruktionen automatisch übersetzt, wenn die Ziel-Architektur es kann:
https://www.llvm.org/docs/Vectorizers.html
Der Programmierer braucht da gar nichts zu machen.
Das stimmt auch so für bestimmte Sachen, nennt sich Auto-Vectorization. Der Optimizer kann das aber nicht immer machen (das Programm muss ja immer korrekt sein, du kannst Sachen wissen, die der Compiler nicht wissen kann) und manche Sachen macht er gar nicht. Z.B. Masking oder cross lane Operationen. Hier ist die Doku: https://openjdk.org/jeps/448
Du musst dem Compiler "sagen" (zur Kompilationszeit, nicht erst zur Laufzeit), für welche CPU er den Code optimieren soll. Das geht so weit, dass das Programm dann nicht mehr auf älteren CPUs läuft, als der eingestellten. Ich würde "-march=native" beim Aufruf von "native-image" mitgeben und ausmessen.
Es geht hier *nicht* um native Images auch wenn man den Eindruck haben muss, das bei einem Java-Programm nur noch die Startzeit relevant ist, es geht hier nur um das Vector-API. GraalVM ist auch eine sehr schnelle VM, in meinem Use case etwa 15% schneller als Hotspot, braucht aber etwas länger bis der Code optimiert ist.