Article

Treasuring-the-GPU-in-Java

Treasuring the GPU in Java

I remember getting euphoric a decade ago, as a teenager, seeing the motherboard of my new desktop computer being assembled. I had been told that without a high end "graphics card", I wouldnt be able to play Half Life 2! I recall looking at that chip, painted glossy red on top, and thinking that it was something smaller than the processor chip. I was young enough to ignore that I was looking at a GPU.

The Graphics Processing Unit was introduced to offload compute-intensive functions, related to multimedia, away from the CPU. The GPU promised a dedicated execution avenue - processor, registers & memory - to operations like 2D/3D drawing, rendering and video decoding, providing a huge boost in performance - often called "acceleration". GPU was capable of running a larger number of instructions per second, with the assistance of parallelism baked inside the hardware, something that the CPU lacks.

The next, obvious question to ask was - why use it for graphics alone? There are real-world, statistical, scientific and engineering applications that are massively compute-intensive. This realization led to the advent of the GPGPU - the General Purpose GPU. The manufacturers of GPU began to advocate its application in non-graphical use cases that typically involved operations on very long vectors (or arrays). For example certain operations in Bioinformatics, like protein folding were found to be performing 40 times better when run inside a GPU.

Java, as a platform, supports millions of real-world applications today. We keep getting better and better, enabling applications to exploit all that the underlying hardware has to offer. Java is hence keen on working with the GPU to drive home, solid performance gains for the applications running inside it. For example, almost every enterprise application on this planet involves the task of searching. The time complexity of searching unsorted data is often limited to linear efficiency, and for sorted data it is logarithmic. Only the amount of parallelism offered by the GPU can help break these barriers.

Javas standard libraries hold a lot of compute-intensive code. The first obvious step, hence, would be the GPU acceleration of such code. Users of the standard libraries would, of course, be oblivious to this. Since this code is primarily Java, we would have to translate it to machine instructions that can run inside a GPU. The other step would be to enable Java programmers to use the underlying graphics device, through a Java API which could be a wrapper around existing GPU extensions to the C language viz. CUDA and OpenCL. A future Java runtime may dynamically identify parallelization opportunities in running code and offload that code, and the data it works on to the GPU.

While many computation-intensive applications already run on Java, the ones in future will be much more complex. With the success of Big Data Analytics and its expected pervasiveness in the near future, many more enterprise applications will graduate to having compute-intensive subsystems. The Java runtime would be expected to bolster these developments. And our best resort would be the GPU