Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

71–80 of 82 posts

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

#71

Post by kaffiene »

ZoFreX wrote: post #43
raverbashing wrote: post #25

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)

It's not unbearable, I've done a huge amount of Java coding on the command-line. Yes, it's harder, but I strongly believe it's better to move onto Eclipse only after learning how the tools actually work underneath. It makes it far easier to debug weird issues with the IDE, and means you're not SOL if the IDE breaks, or you're on another person's computer - you're just a bit slower, and I'd argue that applies to all t…

Similar story. I used to do everything with Emacs. Java IDEs were able to offer more value and make me move from my standard dev environment (I have a C, C++, LISP background). The Java standard libraries are so numerous that having something to remember the names and parameters of all those methods is a huge win. I don't see how you can see this as a weakness of Java - if it were so bad, you wouldn't have so many languages launched on the JVM to take advantage of the Library ecosystem.

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

#72

Post by Vulume »

algad wrote: post #37

Any security implications? Malware running on the GPU?

This 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.

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

#73

Post by nradov »

jburwell wrote: post #48
nradov wrote: post #15

Earlier quoted context omitted.

Wildcard imports are a bad idea regardless of whether you're using an IDE or not due to the risk of future name conflicts.

This 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 ma…

There has never been any runtime performance difference between individual and wildcard imports. Compiled byte code is identical.

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

#74

Post by nradov »

hnriot wrote: post #56
nradov wrote: post #15

Earlier quoted context omitted.

Wildcard imports are a bad idea regardless of whether you're using an IDE or not due to the risk of future name conflicts.

True iff the code cannot be modified (say for example it's packaged in a jar and is closed source), otherwise this is trivially worked around on the very few times it ever happens.

This issue is irrelevant for jar files. Compiled byte code contains fully qualified class names, not import statements.

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

#75

Post by rbanffy »

raverbashing wrote: post #55
yason wrote: post #50

Earlier quoted context omitted.

Java pretty much created the concept of a modern IDE where the editor knows about the libraries and does boilerplate expansion for you. This wasn't generally needed before the age of Java.

Java also invented extreme overengineering of libraries, making it a need to have syntax completion for even trivial tasks Probably doing socket programming in C is easier than in Java (to be fair, it wasn't Java really, it was "OO evangelists" most likely, starting with C++ then going crazy with Java. Too bad they didn't even touch smalltalk

Learning OOP with Smalltalk can actually hurt your career.

I learned OOP with Smalltalk/V, wrote some apps with Actor on Windows and, when first confronted with C++ I closed the book in horror and only came back 8 years later.

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

#76

Post by rbanffy »

chc wrote: post #65
archangel_one wrote: post #21

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.

Is that why Lisps are so poorly thought of? They're designed around the idea of having a whole REPL all the time.

Do you even know what a REPL is?

It's just a way to run code interactively. "A whole REPL" is something that usually fits in 10 lines of code. With comments.

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

#77

Post by ShabbyDoo »

dman wrote: post #54
markokocic wrote: post #41

Earlier quoted context omitted.

When 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.

So you have never been asked for help from a junior developer whose development setup is different than yours?

We have a standard IDE set-up for our team and require more junior devs to use it -- a least when starting out. It makes pairing with them easier.

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

#78

Post by reeses »

dman wrote: post #54
markokocic wrote: post #41

Earlier quoted context omitted.

When 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.

So you have never been asked for help from a junior developer whose development setup is different than yours?

The junior developer who insists on not using an IDE working with Java is precisely the one who needs the most help.

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

#79

Post by phamilton »

sp332 wrote: post #59
jvc26 wrote: post #26

Earlier quoted context omitted.

To my knowledge bitcoin farmers found the hash rates of the Tesla based ec2 instances far slower than consumer grade high performance graphics cards

I'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.

AMD GPUs are better optimized for integer ops, whereas on nVidia integer ops are basically a second class citizen.

Also, AMD tends to be more cores at a lower clock rate than nVidia. For embarrassingly parallel integer operations (like hashing) AMD blows nVidia out of the water.

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

#80

Post by pmr_ »

kaffeinecoma wrote: post #38
kevingadd wrote: post #4

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.

The 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.

Post reply on HN