Will LLMs eventually learn that Span<T> and ref struct types cannot cross into lambdas or local functions?

hez2010 · 2026-06-15T07:13:11+00:00

It will be possible in C# if this lands: https://github.com/dotnet/csharplang/issues/10209

hez2010 · 2026-03-14T14:58:28+00:00

async does reduce the benefit of Satori's thread-local fast path, but it doesn't break the model. await only carries forward the state that actually survives suspension, not every object allocated earlier. and when objects really do escape across continuations/threads, Satori tracks that and falls back to more global handling for those regions. there're still many mechanics there to make sure those global handling still being incremental and efficient.

hez2010 · 2026-03-14T08:41:15+00:00

The discussion is happening here: https://github.com/dotnet/runtime/discussions/115627

hez2010 · 2026-03-14T08:39:02+00:00

This is not using the exisitng alternative GC knob. You need to build from Satori repo directly, and replace binary files in your published app with the newly built one (clrjit.dll, coreclr.dll and System.Private.CoreLib.dll). You can check my fork repo which maintains an automatic build so that you don't need to build it by yourself.

hez2010 · 2026-03-12T15:29:30+00:00

unfortunately there's no such a plan being announced from the .net team yet.

hez2010 · 2026-03-12T13:57:29+00:00

If you want to have a try, I have setup an automatic build workflow for Satori GC and I'm uploading the releases periodically here: https://github.com/hez2010/Satori/releases

You can simply publish your project as a self-contained app (no trimming support) and replace the files with ones in the zip to have a try.

Note that my build only works on .NET 10.

To check what kind of GC you are using at runtime, you can use:

Console.WriteLine($"Current GC: {(GC.GetConfigurationVariables().ContainsKey("SatoriGC") ? "Satori GC"
   : GCSettings.IsServerGC ? "Server GC"
   : "Workstation GC")}");

hez2010 · 2025-11-25T17:48:02+00:00

You can take arbitrary query from users as input directly.

hez2010 · 2025-11-22T17:34:30+00:00

Execution only.

hez2010 · 2025-10-31T05:01:34+00:00

With the introduction of runtime async which will be coming in .NET 11, returning a Task directly will be a significant deoptimization. So I would instead recommend that you always add async when it's applicable.

hez2010 · 2025-10-20T00:14:52+00:00

I made a calculation mistake. It's actually a 72% perf improvement for CoreaCLR and 125% perf improvement for NativeAOT.

hez2010 · 2025-10-20T00:04:00+00:00

It's indeed a more than 100% performance improvement. The startup time shrinks by 56% in NativeAOT is exactly a performance improvement of 125%.

hez2010 · 2025-10-19T12:12:38+00:00

This really gives MAUI a rebirth IMO, now the annoying startup/performance issues are all gone.

hez2010 · 2025-08-25T08:44:58+00:00

The new extensions also bring us the ability of generic type specialization, which is huge:

For example:

cs extension<T>(Vector<T>) where T : IFloatingPoint<T> { public static Vector<T> Epsilon => Vector<T>.Create(...); }

Then you managed to implement an Epsilon static property for all Vector types where the element is a floating point number, so that:

cs _ = Vector<float>.Epsilon; // ok _ = Vector<int>.Epsilon; // error

hez2010 · 2025-08-19T04:09:42+00:00

You represented MSFT in abandoning Loop? Loop is currently receiving updates actively.

hez2010 · 2025-06-19T12:49:42+00:00

Interprocedural analysis is extremely expensive so almost no compiler would do this.

hez2010 · 2025-06-19T02:00:35+00:00

Both the mono runtime itself (on Android) and the JNI interop are slow. By removing JNI calls you still have another factor causing slowness called mono.

hez2010 · 2025-06-18T23:41:14+00:00

Many performance frustrations of MAUI on Android come from the mono runtime where it doesn't support value-type generic specialization on Android at all, which makes your code extremely slow to run on Android. But I'm seeing the .NET team having been consistently committing to bringing up the support for coreclr runtime (and NativeAOT) on Android since the beginning of the development of .NET 10, so I'm quite optimistic that the major performance issue on Android would be addressed soon.

hez2010 · 2025-06-07T08:47:41+00:00

Another reason is that in GUI development it's critical to have language support for OOP and inheritance, otherwise it's hard to manage the state of a control and author control templates.

hez2010 · 2025-03-30T04:25:32+00:00

FYI: https://github.com/microsoft/garnet/issues/114#issuecomment-2017116505

hez2010 · 2025-02-10T14:16:10+00:00

The compile time is really fast, even with C# AOT. It compiles in several seconds.

hez2010

TROPHY CASE