<h3>github url:</h3>
<p><a href="https://github.com/victorldb/binary-trees" rel="nofollow">https://github.com/victorldb/binary-trees</a></p>
<h3>report:</h3>
<p>stretch tree of depth 22 check: 8388607<br/>
2097152 trees of depth 4 check: 65011712<br/>
524288 trees of depth 6 check: 66584576<br/>
131072 trees of depth 8 check: 66977792<br/>
32768 trees of depth 10 check: 67076096<br/>
8192 trees of depth 12 check: 67100672<br/>
2048 trees of depth 14 check: 67106816<br/>
512 trees of depth 16 check: 67108352<br/>
128 trees of depth 18 check: 67108736<br/>
32 trees of depth 20 check: 67108832<br/>
long lived tree of depth 21 check: 4194303<br/>
6.150191126s </p>
<hr/>**评论：**<br/><br/>: <pre><p>[deleted]</p></pre>TheMerovius: <pre><p>It also does <a href="https://github.com/victorldb/binary-trees/blob/a11aa061bb0b937f6091b8672b9b66a1ea3e5d7b/main.go#L86" rel="nofollow">arena allocation</a>, which is <a href="http://benchmarksgame.alioth.debian.org/u64q/binarytrees-description.html#binarytrees" rel="nofollow">explicitly forbidden</a>.</p>
<p>And it does a bunch of unsafe-magic, though I don't understand why, it shouldn't have any advantages.</p>
<p>Basically, the point of benchmarksgame (if any) is to compare programming languages and the point of this benchmark is to compare GC implementations. Circumventing the GC or doing things wholly unnatural to the language is, of course, subverting the goal of the game.</p></pre>dcuadrado: <pre><p>well the Rust implementation even uses a type called "Arena" and the C implementation has a memory pool, the best C++ version also allocates the whole result in one call and has a memory pool as well, is that allowed? The JVM takes all your memory by default so it's probably not even collecting the garbage. Very unfair game I'd say.</p></pre>jerf: <pre><blockquote>
<p>Very unfair game I'd say.</p>
</blockquote>
<p>If you sit down and try, you will find it is impossible to write "fair" rules that everyone will agree is fair.</p>
<p>There have to be <em>some</em> sort of restrictions, otherwise everyone just ends up writing the solution in assembler and wrapping whatever minimum shim is necessary around the assembler to be "in" the target language.</p>
<p>That said, I find that for all the people who'd like to believe otherwise, the numbers I see coming out of the current benchmark game tend to fairly accurately reflect my own personal experiences with the various languages in question, so I think the current rule set is probably pretty decent.</p></pre>TheMerovius: <pre><blockquote>
<p>is that allowed?</p>
</blockquote>
<p>I don't know, I don't run the game. From a pure rules perspective: They <em>do</em> allow to use a library for custom allocators; but not writing “your own custom "arena" or "memory pool" or "free list"”, which the Go code in question does: It knows a priori how much memory it needs and allocates exactly that upfront. Use of <code>sync.Pool</code>, for example, would probably be fine (but probably won't help).</p>
<blockquote>
<p>The JVM takes all your memory by default so it's probably not even collecting the garbage.</p>
</blockquote>
<p>Meaning that, in this particular benchmark, the JVM has a leg up. So?</p>
<blockquote>
<p>Very unfair game I'd say.</p>
</blockquote>
<p>Only if you give it more meaning than it should have. It's just a way to say "under these specific conditions, these languages compare like this". It's pretty much a neutral statement. The intellectual honest thing is to accept that in this particular benchmark Go just might not compare well to some other languages. That doesn't mean Go isn't a great language or worse than others. It just means that if these are the conditions you are looking for, Go might not be the right tool.</p></pre>: <pre><p>[deleted]</p></pre>epiris: <pre><p>The rules against custom arena should forbid the usage of <a href="https://benchmarksgame.alioth.debian.org/u64q/program.php?test=binarytrees&lang=gcc&id=3" rel="nofollow">APR</a> in the C++ program and pretty much every other one aside from maybe RUST since it is a part of the standard library in my opinion. The <a href="https://benchmarksgame.alioth.debian.org/u64q/program.php?test=binarytrees&lang=gpp&id=2" rel="nofollow">C++</a> (36 seconds) program is the first one without an arena and that fairly compares to the <a href="https://benchmarksgame.alioth.debian.org/u64q/program.php?test=binarytrees&lang=go&id=4" rel="nofollow">Go</a> program (34 seconds).</p>
<p>If op wanted to he could simply make an external package that implements the exact same thing as APR to circumvent the rule. Import "github.com/user/unsafepool" is no different than #include <apr_pools.h>. Regardless the games themselves measure the last thing most people value in software engineering, python is sitting at 90 seconds but it does't stop people from using it effectively in resilient production systems. I'll take 90 seconds of python over <a href="https://www.reddit.com/r/golang/comments/70rm8t/is_golang_at_all_useful_for_writing_packages_for/dn5ibjh/" rel="nofollow">the unbearable C/C++ ecosystem</a> and the endless security nightmare it brings with it.</p>
<p>Edit: if the Rust package is a crate I take that statement back as well. Either all languages that have the ability to implement an arena should be allowed to, or they all should not. It is literally the most advantageous portion of the benchmark for every language that doesn't run within a vm and the only reason Go is so far behind on this benchmark.</p></pre>igouy: <pre><blockquote>
<p>The C++ (36 seconds) program is the first one without an arena and that fairly compares to the Go program (34 seconds).</p>
</blockquote>
<p>Presumably someone could implement a C++ program that did not use a pool but did use multi-core, like that Go program -- something like <a href="http://benchmarksgame.alioth.debian.org/u64q/program.php?test=binarytrees&lang=gcc&id=5" rel="nofollow">C gcc #5 program</a> (19.05 secs).</p></pre>: <pre><p>[deleted]</p></pre>epiris: <pre><blockquote>
<p>There is no arena in the Erlang implementation (4.95 seconds) or the C# implementation (8.26 seconds).</p>
</blockquote>
<p>They are faster due to the same thing thing, since they are using vms they are aggressively allocating large..... "pools of memory". Strace either one of them and I am certain you will see an initial batch of larger mmaps or brk's. Since they are running with in vms you will also notice far less (as in a hundred thousand or so) syscalls for synchronization than a Go program. Is there a point to the statement though, I don't recall mentioning either one of those things due to the reason above.</p>
<blockquote>
<p>Also, APR itself is not a custom-tailored arena implementation made for the purpose of defeating this benchmark. It is a well-established arena library for general purpose usage.</p>
</blockquote>
<p>Sure and I could write the exact same library for Go, nothing about the language prevents someone from doing so. I can easily allocate blocks of memory outside the knowledge of the garbage collector in 50~ or so lines of code and suddenly make([]Node, ..) becomes multiple calls to Get(unsafe..) but to the same affect- tens of thousands of less system calls to facilitate the aggressive collection of garbage that is well suited for real world programs. Which is why I disagree with the rule, this arbitrary restriction imposes showing how you can write efficient programs arbitrarily, favoring C/C++ which can use arenas because "it's standard to do so" and VMS which aggressively front load pools of memory and do not immediately release newly allocated memory back to the system. I imagine with GOGC=off even the rather inefficient implementation that takes 34 seconds would run in at least the same amount of time as the C#, even if the to the tune of a couple gb of ram.</p>
<blockquote>
<p>EDIT: and furthermore, that C++ one that you cherry-picked is only using a single core. So, it takes about the same amount of time, but it uses one-fourth of the CPU to do it... so, not exactly the most compelling argument.</p>
</blockquote>
<p>Would you care to link me a C++ one that does not use a pool that is faster (hint there isn't one). We could exchange nits about what we find fair to measure all day, but at the end of the day I find the benchmarks more or less pointless as I already said so it's not really worth debating over. We can agree to disagree, most software should no longer be written in C or C++ that is my stance and it can't be changed.</p></pre>victor_ldb: <pre><p>Use recursion instead of recursion, use pointer conversion instead of object to create directly.</p></pre>TheMerovius: <pre><blockquote>
<p>As a practical matter, the myriad ways to tune GC will not be accepted.</p>
</blockquote>
<p>The code tunes GC. So this alone would probably count as legit a rejection reason.</p></pre>stuartcarnie: <pre><p>Swift used Apache apr. I would argue that is unnatural in Swift, however it has been allowed. Go ahead and create a binding to that and see how Go performs.</p></pre>
