[weberc2]

That benchmarks game quote supports my point (not sure if you quoted it to contradict me or not?). As for prohibited optimizations, arena allocation is the one that comes to mind since it’s the standard way to avoid O(n) allocs.

[igouy]

> That benchmarks game quote supports my point…

As-long-as your point was not intended to be dismissive in any way.

> prohibited optimizations

Go programs are not prohibited from using arena allocation provided by a generally available library — that is what the C++ programs do.

Unfortunately there doesn't seem to be a generally available Go library that provides arena allocation. Of course, Go does provide GC.

[weberc2]

It is dismissive of the idea that the game can tell you meaningful things about a programming language’s average or percentile performance or even its peak performance.

> Go programs are not prohibited...

Right, and this is why the Go benchmarks for allocations aren’t very meaningful. Using arenas (or other kinds of preallocation) is a common optimization in Go even if Go doesn’t have a library for it.

I’m sure you’re well aware of all of this since you evidently contributed to these benchmarks, but for other readers, here’s a good thread about why these benchmarks aren’t meaningful.

[igouy]

Where did you get the idea that 10 tiny tiny programs could tell you about a programming language’s average performance?

Who in this discussion has made any such a claim?

You repeatedly put up a straw man.

[weberc2]

Im not sure why you’re confused. ilovecaching made claims about the relative performance of programming languages based on the benchmark game.

[igouy]

ilovecaching responded to your claim that — [Go's] performance is closer to Java — by posting links to pages on the benchmarks game website.

ilovecaching pointed to the performance of specific Go and Java programs

Now you have put up a straw man — "a programming language’s average or percentile performance or even its peak performance."