15 ms·

One wonders what Go was doing with that extra 36% time in the previous version. Was it all due to map memory allocation and associated cache misses?

by afhof 14y ago

enneff 14y ago
It's hard to point the finger at any one thing. There have been improvements to the map implementation, the compiler's code generator, the runtime's scheduler and garbage collector, and many parts of the standard library.
dsymonds 14y ago
Go 1.1 has a much better map implementation, with fast-paths for common key types such as strings.
coldtea 14y ago
Well, 36% is not a large improvement at all, considering Go is still slower than Java. Go has a some way to go still and it can be improved in all areas: GC, algorithms, heuristics, code generation, ...
- jburgueno 14y ago
  36% is awesome! And it's proves that Go still got lot of space for growing.
- cmccabe 14y ago
  Slower than Java at what? At program startup time? Java is a joke in this area. At memory consumption? Java has a high fixed memory cost. It also uses more memory than Go does. There are fundamental reasons for this. Java needs to keep around runtime type information because the code can change at runtime due to new classes being loaded. Go does not. Java also chose to implement a scheme where any object can serve as a mutex or condition variable. The result is a few words of extra memory per object when compared with Go... usually somewhere in the neighborhood of 8 or 16 bytes per object, depending on architecture. Using memory efficiently is HUGE in modern architectures and Go is better at that. Go also gives you more control over how your program uses memory. This is because Go has both pointers and value types. The result is that things that would have had to be "boxed" (i.e. separate memory allocations) in Java can be unboxed in Go. If you know C, think of it as the difference between doing a malloc for each structure element, and just having a bunch of structs stored by value inside another struct. Go is faster at interfacing with native code. Have you checked the speed of JNI lately? Speaking as someone who's written a lot of JNI... it's not pretty. Java still has the edge in one area: HotSpot has a precise garbage collector, something Go doesn't currently have. But I have a feeling that gap is going to be closed. Note: I am oversimplifying the unboxing discussion a bit. In theory, it might be possible to unbox certain structures in Java, such as non-nullable final fields. However, Go preserves a lot more of the intentions of the programmer in this regard-- and without knowing how the programmer intended to use the memory, most optimizers will struggle.
  - trailfox 14y ago
    For most applications the startup time is irrelevant. The startup time of a server app which runs for months is not an interesting data point. The throughput in requests per second is far more important and this is where the JVM has been very strong (3x faster than Go 1): http://www.techempower.com/blog/2013/03/28/framework-benchmarks/ http://www.techempower.com/blog/2013/03/28/framework-benchma... Memory consumption is often not a major concern on modern systems, saving 50 MB or even 500 MB is seldom as important as the ability to process more requests per second. I'm busy learning Go, and am very impressed by the performance gains in 1.1 (and GC improvements). My main concern at the moment is how much less expressive the language is relative to Python, Scala and Ruby. Go is fast, but so is Scala, and Scala is also very expressive compared to Go. Go has a definite edge in environments where memory footprint is important and simple interfacing with native libraries is critital. Scala and the JVM are still more appealing to me in most other areas.
    - agentS 14y ago
      To be fair, I would rather write this: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/go/hello.go https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... rather than this: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/netty/src/main/java/hello/HelloServerHandler.java https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... (not to mention the 2 other Java files to setup the server).
      - icebraining 14y ago
        Well, that's using a particular framework (netty). Play seems much simpler.
        coldtea 14y ago
        Not to mention this gives you a lot of flexibility and quite a battle tested backend, whereas the Go equivalents are still mostly in progress and less flexible. Oh, and in the recent shootout, netty gets to 30,000 rpm, whereas Go peaks around 10,000.
- ghshephard 14y ago
  On HN there is usually a pretty high bar for making comments regarding performance, stability, etc... I'm actually interested in what you have to share regarding performance characteristics of Go versus Java - but a bit more detail than, "Go has a some way to go still and it can be improved in all areas: GC, algorithms, heuristics, code generation," would be useful, particularly in comparison to Java, which you have called out. Also - I think 36% is a pretty amazing improvement - particularly if Google can persist these performance increases.
  - trailfox 14y ago
    I agree that his comment need to provide more data. I also find that HN in general is very quick to downvote comments critical of Go, even well reasoned ones with sources. In terms of performance data check out quad core results for Go 1 (go 1.1 would need to improve by considerably more than 33% to best the JVM): http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?test=all&lang=go&lang2=java http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t... Also see Netty (Java) outperforming go by a wide margin here: http://www.techempower.com/blog/2013/03/28/framework-benchmarks/ http://www.techempower.com/blog/2013/03/28/framework-benchma... The poster's comments regarding GC, heuristics and code generation are vague, but it's no secret that IBM/Sunoracle and co. have very sophisticated GC and JIT implementations which they have been optimizing for 15+ years and it shows through in the benchmark results. I like Go, I just think that we need to be wary of expecting it to be as fast as the JVM and even MSCLR straight out the gate. It will likely take years to reach that level of sophistication.
    - pjmlp 14y ago
      > I also find that HN in general is very quick to downvote comments critical of Go, even well reasoned ones with sources. I am sure if Go wasn't being done at Google, most hackers would actually ignore it. Just check how successful the Go like predecessors from the authors were, when working at other companies. I think the language suffers from an hallo effect.
      - enneff 14y ago
