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
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.
Um, 'scuse me, you got a license for the use of the word Java in that first post?
-- Oracle lawweasel
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.
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?
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.
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".