7 ms·

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

by 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.
      - voidlogic 14y ago
        First off, is was 14k vs 38k. Just wait until next benchmark update when they have switched to Go 1.1 Based on these results Go and Netty should be much closer: https://gist.github.com/errnoh/5320784 https://gist.github.com/errnoh/5320784
- errnoh 14y ago
  I'll skip most of the Java vs Go discussion but as you're probably aware that was Go 1.0.3 running on that benchmark. Here's Go 1.1 vs 1.0.3 on a bit beefier machine: https://gist.github.com/errnoh/5320784 https://gist.github.com/errnoh/5320784 Next benchmark will have Go 1.1 running, can't promise that it'll scale as well as on this server but it'll be significant change anyways. And most of all, main part of the language is that it's intuitive to write and comes with a clear and readable spec and standard library. edit: updated gist with Netty using the same configuration
batgaijin 14y ago
Tell me when go can compete with this: https://sites.google.com/site/piotrwendykier/software/parallelcolt https://sites.google.com/site/piotrwendykier/software/parall...
coldtea 14y ago
>Slower than Java at what? At program startup time? Java is a joke in this area. No. In actual performance for most cases of algorithmic code. http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=java&lang2=go http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... Java is 2-6 times faster and uses more memory for slightly more code. I'm willing to trade. Yes, "those are not real world programs etc". In general the shootout gives a quite realistic results (not to mention that anybody who thinks he can do better can go code his own solution). Programs are programs. In my own tests with larger programs Go has been 1/2 the time of Python and slower than Java too. If you're not IO bound, those things matter. If you are IO bound, you could as well run Python, since you aren't missing much. Startup time doesn't matter at all except if you do scripting or old-style CGI. Java (and Go for that matter) target long running network servers and such. >Go also gives you more control over how your program uses memory. On the other hand Java gives most control to the JVM, which is smarter than most programmer's fine tuning and knows a whole lot more about the code's runtime behavior.
- enneff 14y ago
  > Programs are programs The programs in the shootout are nothing like the programs people typically run and write. For instance, most of the programs I write do a lot of I/O. The shootout programs do none. > Startup time doesn't matter at all It certainly does in cluster environments where you regularly spin up new server instances. It's also important for command-line tools.
  - coldtea 14y ago
    >The programs in the shootout are nothing like the programs people typically run and write. For instance, most of the programs I write do a lot of I/O. The shootout programs do none. Which is as well, because you only want to benchmark for CPU bound parts of the program. IO is the same speed for all languages, so it cancels out. >It certainly does in cluster environments where you regularly spin up new server instances. Not really a common use case. >It's also important for command-line tools. I don't think command-line-tools are Go's or Java's niche.
pjmlp 14y ago
> At program startup time? Java is a joke in this area. It is always a matter if you are using a JVM (from which vendor) or compiling to native code. Language != Implementation
- enneff 14y ago
  > Language != Implementation Ideally, yes. But in practice a language and its implementation (whichever one you choose) is a tool. If you're comparing tools, you've got to compare a language with its implementation.
  - pjmlp 14y ago
    So what you compare when a language happens to have multiple implementations? Which from 6g, gogcc, go express you pick for Go? Which from OpenJDK, Oracle JVM, IBM J9, gcj, RoboVM, Aonix Perc ... you pick for Java? Which from Sun Forte, IBM xlc, hpcc, gcc, clang, CINT, Visual C++, ... you pick for C or C++? Which from CPython, IronPython, PyPy, JPython, ... you pick for Python?
    - enneff 14y ago
      It depends what you're trying to compare.
      - pjmlp 14y ago
        It is always up to the present to use the evidence that better fulfills its goals in the eyes of others.
    - coldtea 14y ago
      That's easy. Except for C++, which is a multi-vendor language. For all others there is a definitive, used in the overwhelming majority of cases, implementation: Go: 6g Java: Oracle JVM Python: CPython Ruby: Matz's Haskell: GHC ...
      - 14y ago

