4 ms·
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
by 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 agoTo 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 agoWell, that's using a particular framework (netty). Play seems much simpler.
- coldtea 14y agoNot 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 agoFirst 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 agoI'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
- ansible 14y agoMemory 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. The difference between 50 MB and 500 MB is that the former is more likely to fit in L3 cache than the latter. Ignore that difference at your peril.
- voidlogic 14y ago>>Memory consumption is often not a major concern on modern systems, saving 50 MB or even 500 MB Tell that to the folks that have to pay for cloud or VPS servers... Also, less memory usage means higher CPU cache hit rates and fewer page faults.
- Ziomislaw 14y agowhat do you mean by expressive? are you _really_ sure it is not just your bias that is preventing you from "expressing" what you want? ie. you want to write python/java in Go?
- trailfox 14y agoGo typically requires 2-4 times less code to do the same thing: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=go&lang2=python3 http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...
- igouy 14y agoNot 2-4 times less than those Python programs (less would be shown as a fraction), but 2-4x more.
- cmccabe 14y agoMemory 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. That's what the original designers of Java thought too. It turns out that this thinking is wrong, though. Main memory may be big, but CPU caches are still small. For example, the laptop I am typing this on has 64 kilobytes of L1 cache, 256 kilobytes of L2 cache, and 3072 kilobytes of L3 cache. That is not a lot. Turns out, when you're spending all your time waiting for main memory, you are not "processing more requests per second." Main memory is at least two orders of magnitude slower than CPU cache.