This is a great community activity. Clearly, the community is more than capable of performance enhancements, based on the improvements they have made in the product.
If people start improving the C# benchmarks, please file an issue on dotnet/core to get feedback and some cred. We may do another blog post on that if there is some gravity around the activity.
From a very quick look, something like http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... looks like a direct port from a C program, rather than idiomatic C#.
> Please don't implement your own custom "arena" or "memory pool" or "free list" - they will not be accepted.
> ...
> We ask that contributed programs not only give the correct result, but also use the same algorithm to calculate that result.
So there might not be too much room to improve. There could be some room to improve for things like "custom ... memory pool" since .NET Core has ArrayPool [2] built-in. But I can't tell if the spirit of that rule is "don't implement pooling" vs. "you can only allocate memory in the standard ways provided by the runtime."
[1] http://benchmarksgame.alioth.debian.org/u64q/binarytrees-des...
[2] https://github.com/dotnet/corefx/blob/master/src/System.Buff...
This.
However in CoreCLR there are multiple efforts to reduce memory consumption, mostly driven by the ports to other architectures (e.g. ARM, ARM32), see https://github.com/dotnet/coreclr/search?q=memory+consumptio...