by cmccabe 14y ago

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.
    - voidlogic 14y ago
      First off, is was 14k vs 38k. Just wait until next benchmark update when they have switched to Go 1.1 Based on these results Go and Netty should be much closer: https://gist.github.com/errnoh/5320784 https://gist.github.com/errnoh/5320784
errnoh 14y ago
I'll skip most of the Java vs Go discussion but as you're probably aware that was Go 1.0.3 running on that benchmark. Here's Go 1.1 vs 1.0.3 on a bit beefier machine: https://gist.github.com/errnoh/5320784 https://gist.github.com/errnoh/5320784 Next benchmark will have Go 1.1 running, can't promise that it'll scale as well as on this server but it'll be significant change anyways. And most of all, main part of the language is that it's intuitive to write and comes with a clear and readable spec and standard library. edit: updated gist with Netty using the same configuration

batgaijin 14y ago

Tell me when go can compete with this: https://sites.google.com/site/piotrwendykier/software/parallelcolt https://sites.google.com/site/piotrwendykier/software/parall...

coldtea 14y ago

>Slower than Java at what? At program startup time? Java is a joke in this area. No. In actual performance for most cases of algorithmic code. http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=java&lang2=go http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... Java is 2-6 times faster and uses more memory for slightly more code. I'm willing to trade. Yes, "those are not real world programs etc". In general the shootout gives a quite realistic results (not to mention that anybody who thinks he can do better can go code his own solution). Programs are programs. In my own tests with larger programs Go has been 1/2 the time of Python and slower than Java too. If you're not IO bound, those things matter. If you are IO bound, you could as well run Python, since you aren't missing much. Startup time doesn't matter at all except if you do scripting or old-style CGI. Java (and Go for that matter) target long running network servers and such. >Go also gives you more control over how your program uses memory. On the other hand Java gives most control to the JVM, which is smarter than most programmer's fine tuning and knows a whole lot more about the code's runtime behavior.

enneff 14y ago
> Programs are programs The programs in the shootout are nothing like the programs people typically run and write. For instance, most of the programs I write do a lot of I/O. The shootout programs do none. > Startup time doesn't matter at all It certainly does in cluster environments where you regularly spin up new server instances. It's also important for command-line tools.
- coldtea 14y ago
  >The programs in the shootout are nothing like the programs people typically run and write. For instance, most of the programs I write do a lot of I/O. The shootout programs do none. Which is as well, because you only want to benchmark for CPU bound parts of the program. IO is the same speed for all languages, so it cancels out. >It certainly does in cluster environments where you regularly spin up new server instances. Not really a common use case. >It's also important for command-line tools. I don't think command-line-tools are Go's or Java's niche.

pjmlp 14y ago

> At program startup time? Java is a joke in this area. It is always a matter if you are using a JVM (from which vendor) or compiling to native code. Language != Implementation

enneff 14y ago
> Language != Implementation Ideally, yes. But in practice a language and its implementation (whichever one you choose) is a tool. If you're comparing tools, you've got to compare a language with its implementation.
- pjmlp 14y ago
  So what you compare when a language happens to have multiple implementations? Which from 6g, gogcc, go express you pick for Go? Which from OpenJDK, Oracle JVM, IBM J9, gcj, RoboVM, Aonix Perc ... you pick for Java? Which from Sun Forte, IBM xlc, hpcc, gcc, clang, CINT, Visual C++, ... you pick for C or C++? Which from CPython, IronPython, PyPy, JPython, ... you pick for Python?
  - enneff 14y ago
    It depends what you're trying to compare.
    - pjmlp 14y ago
      It is always up to the present to use the evidence that better fulfills its goals in the eyes of others.
  - coldtea 14y ago
    That's easy. Except for C++, which is a multi-vendor language. For all others there is a definitive, used in the overwhelming majority of cases, implementation: Go: 6g Java: Oracle JVM Python: CPython Ruby: Matz's Haskell: GHC ...
    - 14y ago