.NET Runtime VS runtimelab

This issue is still open: https://github.com/dotnet/runtime/issues/35995

Also, it seems that initial memory settings have a big effect on mobile, this is a fix that will make it for 7.0.4 (April): https://github.com/dotnet/runtime/pull/80849

looked it up and engine.cpp seems to only be 8.5k lines, which doesn't seem super unreasonable to work with. It ain't no gc.cpp that's for sure.

Threading.Channel has more or less replaced all the concurrent queue alternatives for me. channels have the benefit of nonblocking wait for when the channel can be written.

My teammate created an issue on GitHub: the developers fixed the order of arguments and added a test.

i have tried with an adapted .editorconfig but even using the "official" dotnet team editorconfig

Technically Mono supports RISC-V, so you can get .NET code running on it. Also it looks like if you're willing to go through messy and poorly documented build processes you can build CoreCLR on RISC-V: https://github.com/dotnet/runtime/issues/36748

So proper support is likely coming soonish, I'd guess by the time .NET 8 comes out.

There's an issue on simplifying WebSockets specifically https://github.com/dotnet/runtime/issues/77060 that may be of interest.

See CLR is also using left/right for its not-quite-binary-tree in SortedSet. Though this also uses the Enum-As-Discriminator trick instead of boolean/array. I know the JVM also has/uses left/right but I can't find the backing source file right now.

The thing that is great here is dotnet -> wasm, and there is sounder work on that at an earlier stage in the runtimelab NativeAOT-LLVM branch https://github.com/dotnet/runtimelab/issues/1828.

> There's something nice about the ergonomics of a single file compared to a single folder though

Agreed. We are going to move to proper single file (or as close as we can get) as soon as any sort of meaningful AOT compilation is available:

https://github.com/dotnet/runtimelab/tree/feature/NativeAOT

https://github.com/dotnet/runtimelab/issues/248

There is a "PublishSingleFile" option, but that is just a zip file in disguise.

Good choice of words. Indeed, one nonetheless can compile their app to native code without IL at all, for example, via NativeAOT

You can, as sbelskie mentioned below. In .Net 6, it's available as a Preview [1]. But it's going to ship with the main framework in 7.0 [2].

The preview works quite well. You can build self-contained, smaller executables, and shared libraries callable from say, C code.

[1]: https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/...

[2]: https://github.com/dotnet/runtime/issues/61231

Can you share any resources how to build such a DLL? I found this document, but it sounds like it would produce an EXE rather than a DLL: https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/docs/using-nativeaot/compiling.md

Here

> “.Net has almost the same performance as Golang and Rust, but only after 1k iterations(after JIT).”

Additions like async/await and nullable reference types make it easier to write bug-free code, which for a lot of folks is a better trade off than “speaking to the hardware directly”.

.NET also runs natively on a bunch of platforms now, including ARM.

I’d call all of that continuous improvement. Perhaps even reinvention?

[1] https://docs.microsoft.com/en-us/dotnet/core/deploying/ready...

[2] https://github.com/dotnet/runtimelab/tree/feature/NativeAOT

[3] https://www.techempower.com/benchmarks/#section=test&runid=5...

For example, ordinary IoC containers depend on reflection emit. Such an approach will not work on platforms where AOT compilation is supported. They will throw an error in runtime. The AOT compilation is supported in Xamarin, Unity and Native AOT So, if you want to use AOT compilation to improve startup performance and ioc container then the source generation is a single option.