5 ms·

"Let's also not forget that Java is significantly faster" Citations please. While I am not necessarily saying I don't believe you (because a properly tuned JVM

"Let's also not forget that Java is significantly faster" Citations please. While I am not necessarily saying I don't believe you (because a properly tuned JVM is lightning fast), making a statement like this without numbers to back it up is a gaping hole in your argument.

nkozyra 11y ago
As always, it depends on what you're measuring. I find it to be largely a wash http://benchmarksgame.alioth.debian.org/u64q/go.html http://benchmarksgame.alioth.debian.org/u64q/go.html Keep in mind this is comparing Go 1.4, I'd expect 1.5 to do better.
- igouy 11y ago
  Keep in mind Go 1.5 has not been released yet :-)
- TheDong 11y ago
  You say that, but because 1.5 is written in Go, it actually does significantly worse on some benchmarks and actual programs. See: https://talks.golang.org/2015/state-of-go-may.slide#11 https://talks.golang.org/2015/state-of-go-may.slide#11
- pcwalton 11y ago
  Note that the benchmarks game is going to count compile time against Java, but not against Go, since Go is AOT compiled and Java is JIT'd. If your app is a long-running server, you should take the benchmarks game numbers with a grain of salt.
  - igouy 11y ago
    JVM start-up, JIT, OSR etc take very little time relative to most of the workloads shown on the benchmarks game. http://benchmarksgame.alioth.debian.org/play.html#java http://benchmarksgame.alioth.debian.org/play.html#java The notable exception (not included in summary measurements) is the few tenths of a second run-time for meteor-contest. Of that few tenths of a second: JVM startup takes 95%, JIT and OSR another 4.9%. Whatever kind-of app you have, you should take general statements about program performance with a grain of salt, there's even a page for that -- http://benchmarksgame.alioth.debian.org/dont-jump-to-conclusions.html http://benchmarksgame.alioth.debian.org/dont-jump-to-conclus...
threeseed 11y ago
Not the best but the Techempower one is one example: https://www.techempower.com/benchmarks/#section=data-r9 https://www.techempower.com/benchmarks/#section=data-r9 And arguably more real world than microbenchmarks.
jusssi 11y ago
There are cases where the Go compiler generates horrors, and the only workaround is to write your code in asm. Here's one example: // imagine a for-loop around this s := foo[i:i+4] s[3], s[2], s[1], s[0] = s[0], s[1], s[2], s[3] The reasonable assumption is that the second line generates either zero, one, or four bounds checks on s. However, the Go compiler likes to be sure, and turns it into 8 bounds checks. I agree it's not a typical for a server to spend the majority of it's time swapping bytes. In the rare case that happens, you're going to hate the compiler for not being smarter. EDIT: fixed formatting of the example

nkozyra 11y ago

As always, it depends on what you're measuring. I find it to be largely a wash http://benchmarksgame.alioth.debian.org/u64q/go.html http://benchmarksgame.alioth.debian.org/u64q/go.html Keep in mind this is comparing Go 1.4, I'd expect 1.5 to do better.

igouy 11y ago
Keep in mind Go 1.5 has not been released yet :-)
TheDong 11y ago
You say that, but because 1.5 is written in Go, it actually does significantly worse on some benchmarks and actual programs. See: https://talks.golang.org/2015/state-of-go-may.slide#11 https://talks.golang.org/2015/state-of-go-may.slide#11
pcwalton 11y ago
Note that the benchmarks game is going to count compile time against Java, but not against Go, since Go is AOT compiled and Java is JIT'd. If your app is a long-running server, you should take the benchmarks game numbers with a grain of salt.
- igouy 11y ago
  JVM start-up, JIT, OSR etc take very little time relative to most of the workloads shown on the benchmarks game. http://benchmarksgame.alioth.debian.org/play.html#java http://benchmarksgame.alioth.debian.org/play.html#java The notable exception (not included in summary measurements) is the few tenths of a second run-time for meteor-contest. Of that few tenths of a second: JVM startup takes 95%, JIT and OSR another 4.9%. Whatever kind-of app you have, you should take general statements about program performance with a grain of salt, there's even a page for that -- http://benchmarksgame.alioth.debian.org/dont-jump-to-conclusions.html http://benchmarksgame.alioth.debian.org/dont-jump-to-conclus...

threeseed 11y ago

Not the best but the Techempower one is one example: https://www.techempower.com/benchmarks/#section=data-r9 https://www.techempower.com/benchmarks/#section=data-r9 And arguably more real world than microbenchmarks.

jusssi 11y ago

There are cases where the Go compiler generates horrors, and the only workaround is to write your code in asm. Here's one example: // imagine a for-loop around this s := foo[i:i+4] s[3], s[2], s[1], s[0] = s[0], s[1], s[2], s[3] The reasonable assumption is that the second line generates either zero, one, or four bounds checks on s. However, the Go compiler likes to be sure, and turns it into 8 bounds checks. I agree it's not a typical for a server to spend the majority of it's time swapping bytes. In the rare case that happens, you're going to hate the compiler for not being smarter. EDIT: fixed formatting of the example