Any cross-language benchmarks are always unfair for those kinds of reasons, because ultimately everything is eventually possible against any given hardware.

What matters more for comparing what you get out of languages is the output of idiomatic code written against typical frameworks.

Indeed, it's still cool to see, even if it's optimised to beyond recognition, as seeing the occasional C# win is nice to keep the "re-write in rust" wolves from the door, who seem to ever lurk, especially in a world where re-writes appear easier.

▲

afdbcreid a day ago | parent [-]

> ultimately everything is eventually possible against any given hardware.

Not everything, no. You can't run C# without the .NET runtime. Some parts of it are irreplaceable.

And the Rust optimizations to shrink binary size (see https://github.com/johnthagen/min-sized-rust) are commonly done in production when it matters, not just in WASM but also in embedded.

▲

memsom a day ago | parent | next [-]

> Not everything, no. You can't run C# without the .NET runtime

You can compile C# to an AOT exe, and when you do that it will literally only be what it needs to work, less and dynamic libs.

	▲	afdbcreid a day ago \| parent [-]
		Indeed, some parts are possible to strip. Some not.

▲

jeswin a day ago | parent | prev | next [-]

> You can't run C# without the .NET runtime

With NativeAOT, same a golang then. NativeAOT has worked wonderfully for us, and in some specific situations faster than Rust.

▲

afdbcreid a day ago | parent [-]

> and in some specific situations faster than Rust

I'm very curious to hear when? Because even the people that argue managed languages can be faster than unmanaged, say it because the JIT has better information at runtime. But NativeAOT cannot be better (and will be worse) than LLVM with PGO.

▲

DannyBee a day ago | parent | next [-]

The last sentence is definitely true in the limit but not always in practice. PGO doesn’t always make good decisions. It should, but it doesn’t. Anyone who has ever used PGO has seen plenty of cases where PGO results in performance regressions versus non-PGO.

some of these are consistent enough that there are workloads where PGO does worse than non-PGO.

they can all be fixed, of course. which is why what you said is true in the limit, but it might not be true for right now

	▲	afdbcreid a day ago \| parent [-]
		You can always not enable PGO of course. What I meant is that I don't expect NativeAOT to do better.

▲

jasomill 17 hours ago | parent | prev [-]

True, but there's no reason PGO can't eventually be implemented for native AOT.

Microsoft already has both dynamic PGO in .NET JIT and traditional PGO in its C++ toolchain, after all.

And for that matter, there's no reason LLVM itself couldn't eventually be a target for native AOT.

	▲	afdbcreid 14 hours ago \| parent [-]
		> True, but there's no reason PGO can't eventually be implemented for native AOT. It already is implemented, I believe. The thing I wondered is how NativeAOT could be faster, which is what GP claimed. (Also, practically it should be slower because NativeAOT is based on the JIT and the JIT is worse at optimizing than LLVM).

▲

zarlo a day ago | parent | prev [-]

[dead]