Re:JEP Draft: Deprecate memory-access methods in sun.misc.un...
by anonymoushn on Wednesday January 17, 2024 @03:30AM
(#39024923)
Submissions to this challenge are also hampered by the lack of prefetch intrinsic, vpshufb intrinsic, aesenc intrinsic, and graal's complete lack of vector intrinsics. As a total outsider to the Java ecosystem, it makes it seem like nobody in a place to make changes really knows or cares about enabling high-throughput code to run in the JVM.
[ Parent
| on HN ]
Re:JEP Draft: Deprecate memory-access methods in sun.misc.un...
by kaba0 on Wednesday January 17, 2024 @04:07AM
(#39025239)
What do you mean by that?
Also, graal can do some vectorization, and definitely has some libraries with vector intrinsics, e.g. truffle’s regex implementation uses similar algorithms to simdjson.
Re:JEP Draft: Deprecate memory-access methods in sun.misc.un...
by anonymoushn on Wednesday January 17, 2024 @04:13AM
(#39025291)
I think I was fairly specific? There's no way for a user to do vpshufb, aesenc, or a prefetch instruction. One would expect the former two things to be in jdk.incubator.vector, where they are not present. The last thing was explicitly removed, here's a link to one part of the process of it being removed: https://bugs.openjdk.org/browse/JDK-8068977
Code that uses jdk.incubator.vector does not actually get compiled to vector instructions under graal. This is why the top submission that uses jdk.incubator.vector is the only top solution that does not use graal.
I don't doubt that "similar algorithms to simdjson" may be used, but simdjson uses instruction sequences that are impossible to generate using the tools provided.