> 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" And for any synthetic microbenchma

> 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" And for any synthetic microbenchmark, that's unlikely to reflect real-world workloads, as they tend to narrowly test just one aspect of the language (or rather, its implementation). Remember, we're talking about a peer-reviewed paper here, where the burden to show relevance is upon the authors. Section 4 ("Threats to Validity") of the paper does not really address that adequately. As the Computer Language Benchmark Game site itself quotes (and one reason why it calls itself a "game" and disavows usefulness for actual programming language comparisons): Attempts at running programs that are much simpler than a real application have led to performance pitfalls. Examples include: ... * Toy programs, which are 100-line programs from beginning programming assignments ... * Synthetic benchmarks, which are small, fake programs invented to try to match the profile and behavior of real applications ... All three are discredited today, usually because the compiler writer and architect can conspire to make the computer appear faster on these stand-in programs than on real applications. You can construct pretty much arbitrary rules that will arbitrarily favor certain implementations over others. For example, the rules could also say to only use the language's built-in allocation mechanism for this benchmark. Or you could construct a benchmark that would heavily favor languages with built-in JIT techniques. > You can do object pools in GC'd languages, too, for example. No. The rules do not allow for that. I did mention how arbitrary they are, right? The regex-redux benchmark, for example, comes down to what the best external library is that you can link to under the rules. The gcc version wins in large part (being massively better than the g++ version, which relies on Boost regexes) because it uses the JIT version of libpcre. It's borderline absurd. > generics? Not C++ specific. You said templates, not generics. Generics alone are not necessarily sufficient to implement pool allocators. Plus, C++ is the only language that has major adoption that has both some form of generics and manual memory management. > 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. This is false. Even a simple first-fit allocator can fare better, for example. Obviously, a compacting GC can avoid external fragmentation (almost) entirely, no matter the cause.