The short answer is the JVM is horrible at SIMD. It does a few optimizations when working with primitive arrays but beyond that, you're basically stuck working outside the JVM. The key for Arrow is that the overhead of stepping out of the JVM can be amortized across all records in a batch. I hope to contribute some examples of this cross use with benchmarks shortly but would love it if others also did some work here.
On Wed, Feb 24, 2016 at 2:22 AM, Taro L. Saito <l...@xerial.org> wrote: > Hi, > > I have just started looking at the java code of Arrow. So far what I can > found is: > - Code template is used to generate efficient codes for reading/writing > fixed bit-length value vectors > - Unsafe class will be used to accelerate raw memory access within > ByteBuffer > - ValueHolder class is used to avoid object construction costs > > msgpack-java (https://github.com/msgpack/msgpack-java) is also using > similar techniques, so these optimizations are totally make sense. > > But I still cannot find where SIMD operations will work effectively. > Using JNI to invoke SIMD ops will have non-negligible overhead. So my guess > is Arrow will rely on some JVM optimization. > > Could you tell me how SIMD operations will be used in Arrow java? > Thanks in advance, > -- > Taro L. Saito > http://xerial.org/leo >
