For anyone who enjoys Stephen Toub’s deep technical articles like this one as much as I do - he also published another post today on migrating the Copilot coding harness from Node.js to Rust. Another great read.
Too bad there’s such a lingering culture of Windows and creaky Lenovos and Dells around it. I’m sure it can be different, but I’m not taking my chances ever again. Simply not worth my sanity.
That is not my experience. Sure, the background of .NET is windows, but in the last decade or so it opened up to other platforms, and so many shops prefer deploying their .NET based applications to linux for multitude of reasons. Along with this comes linux oriented culture.
So windows culture is not tied to .NET per se, more so tied to certain shops I would say.
Speaking from anecdotal experience, I have no numbers on this :)
Not sure when your last foray into the .NET ecosystem was, but every since it is xplat and unified (.NET 5 probably) it is a real joy. I use VSCode as IDE for C# on my mac, and deploy to Linux.
You don’t need to, but if you ever want to really optimise some code, understanding what it turns into on the target CPU really helps. Especially if you know the implications for any particular instruction (cost of memory access, potential branch prediction misses, etc)
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…
C# takes a lot of different roles. If all you're doing is higher level stuff, say you're only working on a local GUI app where you're waiting on the user 99% of the time, you probably don't need to understand it. But you can also treat C# as more of a low level systems language, maybe you need to optimise some number crunching in a server - and then, as with any systems language, being able to read it may help.
Kinda. I use the `disassemble` function in Common Lisp quite a bit, and I can't work backwards to explain what a function is doing based on the disassembly.
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.
Not really, you only need to know you can get at it. One day you might be doing something like processing images or video and you are finding it slow and getting down to this level can be helpful. But it wouldn't necessarily be the first thing you'd look at.
Assembly is honestly very easy to learn, especially ARM assembly, for the basics (even if whole-program assembly is still difficult). In the worst case, you end up learning something interesting.
Very thorough write up. Clearly a lot of performance improvements across their stack. As if it wasn't detailed/long enough already, I would have loved to see some application-level benchmarks that gave a hint of the cumulative performance gains we should expect.
I noticed that audio quality begins degrading above 100% (at least if the media is already at high volume), so it really is a useful concept. I'm unsure what Linux distro I'm recalling this from, but it was useful on my little old netbook from college
The software has to start clipping the audio above "100%", but I use it regularly in say, VLC, because I might want the volume slightly higher without increasing my whole system volume just to hear a quiet section. I rarely notice any degradation at 150%.
Ah the traditional browser stress test from the .NET team. :)
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.
Flip side: LLMs have to be very explicitly told to code in "modern" .NET and C# due to lack of representation in the training set.
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() { ... }
}
Agents really struggle on this one for some reason.
Even older releases have a few that I notice LLMs making mistakes on like use of `System.Threading.Lock` over `Object` when locking.
Buildings games in Unity feels like magic with frontier reasoning models.
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.
> The sections that follow are full of real improvements. A bounds check removed, an allocation that no longer happens,
Annoyingly the.net blog seems to have started to use LLMs to write their copy. Using "real" twice in one paragraph - do LLMs do that? Lots of commas is a tell for me.
> This is a long one. It’s meant to be. Grab your hot beverage of choice, settle in, and let’s turn it up.
These comments about potential LLM usage are so boring. Stephen is doing this kind of blog post since 6+ years. They all look the same. Read it! It’s very good. Performance deep dives with this kind of quality are rare.
Ok, fair enough. I may have over compensated for this one. I found the Spinal Tap, "this one goes to 11 stuff" so irritating that I might have not thought it through. It's such a tired joke by now. I did enjoy his Frozen reference last year.
I suspect it was done old school: Written by Stephen and passed to a LLM to fill in all those links and other garnish and then passed back for final polish by Stephen. That's how I do my write ups (but generally without the LLM bit for shorter efforts).
This is a long write up, and I'm sure it will have been assisted, but in the right way, and not a sloppy way.
I've dropped several commas before conjunctions, soz!
FWIW the .NET 10 release also had 2 occurrences of "real" in literally the first paragraph.
I, too, tire of the constant YOU WROTE THIS WITH LLMs outrage. An incredible engineer dumped an ENORMOUS amount of technical knowledge at your feet, and you're commenting on the smell? Is that all you have to contribute?
I saw this too on the Ryan Carniato/SolidJS 2.0 announcement post. A world-class engineer makes a great blog post, and all the comments can focus on are the LLM-smells. Oh well. Any reason not to learn, I guess.
This post was so refreshing to read, because it reminds me of a time of solid engineering & writing in a pre-AI era.
I’m afraid posts like this might become fleeting.
looks like a large chunk of this was written by claude though :(
the technical parts are fresh as ever but the writing style is awful, man
casey muratori would like to have a talk with you about the following :))
For anyone who enjoys Stephen Toub’s deep technical articles like this one as much as I do - he also published another post today on migrating the Copilot coding harness from Node.js to Rust. Another great read.
https://github.blog/ai-and-ml/generative-ai/migrating-the-gi...
Runtime async is certainly an interesting development. Really excited to see how this plays out.
these blog posts have really turned me into a dotnet evangelist. love the framework & language.
Too bad there’s such a lingering culture of Windows and creaky Lenovos and Dells around it. I’m sure it can be different, but I’m not taking my chances ever again. Simply not worth my sanity.
That is not my experience. Sure, the background of .NET is windows, but in the last decade or so it opened up to other platforms, and so many shops prefer deploying their .NET based applications to linux for multitude of reasons. Along with this comes linux oriented culture. So windows culture is not tied to .NET per se, more so tied to certain shops I would say. Speaking from anecdotal experience, I have no numbers on this :)
Not sure when your last foray into the .NET ecosystem was, but every since it is xplat and unified (.NET 5 probably) it is a real joy. I use VSCode as IDE for C# on my mac, and deploy to Linux.
[flagged]
Saw a noticeable startup time boost on a recent project migration. Always appreciate the continued focus on speed.
Dumb Q: should a non-systems-language dev know/read assembly?
I know C#/F# decently well, but is there any reason to actually pull out the ol textbooks and learn wtf the above is saying?You don’t need to, but if you ever want to really optimise some code, understanding what it turns into on the target CPU really helps. Especially if you know the implications for any particular instruction (cost of memory access, potential branch prediction misses, etc)
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
C# takes a lot of different roles. If all you're doing is higher level stuff, say you're only working on a local GUI app where you're waiting on the user 99% of the time, you probably don't need to understand it. But you can also treat C# as more of a low level systems language, maybe you need to optimise some number crunching in a server - and then, as with any systems language, being able to read it may help.
All you could tell from this snippet is that .NET 11 eliminated 2 instructions, one of which is a branch.
You should learn assembly anyway, but it won't make this part any more insightful.
Kinda. I use the `disassemble` function in Common Lisp quite a bit, and I can't work backwards to explain what a function is doing based on the disassembly.
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 :-)
Not really, you only need to know you can get at it. One day you might be doing something like processing images or video and you are finding it slow and getting down to this level can be helpful. But it wouldn't necessarily be the first thing you'd look at.
Assembly is honestly very easy to learn, especially ARM assembly, for the basics (even if whole-program assembly is still difficult). In the worst case, you end up learning something interesting.
No. If you're a low-level C language programmer then it is useful.
Always appreciate the continued perf gains. Our existing services just get faster for free, which is a nice win.
I hope there will be some kind of runtime async support for the current or a new asyncmethodbuilder. That is amazing work.
Very thorough write up. Clearly a lot of performance improvements across their stack. As if it wasn't detailed/long enough already, I would have loved to see some application-level benchmarks that gave a hint of the cumulative performance gains we should expect.
Spinal Tap's "put it up to 11". My laptop (Kubuntu) has volume controls that allow me to override 100% and take it to 150%.
I can wind it up to 15! \||/ (is there an official ASCII art four finger devil's horns)
I noticed that audio quality begins degrading above 100% (at least if the media is already at high volume), so it really is a useful concept. I'm unsure what Linux distro I'm recalling this from, but it was useful on my little old netbook from college
The software has to start clipping the audio above "100%", but I use it regularly in say, VLC, because I might want the volume slightly higher without increasing my whole system volume just to hear a quiet section. I rarely notice any degradation at 150%.
\m/
I stared at my keyboard for bloody ages and came up with || instead of m.
nob end!
Ah the traditional browser stress test from the .NET team. :)
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.
Impressive technical work and authorship. My quibble, which seems significant in context, is what happened with AoT?
It still exists, it's still a bit quirky because of the way you need to match CPU to binary (e.g. some opcode extensions only existing on some CPUs)
AoT is still a thing. Presumably a lot of the JIT improvements would also improve the generation of AoT-compiled code.
I hope that’s the case but I’d feel a lot better to see it in print.
Thanks Stephen for this, it is very rewarding to read something very technical that is not AI slop these days.
C#/.NET are very well-represented in LLM data - from enterprise back-end code to games. A language to use for sure.
Flip side: LLMs have to be very explicitly told to code in "modern" .NET and C# due to lack of representation in the training set.
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.
Agents really struggle on this one for some reason.Even older releases have a few that I notice LLMs making mistakes on like use of `System.Threading.Lock` over `Object` when locking.
The dotnet team provides some agent plugins which solve some of these issues. I expect unions in dotnet 11 will need some skill updates too.
With Claude I never had that problem. However Claude does not use the pattern by default
Buildings games in Unity feels like magic with frontier reasoning models.
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.
> The sections that follow are full of real improvements. A bounds check removed, an allocation that no longer happens,
Annoyingly the.net blog seems to have started to use LLMs to write their copy. Using "real" twice in one paragraph - do LLMs do that? Lots of commas is a tell for me.
> This is a long one. It’s meant to be. Grab your hot beverage of choice, settle in, and let’s turn it up.
Ugh.
These comments about potential LLM usage are so boring. Stephen is doing this kind of blog post since 6+ years. They all look the same. Read it! It’s very good. Performance deep dives with this kind of quality are rare.
Ok, fair enough. I may have over compensated for this one. I found the Spinal Tap, "this one goes to 11 stuff" so irritating that I might have not thought it through. It's such a tired joke by now. I did enjoy his Frozen reference last year.
Not too sure here. I use quite a few commas, too.
I suspect it was done old school: Written by Stephen and passed to a LLM to fill in all those links and other garnish and then passed back for final polish by Stephen. That's how I do my write ups (but generally without the LLM bit for shorter efforts).
This is a long write up, and I'm sure it will have been assisted, but in the right way, and not a sloppy way.
I've dropped several commas before conjunctions, soz!
FWIW the .NET 10 release also had 2 occurrences of "real" in literally the first paragraph.
I, too, tire of the constant YOU WROTE THIS WITH LLMs outrage. An incredible engineer dumped an ENORMOUS amount of technical knowledge at your feet, and you're commenting on the smell? Is that all you have to contribute?
I saw this too on the Ryan Carniato/SolidJS 2.0 announcement post. A world-class engineer makes a great blog post, and all the comments can focus on are the LLM-smells. Oh well. Any reason not to learn, I guess.
For some people LLM-spotting feels like a sport they need to compete in
This is the loudest release of .NET to date(!)
It’s a spinal tap joke.
Backing you up on this. I smelled LLM and hit cmd+w.