Live data from Hacker News

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

github.com

51–60 of 82 posts

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

#51
post #47

Earlier quoted context omitted.

That is an unusually long namespace. It says more about the coding style of the programmer that wrote it than it does about Java.

After a while, most Java developers start thinking it's ok to build deep hierarchies of modules.

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

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

#52
post #44

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

this 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

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

#53
post #15

Earlier quoted context omitted.

import edu.syr.pcpratts. ; 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;

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

Name conflicts are a compile error - the worst thing that can happen is that you have to change it back to an explicit include.

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

#54
post #32

Earlier quoted context omitted.

When you're using somebody else's computer.

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?

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

#55
post #50

Earlier quoted context omitted.

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 hav…

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

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

#56
post #15

Earlier quoted context omitted.

import edu.syr.pcpratts. ; 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;

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.

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

#57

Earlier quoted context omitted.

It's really not a problem when IDEs like Eclipse and Netbeans automatically handle imports for you.

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

Is this really a concern? It's like blaming C for needing an editor, what's the big deal about using an IDE for some languages. It makes you more productive and they are not heavyweight by modern laptop standards.

And even without an IDE, it's hardly that difficult to use namespaces. As has been mentioned here already, they solve a real problem, are necessary, and are much better than not having them.

This just seems like ignorant hating.

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

#58
post #45
post #42

"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 imp…

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

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

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

#59
post #26

Earlier quoted context omitted.

Well, 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…

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.
Post reply on HN