+66,578; -14,479 across 58 PRs (plus a few others PRs I know aren't in my tracked list)
Definitely smaller from the perspective of who will directly use it, but big from those that can indirectly benefit via the BCL or implicit improvements to existing SIMD code ;)
@tannergooding Bingo. While many folks will benefit from it, I think few will comprehend what the work means for them. Maybe I should have used “top-of-mind”. I was not attempting to diminish the work that went into it, apologies. :)
From my perspective, that stuff is “BIG” since it’s one step forward on the road to Wasm. I think Wasm could be the great uniter, bringing ecosystems together. The ring to rule them all.
Speaking of WASM and intrinsics, WASM SIMD has been getting worked on as well and I didn't include that in my numbers.
Plus lots of general SIMD light-up for Mono JIT and Mono Interpreter (Arm64, x64, and WASM) which will help other workloads as well
Lots of big perf wins showing up in the micro-benches and translating to measurable wins in the "real world" benchmarks/apps and dedicated benchmarks like TechEmpower as well
Adding IUtf8SpanFormattable also gave some pretty nice wins in real workloads. IUtf8SpanParsable is also in the works and should do the same
@tannergooding Personally, I don’t put a lot of stake in the TechEmpower benchmarks. Many produced results are from code that many folks wouldn’t write.
That said, I’m sure the benefits are there.
My wishlist item would be for MS to invest more in NuGet and bring a first-class Wasm dependency into MSBuild, like you would with any other package. In the process, an .NET compatible interface would be generated based on the Wasm interface manifest.
@khalidabuhakmeh@tannergooding my question would rather be why is Mono VM getting any investments at all, instead of fully focusing on .NET Native (including for mobile targets). That would be something
@filipw@tannergooding I believe the Mono runtime is what Blazor is based on (correct me if I’m wrong). So those are the assemblies that get pushed to the client.
@khalidabuhakmeh@filipw@tannergooding Umm..not sure that's still true. It would be odd if it WASN'T .NET Core based now (considering .NET core started from silverlight's .net implementation IIRC)
@scottgal@filipw@tannergooding OK, Blazor is weird. Some assemblies are used from the current runtime, while some target 4.0.0 (I assume Mono). So…. Both? 🤷♂️
Here's a random subset of the assemblies transmitted to the client.
@scottgal@filipw@tannergooding But to Tanner’s point, maybe this is what the transition looks like. So maybe the idea in later versions of .NET is to get rid of some of these dependencies.
WindowsBase.dll is really odd, but I guess that’s what a dependency graph does, it brings in weird dependencies.
@agocke@tannergooding I think it’s a chicken/egg scenario tbh. But the idea that a polyglot team could artifact their ecosystem-based work (say Kotlin or Rust) into a Wasm distributable that could be hosted in a .NET process is a compelling case for using .NET.
@khalidabuhakmeh@tannergooding Rust, maybe. Kotlin? Idk, you want to silently shove a whole JVM into your process as though it was just another NuGet package? Or worse, 10 JVMs?
Another might be to consume packages from other ecosystems, like an NPM package, to perform tasks not part of the .NET OSS ecosystem.
I mean, how else am I supposed to LeftPad?! (Just kidding).
On a more serious note, you could consume React/Vue/Svelte on the server in-process to render the server-side output of components as part of an #aspnetcore request/response.
@agocke@tannergooding The way folks are building component-based UIs today has a component of server-side rendering that does not work well with the Razor engine. Wasm extensions could provide packaged and executable versions of libraries to process the HTML on a Razor page, which would be faster than calling out to an external process to do the processing.
Just a crazy thought I’m having, maybe I’m in Lala land though.
@khalidabuhakmeh@tannergooding Same deal, right? Now you're hosting a V8 engine or something similar? Fundamentally, if you compile to WASM you need to bundle a runtime as well. If you're Rust that's not a big deal because your runtime is tiny, but everyone GC'd is not gonna be small.
@agocke@tannergooding Maybe this is naive on my part, but maybe you don’t need GC since these processes/calls are short-lived. Call into the dependency, get your result, destroy everything, and move on.
I believe that’s how FaaS hosts operate. They spin up your function, run it, and kill it. One provider takes a memory snapshot right after the first start is complete to reduce cold start times.
@agocke@tannergooding I only think it’s important to distinguish between runtime and development-time dependencies. I would pay the memory and resource cost to get added functionality at compile time (I guess that is what AOT does, right?).
@khalidabuhakmeh@tannergooding This isn't really a choice the user gets to make. If someone publishes a WASM package, they need to encode the runtime for their language because otherwise it just won't work. You can't go after the fact and pull out pieces of the runtime they packaged up.
@khalidabuhakmeh@tannergooding I think the best you can hope for is that WASM defines a GC spec which is actually usable by all the languages. I'm not sure how likely that is.
@khalidabuhakmeh the whole Ubuntu smol images using chisel is interesting too though that may also work with six, it all blurs into the mess of versioning differences I have to memorise back to .net 3.5 😂
Add comment