Evaluating different Java bindings for OpenCL

Raquel Medina Dominguez
Universidad Carlos III de Madrid. Departamento de Informatica
Universidad Carlos III de Madrid. Departamento de Informatica, 2013


   title={Evaluating different Java bindings for OpenCL},

   author={Medina Dom{‘i}nguez, Raquel},



Download Download (PDF)   View View   Source Source   



The traditional CPU is able to run only a few complex threads concurrently. By contrast, a GPU (Graphics Processing Unit) allows a concurrent execution of hundreds or thousands of simpler threads. The GPU was originally designed for a computer graphics, but nowadays it is being used for generalpurpose computation using a GPGPU (General Purpose GPU) technology. OpenCL, one of the GPGPU technologies, is introduced in this final project. OpenCL is an extension of C and enables efficient parallel programming for heterogeneous devices including both multi-core CPUs and GPUs. However, it provides a low level abstraction to utilize the hardware efficiently. This tends to a hurdle for productive parallel programming. On the other hand, Java is widely used in many application domains since it provides good productivity in software development. Recently, several methods that bind OpenCL and Java have been suggested: Joagamp, Jocl, JavaCL. In this final project, I evaluate these Java bindings for OpenCL in terms of execution time and the memory used. My own class for vector multiplication has been the baseline application in evaluating the libraries presented here. My results show that Joagamp is more efficient, and Jocl consumes less memory, while JavaCL is most productive in terms of the number of lines of code.
Rating: 1.0. From 4 votes.
Please wait...
  • ochafik

    It’s a shame this paper used a very old version of JavaCL-JNA (1.0-beta-6, which dates back to Feb 2010 !!!).
    JavaCL-BridJ 1.0-SNAPSHOT should be immensely faster… (uses BridJ instead of JNA, with direct bindings)

    Also, the timings are done wrong: for Jogamp and JOCL, timer is started after creating the kernel, but for JavaCL timer is started before (problem is, in JavaCL program build is lazy, so it’s triggered by program.createKernel). This alone could account for the performance difference between JavaCL and Jogamp, without even taking the old version issue into account.

    Would be interesting to see an updated version of this paper take these remarks into account.

    No votes yet.
    Please wait...

* * *

* * *

HGPU group © 2010-2017 hgpu.org

All rights belong to the respective authors

Contact us: