javaakkaopenclgpuaparapi

Java parallelism: OpenCL/GPUs vs. actors/threads


The APARAPI project describes itself as:

Aparapi allows Java developers to take advantage of the compute power of GPU and APU devices by executing data parallel code fragments on the GPU rather than being confined to the local CPU. It does this by converting Java bytecode to OpenCL at runtime and executing on the GPU...

I'm wondering what benefit this offers over traditional concurrency frameworks such as gpars or Akka.

Under what circumstances would converting JVM bytecode to OpenCL be faster or more preferable to what these alternatives offer? Why is the OpenCL/GPU paradigm "faster" (at least under certain circumstances) than Java/CPU? What circumstances would warrant doing this?


Solution

  • I would say this, akka is a very high level abstraction for concurrency, whilst stuff like CUDA, OpenMP, MPI and so on are for computationally expensive stuff. So akka is great for implementing something like a task scheduling system and handling and throttling requests but no so great for the task execution themselves if they were computationally expensive and could be parallelized. But you have this really high abstraction and can use futures with them as well to make the whole system reactive so that it is not locking anywhere. All the GPU libraries are great for implementing massively parallel tasks where you have heaps of drones all doing almost the same thing. So that's stuff like BLAS. They've become more popular in recent times I think because of the larger advancements of graphics cards compared to CPUs, still a very specialized area though with a large learning curve IMHO as oposed to OpenMP which you can just stick a few preprocessor derivatives on your loops, or something like java8 new parallel collections. Anyway that's my 2 cents.