horn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shubham Mehta <shubham.meht...@gmail.com>
Subject Re: Java On GPU: Rootbear, Java 8
Date Thu, 29 Oct 2015 00:20:40 GMT
GPU programming can be done two ways:
-> CUDA: It has very limited vendors
-> OpenCl: It is much more portable

A comparative study between *CUDA* and *OpenCL*:
http://wiki.tiker.net/CudaVsOpenCL

*Conclusion: *I personally think that we should go with OpenCL. Though, we
lose a bit on performance.

If we go by OpenCL then rootbeer option is ruled out. Also, it is not
maintained at present. I suggest that we should go for *Aparapi*(
https://github.com/aparapi/aparapi) which is also open source and well
maintained. *Aparapi *is based on OpenCL.

A comparative study between *JCuda *and* Aparapi*:
http://www.des.udc.es/~juan/papers/eoops2013.pdf
Its comnclusion says that JCuda requires more programming effort but can
give better performance when used with optimized CUDA libraries (CUFFT and
CUBLABS)





On Wed, Oct 28, 2015 at 1:30 PM, Edward J. Yoon <edwardyoon@apache.org>
wrote:

> Cool, I can look at about GC problem of rootbeer and Java8 closely.
>
> On Wednesday, 28 October 2015, Shubham Mehta <shubham.mehta93@gmail.com>
> wrote:
>
> > Hi,
> >
> > As you know Edward suggested that we can go by Rootbear(
> >
> >
> https://raw.githubusercontent.com/pcpratts/rootbeer1/master/doc/rootbeer1_paper.pdf
> .
> > ).
> > So, I was going through their paper regarding how they supported GPU
> > acceleration for Java.
> >
> > The main idea is cross compilation of Java bytecode to CUDA. They have
> > tried to get highest performance in (de)serialization to and from GPU
> > memory by comparing few approaches: JNI, Pure Java and Reflection.
> Finally,
> > they used Pure Java to read everything into Java byte array. After that,
> > one JNI call to copy everything to GPU memory.
> >
> > Each Java Object is represented in GPU memory as two segments-Static mem.
> > and Instance mem. They mostly haven't done Garbage Collection on GPU,
> which
> > I think shouldn't bother us.
> >
> > For code conversion to CUDA, they use *Soot Optimization Framework* (Raja
> > Vallée-Rai, Laurie Hendren, Vijay Sundaresan, Patrick Lam, Etienne Gagnon
> > and Phong Co. Soot - a Java Optimization Framework) to load .class files
> > from jar to an intermediate in memory representation called Jimple which
> is
> > then analyzed to generate CUDA code.
> >
> > *In short, it will server our purpose to run computation support GPUs for
> > neuron-centric programming model.*
> >
> > But before taking final decision, it would be great if someone can look
> > into the following paper:
> > "*Evaluation of Java for General Purpose GPU Computing "*
> > This paper cites Rootbear and has done comparative study of all available
> > framework for running Java code on GPGPU. I couldn't access it.
> >
> > Also, I read that Java 8 provides parallel stream APIs with lambda
> > expressions to facilitate parallel programming for multi-core CPUs and
> > many-code GPUs. Does anyone know about this in more detail?
> >
> > Lastly, people are trying to use ML to decide between GPU and CPU during
> > runtime. I don't know how well it scales. It is very recent study.
> > "*Machine-Learning-based Performance Heuristics for Runtime CPU/GPU
> > Selection*"
> >
> > Best Regards,
> > Shubham
> >
> >
> >
> >
> >
> >
> > --
> > Shubham Mehta
> > B.Tech 2015
> > Computer Science and Engineering
> > IIT Bombay
> >
>
>
> --
> Best Regards, Edward J. Yoon
>



-- 
Shubham Mehta
B.Tech 2015
Computer Science and Engineering
IIT Bombay

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message