Rootbeer GPU Compiler Lets Almost Any Java Code Run On the GPU
An anonymous reader writes "Today the source code to the Rootbeer GPU Compiler was released as open source on github. This work allows for a developer to use almost any Java code on the GPU. It is free, open source and highly tested. Rootbeer is the most full featured translator to convert Java Bytecode to CUDA. It allows arbitrary graphs of objects to be serialized to the GPU and the GPU kernel to be written in Java." Rootbeer is the work of Syracuse University instructor Phil Pratt-Szeliga.
This work allows for a developer to use almost any Java code on the GPU.
Except for the code my students write. :rolleyes:
Taking guns away from the 99% gives the 1% 100% of the power.
Maybe now the x264 developers will add GPU support and we'll finally have a solution for video encoding that uses the processor and GPUs in parallel. Here's to hoping... :\
#fuckbeta #iamslashdot #dicemustdie
The WORA aspects of Java work flawlessly these days.
Mod me down, my New Earth Global Warmingist friends!
2004 called, they want their blind hate for Java back.
Used intelligently by a skilled programmer, Java can deliver great results and provide exactly the sort of cross platform capabilities it was designed for. Used by idiots and/or kids who just earned that undergrad CS degree, it tends to provide less.
-Lod
2004 called, they want their blind hate for Java back.
Used intelligently by a skilled programmer, Java can deliver great results and provide exactly the sort of cross platform capabilities it was designed for. Used by idiots and/or kids who just earned that undergrad CS degree, it tends to provide less.
Just like any other programming language?
This is simply not true for code written by a professional and competent Java developer (note: part of my consulting gig means I code Java on a professional basis).
If you write only to the public APIs then Java truly is Write-Once-Run-Anywhere (although some bad Java developers use internal functionality that can change between Java versions - I'm guessing that perhaps these folks are used to coding to the Undocumented APIs of Win32 that you used to have to use to get things done). In Java you shouldn't do this. IIRC, Sun created around ten thousand unit tests to ensure Java worked correctly on each platform (wonderful, they did all the porting and port testing effort so Java developers don't have to).
Aside from my professional coding (where Java written on a Mac works flawlessly when deployed to Linux and Windows servers) in my spare time I'm working on modern jet air combat simulator in Java. The same Java+JoGL code works flawlessly on Mac, Linux and Windows. Any differences are in capabilities/performance of individual graphics cards (AMD/ATI vs NVidia).
This article about being able to write Java for the GPU is very interesting, since writing shaders via OpenGL is a little bit of a PITA (there is an impedance mismatch between the conventions of Java, OpenGL and GLSL - it would be fabulous to just write in Java [akin to how I can do this on the Web using Google Web Toolkit]).
So I don't think your statement is really true - except for buggy software written by developers who have bad simple-platform habits.
Usually there is only a problem when your application server (I'm looking at you, stinky Websphere) relies on a particular vendor's implementation of Java (eg. IBM JDK). With recent Sun/Oracle Java Runtime Environments (that is: Java 6, which is around 5 years old; and Java 7) applications usually run flawlessly (at least, mine do - and I'm doing all the usual Java funky stuff: radar, roadsign and head tracking hardware device control, networking, web, 3D graphics, rich clients, etc).
As a current practitioner in the field I wonder whether your experience is from a long time ago (and polluted by the experience of using software that was based on Microsoft's awful [and deliberately incompatible - which they lost the famous lawsuit over] Java implementation from a long time ago).
It's CUDA only, meaning it does not support any open standards. Call me when when I can target OpenCL.
---- GENERATION 26: The first time you see this, copy it into your sig on any forum and add 1 to the generation.
released as open source on github
Damn, Slashdot, I almost had a freaking heart attack when I moused over (you don't think I actually clicked do you? New here?) the link in the summary and it was to the actual github page rather than some crappy 10 page blog post based on something pulled off the reuters wire from last week.
I'm impressed!
The soylentnews experiment has been a dismal failure.
You must run some VERY different apps than I do. Every management app I've used seems to be tied to different versions of java everything for ui glitches though plain just not working.
No sir I dont like it.
Um, 'scuse me, you got a license for the use of the word Java in that first post?
-- Oracle lawweasel
Primarily with those java management apps related to networking kit. You know those things that are embedded in firmware and sometimes the only way to do more than get an IP on the box to get to said java nightmare. I've had the issues as recent as a few weeks ago when a java update stopped some dialog boxes from working on a supermicro ipkvm java app. Same update killed all my ASDM java apps for working with CIsco ASA's (though it still works as a web app for whatever reasons)
No sir I dont like it.
He means it would be too slow to fly to java before posting from an internet cafe.
http://michaelsmith.id.au
Why is any hack done? Because it can be.
Here, from GitHub, is the short presentation. This is very impressive. It finds parallelism automatically, at least for simple cases. Over 50x performance improvement on matrix multiply and naive Fourier transform (not FFT), both of which have very simple inner loops. Not clear how it does on less obvious problems.
Yeah I guess I do. I tend to use good software.
Java doesn't have a monopoly on shitty software.
Mod me down, my New Earth Global Warmingist friends!
I rarely see problems involving new releases of Java... with one specific exception: 64-bit Java. I've seen more than a few apps that die horrible deaths with 64-bit Java... and almost exactly the same number that specifically *require* 64-bit Java when running under 64-bit Windows.
I'm still trying to figure out what, exactly, causes some random Java app to specifically require one or the other when running under Win7/64. I suspect it has something to do with changes Microsoft made to 64-bit Windows that forced (or at least induced) Sun, then Oracle, to change something major with 64-bit Java... but I've never seen any white paper or article that identifies and explores the specific reasons why this might be so. I'm sure the mass layoffs and exodus of Sun's employees right around the time 64-bit Java became relevant, and 64-bit Windows became mainstream, didn't help.
No, *you* get to dictate the licence of your software. It is *you* who chooses to use a GPL library in your code.
The Author of the GPL code did not put a gun to your head and forced you to choose their code.
This is simply not true for code written by a professional and competent Java developer (note: part of my consulting gig means I code Java on a professional basis).
If you write only to the public APIs then Java truly is Write-Once-Run-Anywhere (although some bad Java developers use internal functionality that can change between Java versions - I'm guessing that perhaps these folks are used to coding to the Undocumented APIs of Win32 that you used to have to use to get things done). In Java you shouldn't do this. IIRC, Sun created around ten thousand unit tests to ensure Java worked correctly on each platform (wonderful, they did all the porting and port testing effort so Java developers don't have to).
Aside from my professional coding (where Java written on a Mac works flawlessly when deployed to Linux and Windows servers) in my spare time I'm working on modern jet air combat simulator in Java. The same Java+JoGL code works flawlessly on Mac, Linux and Windows. Any differences are in capabilities/performance of individual graphics cards (AMD/ATI vs NVidia).
This article about being able to write Java for the GPU is very interesting, since writing shaders via OpenGL is a little bit of a PITA (there is an impedance mismatch between the conventions of Java, OpenGL and GLSL - it would be fabulous to just write in Java [akin to how I can do this on the Web using Google Web Toolkit]).
So I don't think your statement is really true - except for buggy software written by developers who have bad simple-platform habits.
I would tend to disagree. Why? Because companies like cisco, ibm, etc. all only certify certain versions of java for use in their applications. The cisco apps are cross platform but do NOT play well with different versions of java. I'm not a java expert (I'm a C#/RoR guy) but if fortune 500 companies can't get it right, can you really say that java is cross version compatible?
Hello, I am thinking maybe I will use the Apache license...
We have some (too expensive to justify replacing) facilities control modules at work whose 'web interface' consists of a java applet that won't run on anything more recent than J2SE 1.4(early 2002, for those keeping score).
Given the relative costs of replacing the module(the closest thing to a firmware update that the vendor offers) and just maintaining a VM snapshot of a decade-old java setup, we obviously went with the latter.
I have no particular reason to believe that java itself is to blame, rather than merely being the instrument of somebody's apathy and/or incompetence; but there are definitely some special applications floating around.
Considering the approach that Oracle is taking of trying to copyright and charge license fees just for using the Java API's (see Oracle vs Google) I cant see any sane person developing on a non-Oracle provided Java platform. If they can sue Google for Dalvik they can certainly sue whoever deploys Rootbeer if they feel like it.
pgmer6809
Congratulations on inventing C++
Don't quote me on this.
Shouldn't title mention "nVidia GPU" or did I miss that AMD now supports CUDA on top of OpenCL?
They don't "own your code" in any sense. If you violate the license, you're committing copyright infringement, but it has no effect on the copyright status of your own work.
yeah, you can even automate it..
now, I wonder if this gpu project could be used to run http://www.ode4j.org/ ..(ode for java is a port of a c/c++ physics lib to java, mostly automated conversion. it actually works pretty nicely.)
world was created 5 seconds before this post as it is.
> I'm not a java expert (I'm a C#/RoR guy) but if fortune 500 companies can't get it right, can you really say that java is cross version compatible?
Is that your argument? Just because corporate developers (including a lot of C# guys, but there are always exceptions) are often morons doesn't mean Java blows - these guys can and do butcher any technology when they build stuff (hell, even after giving one guy proper code for calculating any date he come back with his shitty VB.NET that was an abomination and had so many holes).
I've written a *lot* of different systems in Java. From embedded, web, graphical, network, rich client etc and the version gotchas (there are minor things you learn to avoid) are nothing in Java compared to the C, C++ and C# systems I used to work on. Hence, my statements.
Bro, you simply have a bias against Java and this means you are not reasoning fully. Admit this to yourself. People can (with some effort) write cross-platform C and C++ apps, yet people often write apps that fall over with new service packs to their operating system. Yet you choose to blame a particular technology rather than accept that , "You can write bad FORTRAN in any language".
Would be nice to actually see this great quality java code in the wild.
We have a ton of server-side java *crap*. It is all crap. I have never seen a java server app that did proper logging-- seems all server-side java coders think uncaught exceptions leading to stack traces are "super cool".
On the client side, things like the java app to manage Brocade FC switches will sometimes show 90% of the zones missing! Oh, you kill all java instances and re-run it, and all is cool. Yeah, java is great.
In the early 90s I was a believer, but too many crappy experiences with java-- now, when I hear java, I just assume total piece of shit until proven otherwise (which is _super rare_; being generous-- I can't think of anything great written in java off the top of my head)
There's no point in singling out Java for any of that. As long as the order of the day is cheaper software produced faster instead of spending time and money to get quality, software is going to be garbage.
I do know some really excellent java apps, and a very large quantity of excellent open-source java support libraries, but the finest tools in the hands of 15-rupee/hour junior programmers working to a fantasy schedule aren't going to produce them.
I provide a lot of advice to Java programmers, and one of the top items I warn them to do is use logging. My own stuff not only logs extensively, it even sends me email for the really dire stuff. As far as letting exceptions fall out on the floor goes, that's a mortal sin in my book.
Of course, because I DO have quality standards, I just get yelled at for not being "productive" enough.
> I'm not a java expert (I'm a C#/RoR guy) but if fortune 500 companies can't get it right, can you really say that java is cross version compatible?
Is that your argument? Just because corporate developers (including a lot of C# guys, but there are always exceptions) are often morons doesn't mean Java blows - these guys can and do butcher any technology when they build stuff (hell, even after giving one guy proper code for calculating any date he come back with his shitty VB.NET that was an abomination and had so many holes).
I've written a *lot* of different systems in Java. From embedded, web, graphical, network, rich client etc and the version gotchas (there are minor things you learn to avoid) are nothing in Java compared to the C, C++ and C# systems I used to work on. Hence, my statements.
Java is pretty much unique in its inherent support for cross-version support. There's a special deprecation annotation you can attach to any function or class that causes warnings if you attempt to use downgraded features. You won't find that in C/C++ or VB. In fact, one reason I bailed from Microsoft was that not only was I routinely getting nailed on MS apps to the degree that in extreme cases, I was looking at re-installing an old OS so I could install an old IDE so I could use an old compiler to make a 2-line emergency change, MS would routinely replace an entire API with a totally incompatible one. I got nailed hard on this with SOAP, but the Database API-of-the-day way outright comical - they wouldn't even have the kinks out of the previous one before the next one came along.
With Java's deprecation, you can make your panic fixes, note the deprecation warnings, and make proper version-related updates when things are less stressful (yeah, like that ever happens). The actual Sun-supplied deprecations tend to live forever, so even some items deprecated from Java Version 1 can still be used/abused today. They are a bit weak on the clairvoyance features, however, so forward version dependencies are a bit hit and miss.
The primary reason that major vendors are so picky about JVM brands and versions is that they want to keep their support costs down and even in a strict version-supportive environment like Java, the smaller the number of permutations, the better. Even when the language itself is supportive, the bugs vary from release to release, and yes, some "clever" application programmers do code to internal implementation details or mis-read specs.
I think they started developing Android way before a first release of a Android phone? From wikipedia:
> Android, Inc. was founded in Palo Alto, California, United States in October 2003 [...] Google acquired Android Inc. on August 17, 2005, making Android Inc. a wholly owned subsidiary of Google.
> On 17 November 2006, Sun announced that it would be released under the GNU General Public License (GPL), thus making it free software. This happened in large part on 8 May 2007;
> J2SE 5.0 (September 30, 2004)
So I think Palo Alto started development of Android in 2003, which at that time Java 1.4 was available.
I'm not a lawyer, but since APIs are only a dictionary of methods, classes, (i.e. of names or facts) they are not protected by the copyright law. Please go to http://www.groklaw.net/staticpages/index.php?page=OracleGoogle to a better explanation.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute