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

71–80 of 105 posts

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

#71

Post by rusk »

hehheh wrote: post #25
jaimex2 wrote: post #8

I seem to be missing the point or lesson of the post? Speed comparison between two languages, botched the Java algorithm... and ...?

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.

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

#72

Post by rusk »

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…

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.

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

#73

Post by pjmlp »

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.

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.

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

#74

Post by nhumrich »

The article says he doesn't buy that Java is slow. But the JVM is a JIT with a pretty significant warm-up time. Its designed for long running processes, and if you only doing things that are running for a couple seconds, then yes, Java is slow. Java becomes fast only after it's been running for a while.

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

#75

Post by Twirrim »

chrisper wrote: post #12
sofaofthedamned wrote: post #7

I love this sort of post, and it makes me miss programming (i'm a Linux sysadmin type now) The golden age of this stuff was when I was writing stuff for the Atari ST and Amiga. Fixed hardware, manuals that came with assembly instructions and timings, etc. My greatest moment was when rewriting the Atari ST text output function. For those that don't remember, the ST had an interleaved bitmap [1] and no hardware blitter…

How is that working out for you? Isn't the pay significantly less being a sysadmin?

Depends on where you work, and whether the company recognises the complexity of the work, and the value sysadmins provide.

I make as much as my developer counterparts, for what it's worth.

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

#76

Post by weberc2 »

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.

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

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

#77

Post by hyperpape »

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…

What you've said about the JVM overhead is true, but what the experiment showed is that on the time span of six seconds, implementing an algorithm that's this simple, the overhead does not result in the Java solution being slower than the Go solution.

Full native code compilation for a hot method can be triggered and completed in a fraction of a second after startup. The net result is that for algorithmic problems that finish in seconds rather than milliseconds, the JVM startup cost may not be an issue. This will only be true if, like this problem, you're loading a small number of classes. Most people's experience with crappy JVM startup time probably has a lot to do with with web application containers like Tomcat that load thousands of classes in the first five seconds. Probably a good test to do to assess real-world performance would be something that does file-system operations and employs some parsing libraries, rather than just building data structures in memory and using System.out.

You're correct that if you want to compare peak performance, you should run the tests differently, so that you're not measuring the JVM startup cost.

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

#78

Post by hyperpape »

nhumrich wrote: post #74

The article says he doesn't buy that Java is slow. But the JVM is a JIT with a pretty significant warm-up time. Its designed for long running processes, and if you only doing things that are running for a couple seconds, then yes, Java is slow. Java becomes fast only after it's been running for a while.

The article is a counterexample to your claim. The Go program and the Java program ran in effectively the same amount of time.

I made this point in more detail upthread, but: for some CLI tasks that need to run in a few seconds, JVM performance will be adequate. For others, it will suffer.

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

#80

Post by matwood »

chrisper wrote: post #12
sofaofthedamned wrote: post #7

I love this sort of post, and it makes me miss programming (i'm a Linux sysadmin type now) The golden age of this stuff was when I was writing stuff for the Atari ST and Amiga. Fixed hardware, manuals that came with assembly instructions and timings, etc. My greatest moment was when rewriting the Atari ST text output function. For those that don't remember, the ST had an interleaved bitmap [1] and no hardware blitter…

How is that working out for you? Isn't the pay significantly less being a sysadmin?

Devops right now is very lucrative. Those that understand the cloud (AWS/GCE) and the tools (Terraform/CloudFormation/Ansible/Kub/ECS/etc...) are extremely sought after.
Post reply on HN