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

Yes. Every professional programmer should be able to read assembly. This culture of ignorance that has been fostered, as seen in sibling comments, is why Notepad now takes 10x as much memory as a full operating system like Windows 95. Application developers should absolutely have an idea of how not to piss away their users' resources. Understanding what you're abstracting away is crucial to that. I promise you it's not even hard. In the 90s every professional programmer understood assembly. It was normal, not some elite hacker language. It can still be normal.

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.

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.

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 :-)

No. If you're a low-level C language programmer then it is useful.

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

\m/

AoT is still a thing. Presumably a lot of the JIT improvements would also improve the generation of AoT-compiled code.

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.

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.

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!

For some people LLM-spotting feels like a sport they need to compete in

This is the loudest release of .NET to date(!)

Backing you up on this. I smelled LLM and hit cmd+w.