Why is this Go faster than the equivalent Java? • Hacker News Board

Re: Why is this Go faster than the equivalent Java?

#101

Post by boyter » Sat, Apr 01, 2017, 10:14 PM UTC

aisofteng wrote: post #52

echelon wrote: post #36

I get the sense that the author doesn't know about algorithmic complexity. This has nothing to do with language choice and everything to do with the algorithms used.

I, on the other hand, get the feeling from reading the article that the author understands that this performance difference was due to implementation differences, but wanted a more attention-grabbing title. My subjective impression is that this is the first time the author has come across this sort of consideration in implementation and wanted to write about it. There is nothing wrong with that - in fact, I think it'…

Not the first time but the first time in a while and the first time I have ever written about the process. I was literally just writing down my experience post event.

The title was just taken from the Stackoverflow post which I agree in this context is a little click baity.

I never expected it to get this much attention though, as stated in the first sentence it was just something I did for myself more than anything.

Re: Why is this Go faster than the equivalent Java?

#102

Post by dietrichepp » Sat, Apr 01, 2017, 11:37 PM UTC

Exuma wrote: post #88

dietrichepp wrote: post #38

The moment I saw the problem I started coding :-) https://gist.github.com/depp/3a6f0377284fbb9b33984063856051b... Rather than brute forcing all possible permutations, we start from all possible final states and BFS backwards towards starting states. There are probably tons of opportunities for further optimization, but this takes ~800 ms on my desktop, and it only uses one core. We don't need to track the number of t…

I feel retarded now. So if the players are randomly chosen according to the rules, doesn't that change the possible solutions? Edit: Is it because each solution must take into account every possible permutation of gameplay?

A solution is "no matter what randomly happens, the game will last at least 12 turns".

Re: Why is this Go faster than the equivalent Java?

#103

Post by rusk » Mon, Apr 03, 2017, 12:22 PM UTC

pjmlp wrote: post #100

rusk wrote: post #96

Earlier quoted context omitted.

True but these approaches have never been marketed as part of the java experience

Only by those that aren't doing Java programming. I use Java since the very early days, and am well aware of them, as are my fellow Java developers, when I work in Java projects.

Aren't you great. As a java developer I am well aware of them too. For most people java == java applets; or "hello world" with `javac Hello.java` and then `java -cp. Hello` followed by some interminable wait while all the apparatus of the JVM is marshalled for the sole purpose of emitting a static string and then exiting. And by interminable I mean 2 or 3 second but still.

Even in more enlightened scenarios a REPL on jruby is just eye-wateringly painful unless you've all the "secret speedups" enabled.

In many more modern development cultures such secrets are generally looked upon as "Yak Shaving".

Re: Why is this Go faster than the equivalent Java?

#104

Post by koffiezet » Mon, Apr 03, 2017, 3:05 PM UTC

weberc2 wrote: post #28

quanticle wrote: post #5

tl;dr: The Go implementation being faster has nothing to do with Java or Go. The version implemented in Go used a slightly different algorithm, which allowed hot inner loops to terminate early, greatly improving the performance of the algorithm.

I like Go, but it's not dramatically faster than Java. Any contest between the two of them will probably just be a back and forth of optimizations. They share pretty much the same upper bound.

Speed is not everything however, when it comes to memory usage, Java has a serious disadvantage.

Re: Why is this Go faster than the equivalent Java?

#105

Post by akvadrako » Tue, Apr 11, 2017, 4:03 PM UTC

matwood wrote: post #81

pjmlp wrote: post #73

Earlier quoted context omitted.

A situation that only occurs if one doesn't make use of JVM that cache JIT code like IBM J9, or willing to pay for an optimizing AOT compiler like Excelsior JET. Also another example is those that perceive the JVM as slow due to using it with Clojure, when the slowness in this case is caused by the Clojure implementation itself.

Even without special compilers, most people are using java on the server. Startup time happens once on deploy.

...and much more frequently during development.