Properly unmanaged code will probably always be faster than managed code. But the point still stands. Code in a managed language, identify the hot spots and inject highly performant unmanaged code there. There is no need to go full C++ for 99.999% of all projects.

Like this?

http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...

How should /unsafe be set with .Net CORE csproj ?

I only knew the command line option which no longer worked. Once I found the project.json

    "buildOptions": {
        "allowUnsafe": true
    }

I was able to fake something for dotnet migrate and find the needed setting:

    <Project Sdk="Microsoft.NET.Sdk">
        <PropertyGroup>
            <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
        </PropertyGroup>
    </Project>

> nobody who writes C# managed to produce a benchmark yet that beats a C++ program

No, but I've seen Haskell programs that were much faster than the C++ program they replaced, which is what matters in the real world.

Microbenchmarks measure what happens if you have the time to polish every single line to perfection. If you have infinite developer time then C++ will be faster than most languages. But infinite developer time is a negligible use case.

Did the Haskell programs implement the same algorithm?

It implemented the same business requirements. I don't know or care what algorithm was involved (indeed I wouldn't really say there was one).

"Will your toy benchmark program be faster if you write it in a different programming language? It depends how you write it!" :-)

It's worth pointing out that the majority of large C++ projects contain non-deterministic memory management (reference counting) and cache-inefficient object structures like C#.

Absolutely. But note that if you don't have cycles, reference counting of SOME objects is faster than having a GC for everything. The RAII idiom when used in C++ helps with statically determining that some objects can be released at defined points without having to reference count them.

If they were properly written, I'd accept that, but just take a look at how vastly different things these two are doing:

http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...

Nobody stops you from submitting a different version that's faster.

Isn't that the usual explanation for why some program is faster than some other program? They do things differently.