- dscrd 14y ago
  According to the Shootout, Go-1.1 is only slower on a few tests than Java, while being a bit faster on most and while typically using way less memory.
  - voidlogic 14y ago
    Win some, lose some: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=java http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te... Note: The much faster version Go's DNA regex that uses PCRE rather than "regexp", but it is currently broken due to a build error. (http://benchmarksgame.alioth.debian.org/u64/program.php?test=regexdna&lang=go&id=7 http://benchmarksgame.alioth.debian.org/u64/program.php?test...)
    - igouy 14y ago
      Let's also note that the Go regex-dna programs run out of memory on x86 :-(
      - voidlogic 14y ago
        u32 using 1.0.3 does, but u32q does not: http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?test=regexdna&lang=go&lang2=gcc&id=1 http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t...
        igouy 14y ago
        Thanks, let's hope that holds for the Go #7 program.
  - trailfox 14y ago
    The quad core results indicate the exact opposite in terms of performance with the JVM clearly ahead: http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?test=all&lang=go&lang2=java http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t... Go uses less memory than Java 7, but then again so does Java 1.1
voidlogic 14y ago
In addition to the improvements from the improved scheduler, use of accept4 on Linux, better GC and code generation, Brad Fitzpatrick has been giving a lot of love to the "net/http" package. Here is a small example: https://plus.google.com/u/0/115863474911002159675/posts/L3o9hEs8SAe https://plus.google.com/u/0/115863474911002159675/posts/L3o9...

One wonders what Go was doing with that extra 36% time in the previous version. Was it all due to map memory allocation and associated cache misses?

by afhof 14y ago

One wonders what Go was doing with that extra 36% time in the previous version. Was it all due to map memory allocation and associated cache misses?

enneff 14y ago

It's hard to point the finger at any one thing. There have been improvements to the map implementation, the compiler's code generator, the runtime's scheduler and garbage collector, and many parts of the standard library.

dsymonds 14y ago

Go 1.1 has a much better map implementation, with fast-paths for common key types such as strings.

coldtea 14y ago

Well, 36% is not a large improvement at all, considering Go is still slower than Java. Go has a some way to go still and it can be improved in all areas: GC, algorithms, heuristics, code generation, ...

jburgueno 14y ago
36% is awesome! And it's proves that Go still got lot of space for growing.
cmccabe 14y ago
Slower than Java at what? At program startup time? Java is a joke in this area. At memory consumption? Java has a high fixed memory cost. It also uses more memory than Go does. There are fundamental reasons for this. Java needs to keep around runtime type information because the code can change at runtime due to new classes being loaded. Go does not. Java also chose to implement a scheme where any object can serve as a mutex or condition variable. The result is a few words of extra memory per object when compared with Go... usually somewhere in the neighborhood of 8 or 16 bytes per object, depending on architecture. Using memory efficiently is HUGE in modern architectures and Go is better at that. Go also gives you more control over how your program uses memory. This is because Go has both pointers and value types. The result is that things that would have had to be "boxed" (i.e. separate memory allocations) in Java can be unboxed in Go. If you know C, think of it as the difference between doing a malloc for each structure element, and just having a bunch of structs stored by value inside another struct. Go is faster at interfacing with native code. Have you checked the speed of JNI lately? Speaking as someone who's written a lot of JNI... it's not pretty. Java still has the edge in one area: HotSpot has a precise garbage collector, something Go doesn't currently have. But I have a feeling that gap is going to be closed. Note: I am oversimplifying the unboxing discussion a bit. In theory, it might be possible to unbox certain structures in Java, such as non-nullable final fields. However, Go preserves a lot more of the intentions of the programmer in this regard-- and without knowing how the programmer intended to use the memory, most optimizers will struggle.
- trailfox 14y ago
  For most applications the startup time is irrelevant. The startup time of a server app which runs for months is not an interesting data point. The throughput in requests per second is far more important and this is where the JVM has been very strong (3x faster than Go 1): http://www.techempower.com/blog/2013/03/28/framework-benchmarks/ http://www.techempower.com/blog/2013/03/28/framework-benchma... Memory consumption is often not a major concern on modern systems, saving 50 MB or even 500 MB is seldom as important as the ability to process more requests per second. I'm busy learning Go, and am very impressed by the performance gains in 1.1 (and GC improvements). My main concern at the moment is how much less expressive the language is relative to Python, Scala and Ruby. Go is fast, but so is Scala, and Scala is also very expressive compared to Go. Go has a definite edge in environments where memory footprint is important and simple interfacing with native libraries is critital. Scala and the JVM are still more appealing to me in most other areas.
  - agentS 14y ago
    To be fair, I would rather write this: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/go/hello.go https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... rather than this: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/netty/src/main/java/hello/HelloServerHandler.java https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... (not to mention the 2 other Java files to setup the server).
    - icebraining 14y ago
      Well, that's using a particular framework (netty). Play seems much simpler.
      - coldtea 14y ago
        Not to mention this gives you a lot of flexibility and quite a battle tested backend, whereas the Go equivalents are still mostly in progress and less flexible. Oh, and in the recent shootout, netty gets to 30,000 rpm, whereas Go peaks around 10,000.
