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

61–70 of 105 posts

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

#61

Post by bitcharmer »

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 compiler thread, and probably a few more of those either optimising other, less hot parts of the code, or applying more aggressive optimizations on already JITed sections.

Go comes with AOT compilation and as far as I know, doesn't have much initial overhead. For a test that takes few seconds to complete, I'd say this is not how you want to compare performance.

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

#62

Post by eru »

stonemetal wrote: post #24
chrisper wrote: post #15

Earlier quoted context omitted.

I am a bit confused about what you are referring to. Are you saying that we do not have many choices when it comes to work? I am about to graduate, but a lot of people seem to be saying that once you gain experience it is easy to hop to different jobs.

After a while you get pigeonholed. You can hop jobs easily but it is the same shit, different name on the building. It is often easier to pivot inside a company then jump to a new company.

I found it pretty easy so far. But I am willing to relocate intercontinentally---so there's less pressure on me to agree to the pigeonholing anyone might want to attempt.

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

#63

Post by tboerstad »

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…

Wow, this is beautiful C++ code! High level abstractions, not hiding any of the nitty gritty details, parallelism and all, yet very readable. Well done!

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

#64

Post by eru »

aisofteng wrote: post #50
pjmlp wrote: post #46

Earlier quoted context omitted.

Urban legends tend to live forever.

I think that there is probably a large overlap between the population of people who believe this and the population of people that don't really know what bytecode or JIT compilation are. In fact, I have asked a number of people under the impression that Java is slow to explain why they think it is slow. The answers have two flavors: 1. Its high level abstractions are computationally expensive. Sometimes this idea is…

Number 2 is especially funny: isn't LLVM doing something similar-ish for C++?

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

#65

Post by eru »

chrisper wrote: post #15
sillysaurus3 wrote: post #14

Earlier quoted context omitted.

It's illusory to think that we have a choice. It's hard to avoid becoming obsolete over a long timespan.

I am a bit confused about what you are referring to. Are you saying that we do not have many choices when it comes to work? I am about to graduate, but a lot of people seem to be saying that once you gain experience it is easy to hop to different jobs.

It is, if you avoid getting stuck in a ghetto. Mobility on your part helps, too. (Both in a metaphorical sense, but also very directly: you are obviously going to have a bigger pool of potential suitors when the world is your oyster than when you are restricting yourself to one metro area.)

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

#66

Post by tomohawk »

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.

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.

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

#67

Post by therpe1 »

wuch wrote: post #58
aisofteng wrote: post #50

Earlier quoted context omitted.

I think that there is probably a large overlap between the population of people who believe this and the population of people that don't really know what bytecode or JIT compilation are. In fact, I have asked a number of people under the impression that Java is slow to explain why they think it is slow. The answers have two flavors: 1. Its high level abstractions are computationally expensive. Sometimes this idea is…

Controlling memory layout is one area that is very important for performance, where Java does not exactly shines. You essentially have to store your data in arrays of primitive types, to avoid memory overhead of objects (pointer to class, lock, gc bits) and additional indirection during access. While not exactly impossible, Java makes it quite inconvenient and costly to write code that takes control of memory layout.

It's worth pointing out that:

1) Controlling memory layout is not as big a deal as people think. The JVM is highly optimized (really it's probably the most optimized system ever devised) for allocating and deallocating objects on the heap.

2) It is in fact possible to control memory layout today because Java has access to offheap memory where you can have all the control you want.

This has actually been the case for nearly half a decade but for some reason a lot of people are convinced that "big arrays" can knock over the JVM.

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

#68

Post by swah »

tboerstad wrote: post #63
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…

Wow, this is beautiful C++ code! High level abstractions, not hiding any of the nitty gritty details, parallelism and all, yet very readable. Well done!

I felt the same - not that worse than in a modern language (of course someone should rewrite in Go with the new algorithm so we can decide if it would be good enough :)

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

#69

Post by pjmlp »

eru wrote: post #64
aisofteng wrote: post #50

Earlier quoted context omitted.

I think that there is probably a large overlap between the population of people who believe this and the population of people that don't really know what bytecode or JIT compilation are. In fact, I have asked a number of people under the impression that Java is slow to explain why they think it is slow. The answers have two flavors: 1. Its high level abstractions are computationally expensive. Sometimes this idea is…

Number 2 is especially funny: isn't LLVM doing something similar-ish for C++?

Kind of.

In any case, bytecode as executable format, goes back to the early days when CPU were microprogrammed.

It was also a common approach on mainframes, with OS/400 being the best example.

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

#70

Post by cturner »

akvadrako wrote: post #56
pjmlp wrote: post #46

Earlier quoted context omitted.

Urban legends tend to live forever.

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 foundation of fast, complex distributed systems, particularly if you need multiple programmers working on a single source tree.
Post reply on HN