Live data from Hacker News

Rootbeer GPU Compiler Lets Almost Any Java Code Run On the GPU

github.com

31–40 of 82 posts

Re: Rootbeer GPU Compiler Lets Almost Any Java Code Run On the GPU

#32
post #28

Earlier quoted context omitted.

This Writing Java is unbearable without Eclipse/Netbeans. .NET a little bit less unbearable If your IDE "works harder" than your compiler, something seems wrong to me (of course we all expect things like syntax highlighting today)

This may be a problem if your truck breaks down in the desert, your 3g is out of range and you never thought to install an ide beforehand but apart from that when would you find yourself writing java without an ide?

When you're using somebody else's computer.

Re: Rootbeer GPU Compiler Lets Almost Any Java Code Run On the GPU

#33

Earlier quoted context omitted.

It's a problem with a language if it requires heavyweight environments to make aspects of writing code in it acceptable.

This Writing Java is unbearable without Eclipse/Netbeans. .NET a little bit less unbearable If your IDE "works harder" than your compiler, something seems wrong to me (of course we all expect things like syntax highlighting today)

Meh. It's about trade-offs. Some languages are designed to be lightweight and require minimal assistance from the IDE. Some languages are optimised for very large codebases and expect a lot of "ceremony and plumbing" around them. And then there are, of course, millions of shades between the two extremes. Java and C# are in the second group. These are all very useful tools when used for the right purposes.

(Also I have written a fair amount of Java in vim and I didn't find it any more frustrating than writing Ruby in vim. And I don't even like Java.)

Re: Rootbeer GPU Compiler Lets Almost Any Java Code Run On the GPU

#34

4. sleeping while inside a monitor. ... Can someone clarify what this is?

  // In Java, all instances of Object are also a monitor.
  // See https://en.wikipedia.org/wiki/Monitor_%28synchronization%29
  Foo myMonitor = new Foo()

  // To "enter" a monitor, you use 'synchronized'.
  synchronized (myMonitor) {
    // Inside the monitor, we could do a Thread.sleep.
    Thread.sleep(100);
  }
This is a very simplistic problem case. However, it is very possible for this to become a bigger problem. Because I can call arbitrary code when "inside" a monitor, it is very possible to call a method that does a sleep incidentally. (e.g. many implementations of IO operations will require some sort of sleep.)

Re: Rootbeer GPU Compiler Lets Almost Any Java Code Run On the GPU

#36
post #7

I wonder if this is as big a win as it sounds. Regardless of what language you're using, you have to "think GPU" to get any performance from GPUs. The additional overhead of using CUDA/OpenCL syntax seems pretty small in comparison.

Yes, and it requires quite a low-level understanding of the architecture to "think GPU". SIMD, warps, blocks, threads, different memory types, no branching/identical branching per core, ... Some of this could probably be abstracted away but you definitely need to be aware and adjust algorithms appropriately. You can't just convert code and hope for the best, unless you just want a slow co-processor.

Re: Rootbeer GPU Compiler Lets Almost Any Java Code Run On the GPU

#38

I had forgotten just how much I hate java namespaces. import edu.syr.pcpratts.rootbeer.testcases.rootbeertest.serialization.MMult; This seems like a pretty amazing project if the claims are true, though - I wasn't aware that CUDA was able to express so many of the concepts used to implement Java applications. The performance data in the slides is certainly compelling!

It's nothing compared to the pain of debugging in a language that doesn't have/encourage proper namespaces.

Ruby has Modules, but many, many common libraries do not use them. I had fun recently debugging a project that (through transitive dependencies) relied on two different "progress bar" libraries, both with a class called "Progress", and neither of which was namespaced. Namespaces solve a real problem.

Re: Rootbeer GPU Compiler Lets Almost Any Java Code Run On the GPU

#39
post #7

I wonder if this is as big a win as it sounds. Regardless of what language you're using, you have to "think GPU" to get any performance from GPUs. The additional overhead of using CUDA/OpenCL syntax seems pretty small in comparison.

That's my experience in a nutshell. The cost of doing a cudamemcpy() far outweighs the advantages for computationally small tasks. The surprising bit for me was what's classed as a small task.

Decompressing a 5MP jpg then applying various filters is too lightweight a task to benefit. I thought that would be more or less a perfect GPU task, not so.

Running on OpenCL, the CPU with vector instructions horses a small GPU performance wise for this problem.

Re: Rootbeer GPU Compiler Lets Almost Any Java Code Run On the GPU

#40
post #32
post #28

Earlier quoted context omitted.

This may be a problem if your truck breaks down in the desert, your 3g is out of range and you never thought to install an ide beforehand but apart from that when would you find yourself writing java without an ide?

When you're using somebody else's computer.

Edge case. I develop on my own machine (That said, I absolutely hate the verbosity of Java and love Nods.js exactly for this reason).
Post reply on HN