blend2d VS .NET Runtime

Blend2D: https://blend2d.com/

I don't know the history, but there is supposedly a fixed set of Porter Duff blend modes, specific algorithms. For example, this library:

> Blend2D supports all Porter & Duff compositing operators

https://blend2d.com/

If you can make the "putting the pixels on the screen" part fast, blend2d is a very good software rasterization solution I think.

regarding the topic of compiling shaders for a 2D GUI, using a JIT is a key advantage, see e.g. https://github.com/blend2d/blend2d

Let's go step by step. Looking into dotnet runtime we can find that Libraries.SystemNative acts as a shim (adapter) to a dynamic library called libSystem.Native.

> by this metric

False equivalence. You're saying that the statement "both for.. append" and ".map()" executing the _same steps_ in the _same order_ are the same is equivalent to saying that two statements being composed of cmp,jmp, etc (in totally different ways) are the same. That is a dishonest argument.

> Distinct could sort and look for consecutive, it could use a hashmap

People love happy theories like this, but find me one implementation that does this. For example, here is the distinct() implementation in the most abstraction-happy language that I know - C#

https://github.com/dotnet/runtime/blob/main/src%2Flibraries%...

It unconditionally uses a hashset regardless of input.

For the .NET JIT, at least, speculation on types seems beneficial even if we're only right maybe 30% of the time.

See eg https://github.com/dotnet/runtime/blob/main/docs/design/core...

(where this is presented as a puzzle)....

Destructors? Destructors are fine as a feature. You're not supposed to use them as the first choice but they are a great "safety net" for disposable types that did not get dispose to ensure that production code stays resilient to unmanaged memory leaks when presented with bad code.

Either way, you can read through this issue: https://github.com/WebAssembly/gc/issues/77

Further discussion can be found here: https://github.com/dotnet/runtime/issues/94420

Turning off destructors will not help even a little because the biggest pain points are support for byref pointers and insufficient degree of control over object memory layout.

Let's move on to analyzing the .NET 9 source code; we'll explore the release code available on GitHub.

Indeed. Both OpenJDK HotSpot and .NET RyuJIT perform guarded devirtualization of monomorphic or polymorphic with few instances callsites. OpenJDK also computes optimized call table for megamorphic callsites, which .NET does not need to do for virtual calls, it does have something similar for un-devirtualized interface calls however (virtual stub dispatch caching).

This is not necessarily zero-cost however - if the compiler cannot prove specific type members being invoked, it has to construct an execution profile and then apply it to subsequent compilations, and also emit a guard when doing dispatch on those.

[0]: https://github.com/dotnet/runtime/blob/main/docs/design/core... (note - subject to change)

This is great and despite what the article says, an actually useful technique. The reason this performs well is the .NET runtime does monomorphization when the generic type parameters are value types (primitive types like int or user-defined structs). In modern .NET you would use static abstract methods interface methods to implement this feature. But if you have to run on the old Windows-only .NET Framework, you need to use the approach used in BrainFlood. See this article [1] for more details. An example of an official .NET library that uses this technique on .NET Framework is TensorPrimitives. See this file [2], the structs are defined at the bottom.

[1]: https://blog.stephencleary.com/2022/10/modern-csharp-techniq...

[2]: https://github.com/dotnet/runtime/blob/main/src/libraries/Sy...

Though today much of the Microsoft.Extensions family is considered BCL by most users, especially in the way it is documented as "Core functionality" (the "Generic Host" model uses a lot of Microsoft.Extensions, up front in .NET documentation today) and also in the way that the majority of it (especially in this case of Microsoft.Extensions.Logging) is source controlled side-by-side with most of the BCL, including almost all of System.**: https://github.com/dotnet/runtime/tree/main/src/libraries

(There are some of Microsoft.Extensions that exist outside of dotnet/runtime in dotnet/extensions: https://github.com/dotnet/extensions/tree/main/src/Libraries)

GCHandle.cs