alexyakunin

As for BenchmarkDotNet, I totally agree with you in general - it's the best option available for micro-benchmarks. But if you want to run a benchmark involving a fairly complex interaction, multithreading, etc. (caching benchmark that I used is of this kind - it runs on client + server process, uses SQL Server hosted in Docker, etc.), it's rarely the best fit.

On a positive side, I can assure you I know how to run such benchmarks properly - i.e. things like warmup, explicit GC before / after are just some of the aspects taken into account. If you're curious about some other benchmarks I ran in past, check out https://itnext.io/geting-4x-speedup-with-net-core-3-0-simd-i... and https://github.com/alexyakunin/GCBurn

Hi there, the author of the original post is here. PGO is disabled in .NET 6 by default mainly because of trade-offs associated w/ the startup time - and IMO it's totally reasonable assuming .NET 6 brings decent speed benefits even w/o PGO.

I turned it on mostly to show what you can expect from a service that runs for a while (more than a few minutes?) in a typical server-side scenario after migration to .NET 6 - IMO it's totally reasonable to turn PGO on for nearly any service of this kind.

"Board Games" is a new Fusion + Blazor sample and a fully functional web app allowing you to play real-time multiplayer board games.

Ok, it's real-time, but what's so new there? The implementation cost of real-time updates. Everything you see in this sample required me to write just ~ 35 extra lines of code!

For anyone interested in real-time Blazor apps - I've just published the most "advanced" Fusion sample live: https://fusion-samples.servicetitan.com/

What's interesting there:

- It's a Blazor app that supports _both_ WASM and Blazor Server modes - Authentication sample shows GitHub auth with real-time session tracking. Try signing in there from multiple browser windows and from different browsers - you'll be surprised. - Server Screen page delivers an image stream of ~ 10-20fps / 10 Mbps even on mobile. It's not a real server-screen, of course - the sample is hosted on k8s cluster. Though the pics it sends are generated in real time. It delivers a screencast if you run it on Windows machine. - Chat is just nice to play with, esp. with multiple windows open. It persists everything to a local Sqlite DB, so its state doesn't survive deployments. - And Composition is probably the most interesting part there: it shows how Fusion automatically tracks changes made in completely different parts of this app (Chat, Authentication, Consistency, etc.) and combines them into a single state that's also updated in real time.

P.S. The cluster is tiny (1 core), so please don't turn it into a challenge to crush it - especially via "Server Screen" page, which was made mostly to show what's possible, though was never designed to serve even a hundred of concurrent users on a small machine.

> The OP was dramatically wrong about Go being more verbose than C# when the exact opposite is true.

Sorry, I missed the proof - can you point me to it?

What you presented as "more verbose code" isn't actually a proof - i.e. yes, SIMD code is obviously more verbose than a normal one. And faster.

> Go has support for assembly and supports SIMD intrinsics just fine.

But wait, in this sense any language has support for assembly and SIMD. Bundled assembler is not the same as language-level support for SIMD - and even in https://benchmarksgame-team.pages.debian.net/benchmarksgame/... a large portion of SIMD code is actually cross-platform (what uses Vector<double>), and I am pretty sure sticking to just cross-platform SIMD APIs would be enough to beat Go.

> You wouldn't compare a C# code optimized with SIMD intrinsics with Go code that doesn't use SIMD intrinsics.

You use what's not against the rules, and it's not against the rules on CLBG. You're free to submit your own version of the same benchmark on Go relying on SIMD or whatever you prefer.

> It compares implementation of the benchmark code, not the quality of the compilers on the code that you'll actually write in real life.

Yes, any benchmark is somewhat biased. But honestly, comparing real-life benchmarks is even harder - they involve much more components, so whoever isn't happy with the results can always claim it's a comparison of frameworks, not the actual programs, etc., etc.

Computer Language Benchmark Game already updated their results for .NET / C#: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

As for me, I wrote https://medium.com/servicetitan-engineering/go-vs-c-part-3-c... that compares C# and Go, and conceptually nothing changed a lot from the moment this was written.

IMO Go is the only viable competitor to .NET nowadays. Java is holding there solely because of Android - performance-wise it's so far behind...

And speaking of unsafe code and x86-specific (i.e. non-portable) AVX2 intrinsics:

1. First, unsafe doesn't mean you shouldn't use it on .NET. It just means you need to do more checks manually.

2. A lot of things you can do in Go are unsafe in .NET terms - e.g. even slice is a leaky & unsafe abstraction: https://alexyakunin.medium.com/slice-an-extremely-leaky-abst...

3. Yes, the fact Go doesn't support SIMD intrinsics explains why it loses not only to C#, but also to C++ and Rust on math-intensive tests. But it loses to C# on other tests too - e.g.: - https://benchmarksgame-team.pages.debian.net/benchmarksgame/... - https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

And as you might notice, the code length doesn't differ much there.

Sorry, Go ISN'T faster than .NET at all.

This is the link you should share: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

https://medium.com/servicetitan-engineering/go-vs-c-part-3-c... - check out "Runtime Performance" section here, it shows that geometric mean on exactly this benchmark is heavily in favour to .NET, and it's .NET 3.1, not .NET 5.

Learn how modern web services spend 90% of their resources on computations that should never happen.

What’s the biggest difference between the modern and the future web apps? To answer this question, let’s ask the opposite one first: what’s the most rudimentary UX feature used by almost any web app today? I nominate this button: ...

Yesterday I announced Stl.Fusion — a library allowing anyone to write real-time apps and UIs much faster, but importantly, also quite differently from what most people used to. And this is clearly the biggest point of frustration — long and comprehensive documents like Overview are fine, but we definitely need a really simple explanation. So here it is.

Ended up writing "Stl.Fusion In Simple Terms": https://medium.com/@alexyakunin/stl-fusion-in-simple-terms-6...

Thanks!

Have you ever dreamed to have an abstraction that magically delivers every change made to you server-side data to every client that displays it? Or a caching API that automatically evicts a cached entry right at the moment it becomes inconsistent with the ground truth?

Stl.Fusion solves both these problems — moreover, it does this almost transparently for you, so most of your code won’t even change. Works on .NET and Blazor.

Similar to Knockout & MobX, but thread-safe, asynchronous, immutable, and ready to serve replicas of computed observable instances to remote clients. Works on .NET and Blazor.