Live data from Hacker News

Java and SIMD

prestodb.rocks

1–10 of 40 posts

Re: Java and SIMD

#2
I asked James Gosling about SIMD (MMX and SSE) back in the year 2000 JavaOne conference. He said the answer is method calls, and that the compiler can use whatever instructions it likes. (I submitted the question online, and he answered it on stage, and I later saw the recording; I didn't attend, nor meet him in person. He seemed a bit annoyed that the question was too simple.)

Re: Java and SIMD

#3
This has got to be one of the best blog posts I've read in a while. It's clean, concise, has a clear use-case and is well benchmarked. Kudos to the author.

Re: Java and SIMD

#4
There's room for two approaches in Java really. The JIT can be smart and use SIMD instructions where it can see they are applicable, but there's also room for a small DSL like API that allows library authors and other very experienced users to express a suitable algorithm and have it easily translated into the SIMD instructions available at runtime. Anybody interested in the latter should take a look at the work being done under project Panama.

Re: Java and SIMD

#5

There's room for two approaches in Java really. The JIT can be smart and use SIMD instructions where it can see they are applicable, but there's also room for a small DSL like API that allows library authors and other very experienced users to express a suitable algorithm and have it easily translated into the SIMD instructions available at runtime. Anybody interested in the latter should take a look at the work bein…

This presentation was posted recently on the general OpenJDK mailing list

  http://cr.openjdk.java.net/~vlivanov/talks/2017_Vectorization_in_HotSpot_JVM.pdf

Re: Java and SIMD

#6
Auto-vectorization is hard. Very hard. E.g. even in C/C++, the compiler (e.g. GCC C/C++ or MS VC/VC++) is unable to vectorize loops unless you help it a lot, and in most cases, you end writing SIMD "intrinsics" (e.g. [1]) in order to get optimal results. From my experience, despite auto-vectorization being better than 10 years ago, still is very far for optimizing code properly without lots of tuning (e.g. you can try build any graphic processing library and see the vectorization warnings -i.e. why the vectorization was not possible-).

Ten years ago, in the SSE2/Altivec times, I thought that it would be matter of time having much smarter compilers making graphics/pixel processing code much faster, but not. So for JIT the case it can not be better, because is similar, as even taking runtime information, the auto-vectorization phase is equivalent. I would love to see smarter compilers, understanding the code, many steps over current hardwired pattern-matching based optimizations.

[1] https://software.intel.com/sites/landingpage/IntrinsicsGuide...

Re: Java and SIMD

#9
Be very careful about this in a shared environment. AVX512 slows down the CPU cores because of thermal, voltage throttling. The instructions "take more work". Intel CPUs take 1 MILLIsecond to return to normal speed.

If you're doing any kind of rapid context switching, or multiple workloads, depending on how your scheduler is setup, the OTHER workloads will show up as using more percentage of CPU time per work item. It's non-intuitive, and difficult to debug.

Re: Java and SIMD

#10
post #9

Be very careful about this in a shared environment. AVX512 slows down the CPU cores because of thermal, voltage throttling. The instructions "take more work". Intel CPUs take 1 MILLIsecond to return to normal speed. If you're doing any kind of rapid context switching, or multiple workloads, depending on how your scheduler is setup, the OTHER workloads will show up as using more percentage of CPU time per work item. I…

Now that major cloud vendors are selling VMs with guaranteed AVX512 support, how are they going to deal with the "noisy neighbor" problem?
Post reply on HN