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

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

#81

Post by matwood » Sat, Apr 01, 2017, 1:59 PM UTC

pjmlp wrote: post #73

rusk wrote: post #72

Earlier quoted context omitted.

Yes Java is as quick as anything else once it is up and running ; the point GP was making was getting to this warmed up state is what makes people perceive java as slow.

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.

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

#82

Post by cturner » Sat, Apr 01, 2017, 2:00 PM UTC

rusk wrote: post #72

cturner wrote: post #70

Earlier quoted context omitted.

Java is not slow in practice. Many top trading systems have been written in it, including the excellent and widely licensed nasdaq architecture (omx, singapore, asx, swx, etc) and the independently designed Lmax Disruptor. You do not have to use any library you don't want to. there is nothing stopping you from building everything in preallocated byte arrays, and never triggering gc. Nio2 is fast. Jvm is a leading fou…

Yes Java is as quick as anything else once it is up and running ; the point GP was making was getting to this warmed up state is what makes people perceive java as slow.

You wrote about preceptions in another part of the thread. But that's not what I replied to. The words are above, and it wasn't about perceptions.

But on perceptions: naive perceptions don't justify a false statement. So why draw focus to them, why excuse them? Facts trump perceptions.

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

#83

Post by donatj » Sat, Apr 01, 2017, 2:19 PM UTC

weberc2 wrote: post #76

tomohawk wrote: post #66

Earlier quoted context omitted.

Given a specific machine with a set amount of cpu, ram, and io bandwidth, I find I can easily do more on that machine with go than java. Also, try running multiple java processes on a machine as opposed to multiple go programs.

So could I. I imagine a Java aficionado would say the opposite. Like I said, different ways to think about the problem.

To the posters point about running multiple Java aaps on a single machine, I think ram is the real issue. Java makes in my experience far less frugal use of it. I've seen Java applications eat hundreds of mbs of ram rewritten in Go using 1-2 mb.

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

#84

Post by vinceyuan » Sat, Apr 01, 2017, 2:42 PM UTC

donatj wrote: post #83

weberc2 wrote: post #76

Earlier quoted context omitted.

So could I. I imagine a Java aficionado would say the opposite. Like I said, different ways to think about the problem.

To the posters point about running multiple Java aaps on a single machine, I think ram is the real issue. Java makes in my experience far less frugal use of it. I've seen Java applications eat hundreds of mbs of ram rewritten in Go using 1-2 mb.

Exactly. Go app uses much less RAM than Java app.

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

#85

Post by chrisper » Sat, Apr 01, 2017, 2:53 PM UTC

eru wrote: post #60

chrisper wrote: post #30

Earlier quoted context omitted.

Hmm... I was asking because I am about to graduate in CS. But I think I like Sysadmin stuff more.

If you can program well, and like some aspects of sysadmin-ing, then becoming a Site Reliability Engineer (at eg Google) might be for you. There are always looking for people. (I used to work as an SRE, before I made my way back into functional programming and finance recently.)

Thanks. I'll look into that.

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

#86

Post by jnordwick » Sat, Apr 01, 2017, 3:06 PM UTC

aisofteng wrote: post #48

thwarted wrote: post #34

Earlier quoted context omitted.

Continue with your CS degree. In my experience, all good sysadmins have significant development experience. This is especially useful when working at small companies/startups.

I'd like to counter (but not disagree) with: in my experience, all good developers have significant sysadmin experience, whether professionally or self-taught. As a tech lead of a team that is largely junior, I keep running into places where a lack of sysadmin-type knowledge seriously harms the ability of a CS degree holder (anywhere from BSc to PhD) to do real-world software engineering work unless they have either…

I'm a greaat developer, but a terrible sysadmin. I just don't have the mentality for it. I can pick up pieces, and I know the hardware, but I'll never me a good sysadmin. I have a lot of unix experience, but setting up my own laptop is always a beast of effort. I don't want to ever setup a continuous integration systems with source repo. I'll make a mess of it.

However, if you haven't had networking experience in college, you went to a terrible program. I had exposure to networking (at Cal) in 3-4 classes.

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

#87

Post by jnordwick » Sat, Apr 01, 2017, 3:13 PM UTC

bitcharmer wrote: post #61

I'm surprised the warmup problem in Java hasn't been invoked here yet. Java has bootstrap and warm-up overhead which for comparisons like this one may have a decisive impact on the perceived results. What will happen is (after the JVM starts), there will be (by default) 10000 interpreted iterations, then shortly after that a stop-the-world pause to replace slow interpreted code with its native counterpart JITed by a…

There is no stop the world point. There are compilation threads always running in the background patching hot code.

In Java 8 tiered compilation became the default. After a first threshold is reached, a method or loop will be compiled as a first approximation with further record keeping. At the second threshold, a more aggressively optimized version without record keeping will be put in place. This is kind of like the merging of the old C1 and C2 compilers into one to help get up to speed quicker.

When you want to measure this stuff you use JMH, Java Microbenchmarking Harness, an amazing piece of work that will warmup the JVM before executing performance tests. Be very careful writing your own Java timing code, and for the most part rely on JMH.

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

#88

Post by Exuma » Sat, Apr 01, 2017, 3:35 PM UTC

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?

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

#89

Post by todd8 » Sat, Apr 01, 2017, 3:39 PM UTC

segmondy wrote: post #51

That problem is that type of problem that is well suited for a prolog system with a constraint library.

Some of these types of problems can indeed be turned over to a constraint solver. I'd love to see a comparison with Prolog. Has anybody tried it?

The problem that I see with Prolog in this case is that a simple solution is simple because it is turning the search over to Prolog's built in constraint solver that knows nothing of the problem. This often leads to unacceptable performance with Prolog; performance problems can sometimes be addressed in practice by the appropriate placement of the cut operator within the logical specification of the constraints. This, at least in my experience, makes understanding what the program is doing very difficult.

Generally, I view Prolog (along with languages like Smalltalk) as a language appropriate for some problem domains that have come to the end of their lifetime because mainline, more generally useful, languages have adopted their features or incorporated them in libraries.

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

#90

Post by Ari_Rahikkala » Sat, Apr 01, 2017, 3:40 PM UTC

Just for the sake of having another solution for the same problem, here's the basically-zero-thought-required brute-force search solution in C: https://gist.github.com/arirahikkala/ef1a07dbd5a8ca3a077c03c...

Not as fast as dietrichepp's solution, but not terrible either, and probably the winner in terms of memory use. Since there's no state to keep track of, adding parallelism with OpenMP was trivial, too.