9 ms·
Rootbeer GPU Compiler Lets Almost Any Java Code Run On the GPU
- deleted 14y ago[deleted]
- sillysaurus 14y agoIt would be good to post the code for the performance tests in the slides. https://raw.github.com/pcpratts/rootbeer1/master/doc/hpcc_rootbeer.pdf https://raw.github.com/pcpratts/rootbeer1/master/doc/hpcc_ro...
- kevingadd 14y agoI 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!
- pjmlp 14y agoYou find similarly named namespaces, packages, modules in most languages that support modules. Don't blame the language for what some guys do with them.
- mintplant 14y agoIt's really not a problem when IDEs like Eclipse and Netbeans automatically handle imports for you.
- archangel_one 14y agoIt's a problem with a language if it requires heavyweight environments to make aspects of writing code in it acceptable.
- raverbashing 14y agoThis 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)
- Danski 14y agoThis 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?
- qxcv 14y agoWhen you're using somebody else's computer.
- pooriaazimi 14y agoEdge case. I develop on my own machine (That said, I absolutely hate the verbosity of Java and love Nods.js exactly for this reason).
- markokocic 14y agoWhen was the last time any professional software developer was forced to do any real development on someone elses computer? In that case it is likely that one will miss his keyboard, desktop shortcuts, shell aliases, browser bookmarks much more than tour ide.
- dman 14y agoSo you have never been asked for help from a junior developer whose development setup is different than yours?
- markokocic 14y ago
- taligent 14y agoimport edu.syr.pcpratts.<asterix>; The only reason you see the fully qualified class names is because the IDE does this automatically for you. If there were no IDEs everyone would be using the *s;
- nradov 14y agoWildcard imports are a bad idea regardless of whether you're using an IDE or not due to the risk of future name conflicts.
- taligent 14y agoMy point was more than Java namespaces can be easy to use. Pretty much everyone uses an IDE anyway so it's not like namespaces are ever an issue unless you do come across that rare name clash.
- lloeki 14y ago> Pretty much everyone uses X anyway so it's not like Y are ever an issue This 'its good enough, and everyone does it anyway' attitude leads us to incredibly damaging status quos.
- Karunamon 14y agoOften though, "good enough" really is good enough. You can spend untold man hours trying to get that last little bit of perfection and never really achieve it anyways.
- mateuszf 14y agoThey are not a bad idea if you use and IDE and not an editor. IDE lets you find usages of a type instantly. Anyways such conflicts are rare.
- jburwell 14y agoThis sentiment is dogma from long ago when there was a slight performance improvement for individual imports. Today, there is no such performance advantage. Their risk of a namespace collision, but in practice, it is very rare and very easy to identify when it does. The main reason it remains is mainly due to default IDE configuration. On the flip side, wildcard imports make coding much more fluid and concise. How many times have you had to hit ctrl+space two or more times in the same declaration to add import statements for interfaces and classes from the same package? IMHO, explicit imports greatly decrease the usefulness of the static import feature.
- rabbitfang 14y agoThat is an unusually long namespace. It says more about the coding style of the programmer that wrote it than it does about Java.
- rbanffy 14y agoAfter a while, most Java developers start thinking it's ok to build deep hierarchies of modules.
- jbooth 14y agoComplaining about java as a language for providing a namespace feature that's basically identical to every other language just shows a want to hate on Java.
- rbanffy 14y agoIt's OK to build hierarchies of modules. It's not OK to make them deeper than needed and violate YAGNI with sparse hierarchies prepared for situations that'll never arise. Not all programmers fall into this trap, but due to IDE support, Java developers are specially vulnerable because, for them, it costs nothing - programs do the job of keeping everything neatly over-organized. I don't hate Java. In fact, along with Python and C, it's one of my favorite (and more used) languages. But I do realize it has a huge potential for being abused in horrible ways.
- strictfp 14y agoIf they would remove all the redundant information it would be a lot better.
- rickette 14y agoDoes it really matter? Namespaces/packages only serve to: - make things unique - group things logically (which makes the systems design more explicit) This applies to all programming languages. It's just that there's a convention in the Java community to prefix namespaces with a FQDN, which adds to the length. But you're free to choose another convention if you fancy. Although I wouldn't recommend since it's not a major issue, especially considering IDE support.
- kaffeinecoma 14y agoIt'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.
- pmr_ 14y agoThe thing with namespaces is that they also introduce a problem through the various using clauses programming languages provide and how that interacts with common tools like grep. An API that uses a naming-convention that emulates namespaces (e.g. as in Emacs Lisp) removes that problem. This also makes good harder to follow when reading, especially when C++ things like SFINAE are around and suddenly everybody is calling everything fully qualified again to make code look and be unambiguous. Of course, that can be solved with proper tooling, but some people are just averse to using something more heavyweight than necessary.
- stephen272 14y agoSeems much nicer than coding directly for CUDA or OpenCL
- joestringer 14y agoThe host-side application could already be written using Java, atleast for OpenCL applications[1] (The kernel--that is, the GPU code--was still written in OpenCL). My only concern is that Java will make it more difficult to find out exactly what's going on in the kernel code, and hence more difficult to optimise. Now, this also doesn't solve the issue of needing to consider the parallel architecture when coding the kernel to actually make use of the hardware. Nevertheless, kudos to the guys behind this. [1] http://code.google.com/p/javacl/ http://code.google.com/p/javacl/
- pron 14y agoAt first glance this seems very impressive.
- wmf 14y agoI 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.
- relix 14y agoYes, 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.
- 3amOpsGuy 14y agoThat'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.
- fleitz 14y agoProbably not, typical java code is dominated by branching indirect code. Such code typically operates on mutable data which is not what GPUs are designed to do efficiently. This should be a performance nightmare.
- pjmlp 14y agoA comparison with AMD's Java offering, Arapi (http://developer.amd.com/zones/java/aparapi/pages/default.aspx http://developer.amd.com/zones/java/aparapi/pages/default.as...), would be interesting.
- wetherbeei 14y agoLooking through the code, this seems to do the exact same thing as Aparapi. I'm surprised this was given funding given the high quality implementation AMD has put together. The headline is misleading; only a small subset of Java can be ported to the GPU. It works great for inner math loops and such, but not for higher level problems. Even if the author managed to find a way to translate more complicated problems (I see object locking in the list of features), they would be better suited to run on a CPU, or refactored to avoid locks.
- ChuckMcM 14y agoIts pretty cool. Of course you are probably using that GPU in a desktop, but an on die GPU in a server class machine? Something to consider.
- SwellJoe 14y agoThe GPU in a desktop is the only interesting kind of GPU. The built-in GPU in servers is ten years behind the current cutting edge on desktops. Though servers can have PCI Express slots for modern GPU installation. I think most of the GPU-based bitcoin farmers are using desktop hardware, but I might be wrong.
- duskwuff 14y agoWell, there's really two classes of server GPUs. One is the tiny ancient GPUs used to drive VGA outputs on servers. Those are hardly even worth talking about; they're only there so that you can hook a monitor up in an emergency. And then there are real server GPUs, like nVidia Tesla stuff. Those typically don't even have video outputs, but they're on par with modern high-end gaming GPUs, possibly even better at some tasks. I believe most bitcoin farmers are still using desktop GPUs, but that's largely just because they're running relatively simple kernels, all things considered, and because desktop GPUs are cheaper and easier to source.
- jvc26 14y agoTo my knowledge bitcoin farmers found the hash rates of the Tesla based ec2 instances far slower than consumer grade high performance graphics cards
- sp332 14y agoI'm not clear on the reason, but desktop GPUs from nvidia and AMD that have similar graphics performance, have very different bitcoin mining performance. The nvidia cards get about half the hash rate of a similar AMD GPU.
- tmurray 14y agothis sort of thing is why NVIDIA is supporting LLVM: http://nvidianews.nvidia.com/Releases/NVIDIA-Contributes-CUDA-Compiler-to-Open-Source-Community-7d0.aspx http://nvidianews.nvidia.com/Releases/NVIDIA-Contributes-CUD... in other words, with that and the right frontend, you can take Language X, compile to LLVM IR, and run it through the PTX backend to get CUDA. however, in the grand scheme of things, this probably doesn't make GPU programming significantly easier to your average developer (as you still have to deal with big complicated parallel machines); what it really does is ease integration into various codebases in those different languages.
- winter_blue 14y agoDoes this simply run your java code on the GPU, or does it parallelize your code automatically? The latter would be really cool.
- dlsym 14y agoThis is indeed IMHO a central question in this topic, since parallelizing an algorithm is not an easy task. So I guess you still end up writing your algorithm in OpenCL / Cuda and maybe use the serialization provided by this lib. Update: (Just read the hpcc_rootbeer.pdf slides.) You write your _parralellized_ implementation of an Algorithm in Java - and it will be executed on the GPU.
- damncabbage 14y ago4. sleeping while inside a monitor. ... Can someone clarify what this is?
- mkross 14y ago// 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.)
- AnthonBerg 14y agoI prefer programming in CUDA over programming in Java. However, I have a lot of respect for the Java runtime. If Rootbeer or something similar allows me to program CUDA stuff in Clojure, then I am impressed and excited.
- algad 14y agoAny security implications? Malware running on the GPU?
- Vulume 14y agoThis is already possible, but it never was a problem. The GPU is just a slave to the CPU. The biggest problem I could see would be when your computer becomes part of a botnet. Your computer could be used for brute fore encryption cracking. Again, this was also possible with just CUDA or OpenCL.
- mjs 14y ago"Rootbeer was created using Test Driven Development and testing is essentially important in Rootbeer" I'm not sure what the "essentially" means here, but this is the first "big" program I'm aware of that name-checks TDD, and a counter-example to my theory that programs where much of the programmer effort goes into algorithms and data structures are not suited to TDD. Was the TDD approach "pure"? (Only one feature implemented at a time, with absolutely no design thought given to what language features might need to be implemented in the future.)
- colomon 14y agoI'd think a project like this is ideally suited to TDD: you know what the results should be for most operations, and they are easily testable. It's the same reason the Perl 6 test suite has been so valuable to the various Perl 6 compiler projects. (Not that any of them claim to use TDD.)
- sirclueless 14y agoI agree, the biggest philosophical problem with TDD in my mind is that it neglects design -- a little foresight can make all the difference, as in that sudoku case study that went off the rails. But if you are building to a vetted, stable spec as in the case of Java, design isn't nearly as important as compliance so TDD can shine.
- skardan 14y agoHas anybody used Rootbeer with language which compiles to Java bytecode (like Clojure)? It would be interesting to see how functional languages designed for parallelism perform on gpu.
- th0ma5 14y agothis was my first thought in reading this! as other people would said you would have to think in gpu terms, but a quick glance at the code looks like you could just look into the compile functions. I hope someone out there beats me to this because they'll do a better job :D
- rbanffy 14y ago> The license is currently GPL, but I am planning on changing to a more permissive license. My overall goal is to get as many people using Rootbeer as possible. It would be bad to compromise the freedoms of the users in order to be able to limit the freedoms of more of them. Any reason why the GPLv3 would be considered unsuitable? How about the LGPLv3?
- DaNmarner 14y agoThe title captured the true character of Java: Write once, almost run almost everywhere.
- malkia 14y agoDon't spill the beans :)