Performance Improvements in .NET 11(devblogs.microsoft.com) |
Performance Improvements in .NET 11(devblogs.microsoft.com) |
I’m afraid posts like this might become fleeting.
the technical parts are fresh as ever but the writing style is awful, man
I loathe LLM prose, no matter who posts it. It earns a quick cmd+w.
My prizes for spending the internet points to say this are the joy of resisting normalization of illiteracy and a tacit camaraderie with the hundreds of others who agree but won't comment or upvote.
https://github.blog/ai-and-ml/generative-ai/migrating-the-gi...
The only time I've been forced into a "culture of Windows and creaky Lenovos and Dells" recently was on a Java project. (Anecdotally, of course. Java has a similarly cross-platform culture as a whole.)
Just today I created e.g. 100 changes in a file, performed an undo and it rolled back 90 or so of the changes while somehow managing to keep the 5 at the start and the 5 at the end.
; Arm64
--- .NET 10
+++ .NET 11
@@ -13,8 +13,6 @@
ble G_M000_IG04
G_M000_IG03:
- cmp w1, w2
- bhs G_M000_IG05
str wzr, [x0, w1, UXTW #2]
G_M000_IG04:
@@ -25,4 +23,4 @@
bl CORINFO_HELP_RNGCHKFAIL
brk #0
-; Total bytes of code 68
+; Total bytes of code 60
Unless it's a runtime-only optimization, like guarded devirtualization... there's no straightforward way for an AOT compiler to do that without profiling data.
https://isdotnetopen.com/ has a good list of "dramas" questioning if .NET is truly open. At least there are not many new dramas from Microsoft...
For me it's not that big of a deal that some parts are not open. At least we have good competition (Microsoft (Visual Studio, VsCode c# Dev Kit) vs Jetbrais (Rider, VsCode + recent "Resharper for VsCode" extension.) that prevents one party to mess up something big.
Still I take debugger in Visual studio or Rider any day instead of VSCode debugger.
Joke aside, yet another interesting read of all little improvements that go across all the runtime, and very much appreciated that they put out the effort to go through this detail level.
// Approximately what the JIT generates
if (animal?.GetType() == typeof(Dog))
{
((Dog)animal).Speak(); // devirtualized, inlinable
}
else
{
animal.Speak(); // original virtual call, hopefully rare
} void speak_generic(void* animal, int type_id) {
if (type_id == DOG) {
dog_speak((Dog*)animal);
} else {
dispatch_speak_vtable(animal);
}
}
Advantage 2: You still get the flexibility of the vtable if you need it (for the case the type is chosen at runtime at not known). But for 90% of cases, its just as fast as the ugly C code.
Disadvantage 1: Losing a smug sense of superiority because you eschew abstractions and prefer writing verbose error-prone switch statements over clean easy to understand code.
Disadvantage 2: Writing performant code can no longer be gate kept behind archaic practices, now everyone can just use `var animal = new Dog()` and be done with it.
Case in point: extension members from C# 14 is one that LLMs commonly stumble on and requires an explicit example. It still sometimes says that this is not valid syntax.
extension(SomeType instance)
{
public OtherType DoSomething() { ... }
}
Even older releases have a few that I notice LLMs making mistakes on like use of `System.Threading.Lock` over `Object` when locking.
Assuming you are competent with scene work and the various art pipelines, the rest of the problem is significantly easier now.
I've been using the Unity CLI to run arbitrary C# code against Unity 6 scenes without requiring domain reloads. It uses Roslyn to compile the snippet in a special Unity editor component instead of running the normal compilation pipeline.
The implications for a reasoning model are significant. Domain reloads in my projects can take 10-20 seconds. Compound across 5-10 tool calls and the difference adds up very quickly.
I'd be interested in hearing more.
I can wind it up to 15! \||/ (is there an official ASCII art four finger devil's horns)
Here is the "Runtime async" section: https://devblogs.microsoft.com/dotnet/performance-improvemen...
I'm not sure if this will surface as an "enabled by default" feature in .NET 11 - indeed there may not be a final decision on that yet. But it is an active area of work that will arrive sooner or later.
My reading was like this:
- "how much things they postpone to put into v11 ?"
- "moving to stack is faster then heap"
- so.. why they just not use multiple stacks ?? ring buffers are just progressive stack but plain stack is just pointer moving... Hmm, but what is usecase except recursive function calling ?
- ok, I read that articele
- what ? it's just a first part ??
- async thingies
- "state machines looks like that"
- aha, always wanted to konw that, thank you Microsoft! Wait, what?? What I just said ?? That really happened?
- scroll, then scroll more some asm code, maybe I read it later
- something interesting, don't remeber now
- next morning coffee time: O, I have some more to read, maybe I can learn something more ?
- ok, work time but probably will finish reading later today
So it is realy nice article. I learned how to do old-school async wrappers in plain C :)
The three* letter mnemonics are usually pretty easy to decode, even if you don’t know the architecture: anything beginning with ‘B’ will be branch, so ‘ble’ is branch if less than or equal. L and S based mnemonics are unusually Load and Store from and to memory. After that it’s understanding the stack and registers and you’re pretty much good to go.
Everything in assembly is loading something from memory into registers doing something basic with those registers, like add/divide/etc and then putting the result back into memory or using the result to make a decision to jump to processing instructions from another place in memory.
Most devs won’t ever need to know this stuff, but as someone who grew up with computers that could barely do anything without grinding to a halt (8bit computer, 2mhz processor, 32kb of RAM, 20kb of which is for the screen), knowing this stuff was essential; however I still find this stuff useful today, even with my C# work.
I am a bit of a performance tuning nerd though, so…
[*] or more
Usually. BRK is a breakpoint.
BUT what I can do is see which functions are being inlined, which values are in memory versus in registers, see if things are being boxed and unboxed a lot, see if SIMD is being used, etc.
And more importantly I can compare two versions of a function to see which one looks better by those criteria. It's not perfect, but IME it works really well for guiding optimization.
I should add that I read the book "Assembly Language: step-by-step" by Jeff Duntemann, and wrote a Tic-Tac-Toe game in assembly ages ago, so that helps a bit to understand the syntax.
(And technically that's a patch file :-)
That is very handy, especially when writing macros. I only have to look at assembly when I want to know about optimizations that are not visible in the source->source optimizer.
If I ever want to know if something is reified (which I never do) I can always look at the ASM.
You should learn assembly anyway, but it won't make this part any more insightful.
Because at this point I would do anything if I could get Github Copilot to understand the new language features and stop trying to constantly revert code.
The one specific thing I'm constantly having to deny is Copilot seeing this:
List<string> items = [];
List<string> items = new List<string>();(Also, other architectures might use J for 'Jump' rather than 'Branch'). I don't make the rules ;)
"Everything" expects you to use MSSQL, even if today there's ok official support for PostgreSQL and SQLite. Most "thought leaders" of various sorts are on Windows and expect you to use it. This pervades throughout the ecosystem.
Can't see this ever changing as it's not in MS' interest to turn other operating systems into good .NET development platforms.
These days I just use EF with Sqlite on 99% of my projects.
I'd say Microsoft's revenue related push with .NET these days is to try to subtly nudge you into Azure (where MSSQL is rare and Windows is virtually non-existent). But, I also think they know they will kill .NET if they go overboard with it as the competition is strong.
SQL Server is the flagship database project on the Microsoft side and that team surely has some imperative to facilitate the EF vision. It simply must be less of a priority for the PostgreSQL and SQLite maintainers to do so. Is that really a valid dig on the .net ecosystem, though?
The navigation system in EF is where all of the pain points originate. All of my troubles with getting the migration generator to work are because I'm trying to express rather complex relationships. For example, to store a record representing a property on an object, I need to have two foreign keys from the Properties table to the Types table: one for the type of the property and one for the type in which the property lives. Types themselves have many relationships to other types: their base type, interface types they implement, generic type parameters, constraints on generic type parameters (actually, haven't even implemented that one as is too much).
I'm generally happy with the performance and expressivity of the system I've developed so far, but damn, it came with a lot of pain.