Hacker News Reader

Comment by protomyth | Hacker News Reader

> Kind of hard to believe it took this long to get SIMD though!

Does the JVM have SIMD?

If you mean as part of the language standard no.

Having said this, each JVM vendor is free to make use of them if it sees fit to do so. They just don't offer a standard way to explore the SIMD instructions, or let the JIT decide how to compile the code.

Additionally, Java 9 will have integrated support for GPGPU via the Aparapi project for HSAIL support. Which you can already use anyway.

http://developer.amd.com/tools-and-sdks/heterogeneous-comput...

Wow, that is really neat. I would imagine Java's parallel-friendly data structures help make that feasible? (vigorously discussed in this thread a few months back: https://news.ycombinator.com/item?id=6505786)

Its probably not as sexy as that. All data structures have to be copied from CPU land to GPU land, and the GPU is limited in the kind of pointer chasing it can do (so simple linked lists might work, but they are mostly about vectors and matrices).

Well, this is OpenCL backed and the latest OpenCL is all about sharing the memory space between CPU and GPU. AMD has for some time been making a big deal of sharing the same view of virtual memory on GPU and CPU sides. Which lets you use the same pointers from both sides.

https://www.khronos.org/news/press/khronos-finalizes-opencl-...

"Host and device kernels can directly share complex, pointer-containing data structures such as trees and linked lists, providing significant programming flexibility and eliminating costly data transfers between host and devices."

iirc they're aiming for Value types and a new JNI for Java 9, so that could simplify some of those issues.

If what's needed is speed, neither Java nor C# are optimal choices. As for SSE/AVX from Java, http://stackoverflow.com/a/10809123/158026 shows a nice example of how it can be done.

OTOH, I find this specific C# implementation neat and portable. I like it a lot.

If what's needed is speed, neither Java nor C# are optimal choices.

True, but if you're just trying to get some numerical speed out of some specific routines in a larger .NET application then having access to SSE like this could still be very helpful. Calling into native libraries from .NET isn't necessarily a performant option because of the cost of marshaling data back and forth between the managed and unmanaged memory spaces.

The end result can be pretty significant; from my own experience I'm usually pretty hard-pressed to come up with a C++ implementation that can beat the C# code it intends to replace outside of a microbenchmark. If the C# code now has the option of banging on SSE then I'm not sure it'll even be worth trying to trot out C++.

I agree. This is clearly the way to go for the most common use-case ("I don't want to write C/C++, but I want to make this thing faster"). Having support for SIMD in the standard library, even if at the expense of specific types (like NumPy) is definitely the way to go.

You can get rid of a fair amount of marshaling overhead if you use unsafe code (if that's acceptable in your org).

You can, and I've generally had better luck with unsafe code than with C++ code. Unsafe code creates GC overhead, though, so it can also end up doing more harm than good if you're not careful. It's another spot where I've found that microbenchmarks can be misleading - the performance cost that pinning incurs is insidious and hard to measure.

That sounds interesting, could you elaborate? (what is pinning in this context?)

Usually in the managed world you have references that point to an object. The objects themselves don't live in the same place forever, they may be moved by the GC (to consolidate "holes" in memory). References reflect that movement so you don't notice. However, when using unsafe code (which has pointers and pointer arithmetic) you need to keep the objects in place. That's pinning and it essentially forces the GC to work around those islands of pinned objects.

> If what's needed is speed, neither Java nor C# are optimal choices

"Speed" is relative. If you mean throughput or scalability (2 different things), then the JVM or the CLR may be exactly what you want due to the ease with which one can juggle with multi-threading on multi-core processors.

Single-threaded performance is becoming less and less interesting and dealing with multithreading or with asynchronous I/O in lower-level languages, such as C/C++, is an extreme pain in the ass - because for example, C/C++ doesn't come with a memory model by itself (i.e. you can get fucked even when running with a different Glibc version) and the poster child for async I/O, libevent, has been plagued for years with concurrency issues, leading to a whole generation of insecure web servers.

The JVM, .NET and managed runtimes in general are great choices for going forward, because not only they come with memory model guarantees and a sane standard library - but having higher-level bytecode under the hood that can be generated at runtime means that either the runtime or the libraries running on top can repurpose that bytecode at runtime for optimal execution. Like for example, you could target the GPU when dealing with parallel collections.

Yes but there is room to improve.

https://bugs.openjdk.java.net/browse/JDK-6340864

That's a bit different; this is about user-controlled SIMD instructions, not whether .NET can use SIMD instructions as part of its routine JIT code generation (see http://blogs.msdn.com/b/davidnotario/archive/2005/08/15/4518... for some very old commentary on where .NET took advantage of SSE instructions in its code gen).

Awesome! The other day I tried to find the amount of per-cpu tuning the .NET runtime was capable of but could never find anything. Thanks for the link, this is exactly what I was looking for.

Reply on news.ycombinator.com