ghshephard 14y ago
On HN there is usually a pretty high bar for making comments regarding performance, stability, etc... I'm actually interested in what you have to share regarding performance characteristics of Go versus Java - but a bit more detail than, "Go has a some way to go still and it can be improved in all areas: GC, algorithms, heuristics, code generation," would be useful, particularly in comparison to Java, which you have called out. Also - I think 36% is a pretty amazing improvement - particularly if Google can persist these performance increases.
- trailfox 14y ago
  I agree that his comment need to provide more data. I also find that HN in general is very quick to downvote comments critical of Go, even well reasoned ones with sources. In terms of performance data check out quad core results for Go 1 (go 1.1 would need to improve by considerably more than 33% to best the JVM): http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?test=all&lang=go&lang2=java http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t... Also see Netty (Java) outperforming go by a wide margin here: http://www.techempower.com/blog/2013/03/28/framework-benchmarks/ http://www.techempower.com/blog/2013/03/28/framework-benchma... The poster's comments regarding GC, heuristics and code generation are vague, but it's no secret that IBM/Sunoracle and co. have very sophisticated GC and JIT implementations which they have been optimizing for 15+ years and it shows through in the benchmark results. I like Go, I just think that we need to be wary of expecting it to be as fast as the JVM and even MSCLR straight out the gate. It will likely take years to reach that level of sophistication.
  - pjmlp 14y ago
    > I also find that HN in general is very quick to downvote comments critical of Go, even well reasoned ones with sources. I am sure if Go wasn't being done at Google, most hackers would actually ignore it. Just check how successful the Go like predecessors from the authors were, when working at other companies. I think the language suffers from an hallo effect.
    - enneff 14y ago
dscrd 14y ago
According to the Shootout, Go-1.1 is only slower on a few tests than Java, while being a bit faster on most and while typically using way less memory.
- voidlogic 14y ago
  Win some, lose some: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=java http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te... Note: The much faster version Go's DNA regex that uses PCRE rather than "regexp", but it is currently broken due to a build error. (http://benchmarksgame.alioth.debian.org/u64/program.php?test=regexdna&lang=go&id=7 http://benchmarksgame.alioth.debian.org/u64/program.php?test...)
  - igouy 14y ago
    Let's also note that the Go regex-dna programs run out of memory on x86 :-(
    - voidlogic 14y ago
      u32 using 1.0.3 does, but u32q does not: http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?test=regexdna&lang=go&lang2=gcc&id=1 http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t...
      - igouy 14y ago
        Thanks, let's hope that holds for the Go #7 program.
- trailfox 14y ago
  The quad core results indicate the exact opposite in terms of performance with the JVM clearly ahead: http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?test=all&lang=go&lang2=java http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t... Go uses less memory than Java 7, but then again so does Java 1.1

voidlogic 14y ago

In addition to the improvements from the improved scheduler, use of accept4 on Linux, better GC and code generation, Brad Fitzpatrick has been giving a lot of love to the "net/http" package. Here is a small example: https://plus.google.com/u/0/115863474911002159675/posts/L3o9hEs8SAe https://plus.google.com/u/0/115863474911002159675/posts/L3o9...