<p>Hi, I was checking some benchmarks for Golang. Its performance is similar to java(somewhat faster) in all but binary tree benchmarks. Binary tree is 4x slower than Java(and 8x vs C++).
Is there any specific design spec causing it?</p>
<p><a href="http://benchmarksgame.alioth.debian.org/u64q/go.html">link</a></p>
<hr/>**评论：**<br/><br/>egonelbre: <pre><p>That benchmark pretty much benchmarks the effectiveness of GC under heavy allocations. Fastest implementations use a "non-standard allocator" or alternatively they tweak the GC for this particular purpose.</p>
<p>Using go tip makes it 1.5x faster, setting GOGC=800 makes it 1.5x faster. Combining both gives ~2.3x improvement. <em>Note: measurements on a windows machine.</em> Using some non-standard allocator could make it even faster.</p></pre>giovannibajo: <pre><p>Yeah, adding <code>debug.SetGCPercent(800)</code> at the top of the main gives a speed boost. In fact, I always do that for gc-heavy applications where the total memory usage is not a concern. I think somebody might want to submit it as an improved version.</p></pre>igouy: <pre><p><em>"As a practical matter, the <a href="http://benchmarksgame.alioth.debian.org/u64q/binarytrees-description.html#binarytrees" rel="nofollow">myriad ways</a> to tune GC will be ignored."</em></p>
<p>There are one or two ways to tune JVM GC also ;-)</p></pre>giovannibajo: <pre><p>Oh I understand. Then I reckon that the benchmark is not fair and gives an unfair advantage to C and C++.</p></pre>igouy: <pre><p>C and C++ programmers reckon it's <em>not fair</em> that their custom allocators are not allowed.</p>
<hr/>
<p><strong>What does "not fair" mean? (A fable)</strong></p>
<p>They raced up, and down, and around and around and around, and forwards and backwards and sideways and upside-down.</p>
<p>Cheetah's friends said <strong>"it's not fair"</strong> - everyone knows Cheetah is the fastest creature but the races are too long and Cheetah gets tired!</p>
<p>Falcon's friends said <strong>"it's not fair"</strong> - everyone knows Falcon is the fastest creature but Falcon doesn't walk very well, he soars across the sky!</p>
<p>Horse's friends said <strong>"it's not fair"</strong> - everyone knows Horse is the fastest creature but this is only a yearling, you must stop the races until a stallion takes part!</p>
<p>Man's friends said <strong>"it's not fair"</strong> - everyone knows that in the "real world" Man would use a motorbike, you must wait until Man has fueled and warmed up the engine!</p>
<p>Snail's friends said <strong>"it's not fair"</strong> - everyone knows that a creature should leave a slime trail, all those other creatures are cheating!</p>
<p>Dalmatian's tail was banging on the ground. Dalmatian panted and between breaths said "Look at that beautiful mountain, let's race to the top!"</p></pre>SupersonicSpitfire: <pre><p>You must become one with the custom memory allocator. Be the mountain! Run like the wind, beautiful Dalmatian!</p></pre>funny_falcon: <pre><p>Java has more performant Garbage Collector.</p>
<p>While Go has more abilities to avoid making allocations/garbage, Java's allocator/collector is cheaper/more performant.</p>
<p>I'm sure, that this example could be rewritten, using non-idiomatic allocation, and then it will match Java perfornance.</p>
<p>C++ uses costom allocator (<code>object_pool</code>) . It is a bit unfair, but on the other hand, it is common practice in C/C++ (more or less)</p></pre>Zilog8: <pre><p>I think also it might be because the Go GC is geared towards low latency moreso than high throughput.</p></pre>egonelbre: <pre><p>Note there is a slight difference between a "custom allocator" and a "non-standard allocator". That benchmark disallows "custom", as in specifically designed for that benchmark, allocator. However it is fine to use a non-standard allocator that can be used in other places.</p></pre>reddit1461: <pre><p>I can confirm that</p></pre>hooluupog: <pre><p>Go 1.5 binary tree benchmark was somewhat slower than java but became 4x slower than Java in 1.6. Maybe it's a regression.</p></pre>igouy: <pre><p>These <a href="http://benchmarksgame.alioth.debian.org/u64q/measurements.php?lang=go" rel="nofollow">same Go programs</a> seem faster with Go 1.6 than Go 1.5</p>
<pre><code>revision 1.364, Wed Aug 19 21:10:21 2015 UTC
=>
revision 1.491, Sun May 8 23:15:32 2016 UTC
binarytrees #1
cpu 175.908 => 170.780
elapsed 94.746 => 94.943
binarytrees #2
cpu 214.592 => 185.020
elapsed 62.155 => 47.714
binarytrees #4
cpu 209.908 => 187.744
elapsed 60.204 => 48.569
binarytrees #5
cpu 184.240 => 188.332
elapsed 59.782 => 50.053
binarytrees #7
cpu 184.408 => 175.648
elapsed 97.377 => 95.645
binarytrees #9
cpu 172.092 => 162.580
elapsed 92.604 => 91.899
</code></pre></pre>igouy: <pre><p><em>iirc</em> there were a couple of Go binarytrees programs that allocated all the memory at once -- eventually someone noticed and those Go programs were rejected.</p></pre>
