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

Why is this Go faster than the equivalent Java?

boyter.org

Post reply on HN
Print view View original

91–100 of 105 posts

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

#91

Post by weberc2 »

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.

Every time I hear this conversation play out, the Java folks point out that the GC is highly tunable/pluggable, so you can shift some levers and get lower memory consumption in exchange for more frequent collections. I'm not a GC expert, so I'm just repeating what I've heard.

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

#92

Post by ggggtez »

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…

Before I read the post I thought how I would solve it. Dynamic programming starting from end states should avoid lots of redundant work. Also making sure to sort the players by money, to reuse symmetries.

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

#93

Post by nerdwaller »

tomohawk wrote: post #66
weberc2 wrote: post #28

Earlier quoted context omitted.

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.

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.

I tend to agree from the naive Java approach, but with Java and multiple processes on the same machine they really should share a single JVM. Many people end up having one JVM per process. But the go runtime is less greedy and supports that logical thinking much more obviously.

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

#94

Post by mcguire »

weberc2 wrote: post #91
donatj wrote: post #83

Earlier quoted context omitted.

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.

Every time I hear this conversation play out, the Java folks point out that the GC is highly tunable/pluggable, so you can shift some levers and get lower memory consumption in exchange for more frequent collections. I'm not a GC expert, so I'm just repeating what I've heard.

This is true. The Java GC (and the whole VM) is one of thr most impressive pieces of software in existence. There are several GCs available, they're tunable, and they support monitoring better than any other I've seen.

No GC I know is happy without a heap several times larger than the program's requirements.

OTOH, Java programs tend to be built using frameworks that soak up memory like crazy. So there's that.

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

#95

Post by ycombobreaker »

cturner wrote: post #70
akvadrako wrote: post #56

Earlier quoted context omitted.

Java is still slow in practice, particularly due to poor startup times, due to things like class scanning and the ecosystem of bloated libraries.

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…

In my experience NASDAQ's system is both a stellar example of law-latency Java and, due to its rarity, a demonstration of the apparent difficulty. Every other trading system I have seen implemented in Java has suffered noticably from poor memory management (too much GC-related variance). I would expect that Nasdaq approaches their trading software much more like an embedded system, at which point the engineering discipline and mastery of the playform matters much more than the language.

Also as mentioned elsewhere in the thread, trading systems don't suffer from frequent cold restarts, so hotspot work amortizes extremely well. So Java is much more optimal there than e.g. a command line tool.

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

#96

Post by rusk »

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.

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

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

#97

Post by rusk »

cturner wrote: post #82
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.

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.

Really? I see perceptions Trump fact all the time …

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

#98

Post by mcguire »

rusk wrote: post #71
hehheh wrote: post #25

Earlier quoted context omitted.

And the final result was that the two languages had roughly the same performance, which may surprise folks that believe Java is still a slow language.

The reputation for slowness comes from the warm-up time. There is always a very noticeable delay starting even a simple java app; whereas a native binary is relatively instantaneous. There are tricks to alleviate this issue in java (e.g. you can keep a JVM running in the background using tool like nailgun) but the default vanilla java behaviour is what most people will be familiar with.

I wonder how much work the JVM does to handle jit-compilation and deoptimization when use patterns change.

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

#99

Post by FlyingPiranhas »

mcguire wrote: post #94
weberc2 wrote: post #91

Earlier quoted context omitted.

Every time I hear this conversation play out, the Java folks point out that the GC is highly tunable/pluggable, so you can shift some levers and get lower memory consumption in exchange for more frequent collections. I'm not a GC expert, so I'm just repeating what I've heard.

This is true. The Java GC (and the whole VM) is one of thr most impressive pieces of software in existence. There are several GCs available, they're tunable, and they support monitoring better than any other I've seen. No GC I know is happy without a heap several times larger than the program's requirements. OTOH, Java programs tend to be built using frameworks that soak up memory like crazy. So there's that.

I believe that Go's GC currently bounds heap memory usage to 2x the actual usage (worst case).

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

#100

Post by pjmlp »

rusk wrote: post #96
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.

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.

Post reply on HN