<p>Expected to find Go platform on top of this list:
<a href="https://www.techempower.com/benchmarks/#section=data-r10&hw=peak&test=db&s=2&l=2lepq" rel="nofollow">https://www.techempower.com/benchmarks/#section=data-r10&hw=peak&test=db&s=2&l=2lepq</a>
Ok, maybe less behind Java. ;)</p>
<p><em>But was surprised</em> that go perfomace is less than Java, Scala, Lua , bottle-Python, Dart and even raw-Php for peak hardware configuration.</p>
<p>How is that possible for "compiled" language I don't know.</p>
<hr/>**评论：**<br/><br/>bertold: <pre><p>That particular benchmark is extremely specific, highly gamed, and consequently somewhat meaningless.</p></pre>TornadoTerran: <pre><p>more details plz</p></pre>jammerlt: <pre><p>Yes, because a language speed is defined by how quick you serialise json. Json requires using reflections to produce it due to it's dynamic types. If you reimplemented JSON marshaller interface yourself (or just returned a string) and did not rely on the stdlib to do the marshalling for you, I am sure it would be at the top. Also, I suggest you find some proper benchmarks before making claims like this.</p></pre>genesem: <pre><p>Good point about json thanks,
but link points to the "single query db access" test.</p></pre>robertmeta: <pre><p>Which generates a random number, queries a db row, converts the data to json and returns it. I suspect the rand.Intn might be a part of the problem, as is an untweeked naive json marshaling. That all said, for the common case (horizontal scalability rather than vertical, ala EC2 -- Go still does solid).</p>
<p>Additionally, you can see Go coming up slower in the JSON rendering department as others get faster -- because the Go version is just using standard "json.NewEncoder(w).Encode(&Message{helloWorldString})" ... which is what you would probably do in real life, because it is highly unlikely that the json will be the bottleneck, but if it becomes the bottleneck in real life, you can optimize it (using like ffjson to get 2x or 3x performance: <a href="https://github.com/pquerna/ffjson" rel="nofollow">https://github.com/pquerna/ffjson</a>).</p>
<p>In short, don't get overly twisted up over unoptimized artificial benchmarks on hardware you don't (and probably won't) use.</p></pre>genesem: <pre><p>Wow, Thank you!</p></pre>elithrar_: <pre><p>I suspect most of the other languages (besides Java, which has the JVM) have C implementations.</p>
<p>Which is therefore Go vs. hand-crafted C.</p></pre>hooluupog: <pre><p>FYI, <a href="https://groups.google.com/forum/#!searchin/golang-nuts/techempower/golang-nuts/W5yOfB_RF8I/E4u8_sFAQNAJ" rel="nofollow">https://groups.google.com/forum/#!searchin/golang-nuts/techempower/golang-nuts/W5yOfB_RF8I/E4u8_sFAQNAJ</a></p></pre>nuunien: <pre><p>The results seem to be quite different between testing environments. Go appears to be closer to the top on the EC2 instances.</p></pre>genesem: <pre><p>yes, but for the top hardware it degrade it's perfomance for some reason. </p></pre>superlampicak: <pre><p>Make sense. JVM is fantastic in utilizing provided performance.</p></pre>funny_falcon: <pre><p>go is not optimized for running single process on many cpu cores. That is why it shines on small core system, and fails on Peak with 24 real cores 48 hiperthreads.</p>
<p>If one runs 24 processes with GOMAXPROCS=2, that Go's result will be much better.</p>
<p>To he fair, leaders on Peak software do mostly the same: lwan runs many fully independent threads, as well as other C and C++ frameworks; openresty works in many nginx worker processes; only Java shows real one process performance with shared state.</p></pre>robertmeta: <pre><p>To be fair, Go probably has room for improvement on high core systems. My current main dev box is a quad-dec (80 cores) and we get "good enough" performance distributed across all the cores. It allows us to do interesting tests at a high iteration rate. </p></pre>funny_falcon: <pre><p>Go certainly can be "fast enough". The conversation is about benchmark, where more "dumb" solutions shine, or super optimized java runtime. This benchmark prefers a lot of independent processes/threads, not single process with shared mutable state and stop-the-world non-generational GC.</p>
<p>If your application needs single process by desing, the you can not have more from Go at the moment. But, as you say, you already have all you need. And possibly Go will improve in future</p>
<p>But if your application could be scaled to several processes on single machine, the you will gain more performance right now.</p></pre>pinpinbo: <pre><p>Fascinating that the results changed quite a lot between 9 and 10.</p>
<p>On 9, using i7 hardware, Go is more or less on top tier. It is no. 1 on JSON category.</p></pre>
