Earlier quoted context omitted.
> It features an atypically high allocation rate compared to real-world programs. Do you have any supporting evidence for this? Real-world programs can be pretty allocation heavy, and if anything high allocation rates would "unfairly" benefit GC languages since native programs are banned from using arena allocators. > As a synthetic micro benchmark that only ever allocates objects of one size, it makes pool allocator…
> Do you have any supporting evidence for this? For starters, by virtue of the construction of the benchmark alone, which mostly is about stress-testing allocation. There are also quite a few papers that benchmark allocators, such as [1], where you can see that such allocation rates aren't exactly ordinary. > Real-world programs can be pretty allocation heavy, I said "atypical", not "impossible". Obviously, I can con…
That's not actually true at all. Games, for example, can have high allocation rates. But they use custom allocators to make those allocations extremely cheap using things like arena allocators for the allocations for a frame.
> My point is that this apples vs. oranges, no matter how you cut it.
It's not apples vs. oranges at all, though. It's "how can you solve this problem in the optimal way on any given language"
The set of rules does not appear to unfairly punish any particular language design. You can do object pools in GC'd languages, too, for example.
Does the problem itself have bias? Probably, but real problems in the real world have inherent language biases, too. That's a problem with reality, not a problem with the benchmark.
> That sentence doesn't make sense, unless you live in a world where C++ is the only programming language (because templates are pretty much C++-specific).
generics? Not C++ specific.
> Simple example: A program alternates between allocating objects of size N (and then freeing most, but not all of them) and allocating objects of size M (and then freeing most, but not all of them). Worst case means that one object per block is enough to keep an entire block alive.
That example results in terrible fragmentation for everyone if M > N other than a compacting GC. It's not made particularly worse by an object pool.
> Importantly, you seem to be mistaking this for a tribal argument (the GC tribe vs. the manual memory management tribe), whereas my point is simply that the benchmark is bad and tries to compare incomparable things.
I'm not mistaking it for that at all. I'm saying your arguments for why it's bad are bad. You seem to be upset that benchmarks for problems exist that do not represent your priorities of what should be benchmarked.