horn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edward J. Yoon" <edwardy...@apache.org>
Subject Re: Java On GPU: Rootbear, Java 8
Date Wed, 28 Oct 2015 04:30:44 GMT
Cool, I can look at about GC problem of rootbeer and Java8 closely.

On Wednesday, 28 October 2015, Shubham Mehta <shubham.mehta93@gmail.com>

> 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

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