EgorBo

Yes, because the idea to make it first-class, not on top analyzers. It's hard to do it via analyzers properly - too many implicit copies happen under the hood. We've had quite a few bugs where such types would not allow that to happen: all kinds of structs holding & destroying some handle (GCHandle.Free, ArrayPool.Return, something native, etc).

@EgorBo @migueldeicaza It seems something similar exists inside the BCL as well, but the discussion was closed just recently. github.com/dotnet/runtime…

@neuecc @migueldeicaza non-copyable (aka 'move-only') are on C#'s team radar. For now, there is a 3rd party analyzer - github.com/ufcpp/NonCopya…

@migueldeicaza Yes! For example, a struct that holds a pointer becomes more dangerous when copied, but if we can prevent copying, it can be used safely.

定期的に思うけどcopy禁止structの仕様をC#に入れないのなんでなんなん？

@theDiverDK @davidfowl I had another benchmark today, opus did it for 45$, gpt for 220$. So it's hard to actually state anything. I guess it depends on the harness, instructions and pure luck :\

@EgorBo @davidfowl You are right Opus killed it, twice as expensive as #2 Anthropics models are way to expensive. I’ll stay with OpenAI’s model they nail it,

Tired of toy AI benchmarks like making simple games with threejs. I had 3 LLMs (Opus 5, Opus 4.8, GPT 5.6 Sol) implement a real register allocator for .NET's Tier0 JIT instead. Goal: 2%+ faster compilation (measured with ~0.01% precision). The task involved some creativity and trade-offs. Opus 5 killed it.

@aleh_tiktack I explicitly asked to write one from scratch actually, the other two models just decided to make cosmetic changes over the existing one to speed it up. Opus 5's version turns out to be 17% faster (than the baseline) in the end.

@EgorBo I think sol killed it, not opus. It improved 2x requested and added 300 lines of code. Opus just re-wrote something with 1600 lines for double the price

@michaldobro Sadly, no access to fable5 due to their data retention policy :(

@EgorBo Would be interesting to see fable5

@mrneobeard @neuecc I think it's very unfortunate that we have it and I hope one day we'll remove it (with help of advanced escape analysis). We won't be able to if we expose as a public API obviously. Asked AI to list reasons why it's a bad API:

@EgorBo @neuecc github.com/dotnet/runtime… One of many examples.

Are you a Microsoft employee? If not, you have no right to use Unsafe. Performance? Don't worry, we will take care of that. Do you really need that extra 2-3% performance gain? If you are not an employee, you have no right to use it. Since when did C# become a typical dystopia?

@neuecc There is a crazy amount of unsafe code in there I must admit😐

Back to the original principle that "performance is the greatest feature". I've just posted the MessagePack for C# v4 proposal! From 2x up to 10x+, squeezing out performance to the absolute limit! github.com/MessagePack-CS…

@vzarytovskii aged like a fine milk

So, how is - 52x faster than FlashAttention at 1MM tokens - Less than 5% the cost of Opus going? Asking for a friend.

@scottjmaddox @VictorTaelin it's definitely not always elided, this area needs more work inside Rust/LLVM, example: x.com/EgorBo/status/…

@VictorTaelin Bounds checking is elided in rust when the compiler can prove the access is always in bounds. Having the option to prove it explicitly is a nice feature, though.

a late addition to Bend2 that makes it even *faster* than Rust in some cases: safe, O(1) unchecked array indexing in Rust, to index an array, you either pay a bound check (making it slower than C), or use unsafe get/set, which defeats the entire memory safety story. on Bun's Rust migration, AFAIK, unsafe{} is used nearly everywhere in Bend, you can have both. that's possible due to a combination of linear types, which gives us O(1) arrays, and dependent vectors, which allow the compiler to statically verify that no out-of-bound access is possible in other words, Bend makes this entire class of exploit (which, arguably, is THE main cause of zero days) impossible by construction, while retaining full native C performance - potentially, at least

Follow-up: a more power-efficient SpinWait with armv8.7+ WFET/WFxT: github.com/dotnet/runtime…

Minor improvements: Scalar cnt/ctz on Apple M5 (armv8.9+) github.com/dotnet/runtime… 🙃

@torn_hoof Not yet, but hopefully there will be

@EgorBo Is there a roslyn quickfix for the callers?

If you're curious about which APIs will start requiring an `unsafe {}` context to call them in .NET vNext, here they are: github.com/dotnet/runtime… (~350 for now).

Time flies, I guess it means Xamarin was aquired 10 years ago🙃

So they optimize bound checks using unsafe in their stdlib github.com/rust-lang/rust… 🥲

One thing Rust suffers from is lack of complex bound check elimination in LLVM, trivial example: godbolt.org/z/4fMcjh8Eh LLVM has knownbits & constant ranges, but no symbolic ranges. 🤔

in .NET 11.0 we've landed many changes in JIT (applies to NAOT too) to optimize redundant bound checks to make safe code as fast as unsafe (can be tracked via reduce-unsafe label github.com/dotnet/runtime…). Example: github.com/EgorBot/Benchm…