The JVM may be able to do popcount optimization but it's categorically bad
at other vectorization instructions.
On Wed, Feb 24, 2016 at 18:30 Taro L. Saito wrote:
> Thanks for letting me know.
>
> If we need to embed C++ binaries (.so files) inside java,
> snappy-java's approach https://github.co
Thanks for letting me know.
If we need to embed C++ binaries (.so files) inside java,
snappy-java's approach https://github.com/xerial/snappy-java would be
useful,
which bundles .so files built for several OS/CPU architectures, and loads
one of them at run-time.
Btw, JVM is smart enough to replac
I will soon need some SIMD-enabled algorithms for hashing and
bitmap-related stuff like popcount in the C++ implementation; we might
prioritize a batchy JNI interface to Arrow C++ to use for cases where
the JNI overhead is worth paying from the Java side.
On Wed, Feb 24, 2016 at 11:30 AM, Jacques
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 t
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