Add .NET on WebAssembly workload

[maraf]

Add benchmarks for .NET runtime on WebAssembly.
This PR adds 8 benchmarks that test characteristic WebAssembly code for .NET. Benchmarks don't contain UI manipulations and javascript interop except for the necessary startup.

Flavors

There are two flavors of the same benchmark code.

1. Interpreter

The default mode for running .NET (Mono runtime) on WebAssembly is using an interpreter. In this mode .NET assemblies are loaded into WebAssembly memory and IL interpreter interprets the code in a loop.

2. AOT

The second mode Mono runtime on WebAssembly operates in is mixed AOT. It is a mixture of AOTed code and fallbacks to interpreter for scenarios that are not supported by the AOT compiler.

Code samples

RayTracer

Source code at https://github.com/pavelsavara/dotnet-wasm-raytracer. It computes a 3D scene in memory. It is a computation heavy algorithm that stretches the performance of interpreter loop. The UI update part is removed.

Exception handling

.NET uses a two-phase exception handling that is built on top of WasmExceptionHandling.

String

Very common and often used type in .NET codebase.

JSON serialization & deserialization

Very common and often used type in .NET codebase.

Fixes dotnet/runtime#109953

[netlify]

✅ Deploy Preview for webkit-jetstream-preview ready!

Name	Link
🔨 Latest commit	8cba497
🔍 Latest deploy log	https://app.netlify.com/projects/webkit-jetstream-preview/deploys/68396a99f5d52c00082347bd
😎 Deploy Preview	https://deploy-preview-73--webkit-jetstream-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[eqrion]

@maraf Thanks for this!

A couple of questions:

1. What is the default or recommended compilation mode for .NET on wasm? Is it the interpreter or AOT?
2. Does exception handling happen in performance sensitive .NET code? The wasm exception handling feature has been mostly designed with the expectation it's for cold non performance sensitive code. So adding a benchmark just testing it's performance would not be ideal. It's useful to have one for looking for easy optimizations we could make, but to really get good performance would require some techniques that could slow down normal code and we'd prefer not to do that.
3. Can the size of the iterations on these benchmarks be reduced? I'm getting about a minute and a half to just run 'dotnet-aot-string' in Chrome on a pretty powerful laptop. For reference, the zlib-wasm test is running in about 3 seconds.

I think we should probably reduce the number or combine some of these tests so that we're not weighting dotnet too heavily. Right now there are 8 added, which makes it 8 times more important than any other wasm test. I think we've talked about having experimental tests that are not in the main score by default, we could potentially do that here.

[maraf]

@eqrion Thank you for feedback!

1. There isn't one recommendation, and the usage is like 50:50. Both modes have some specific characteristics.
2. .NET has two pass exception handling (virtual unwind to find matching handler docs and actual unwind) which made us implementation some layers on top of wasm exception handling. It is pretty common to use exceptions in .NET to control the non-success path in code execution.
3. I was targeting <= 10s per iteration on my machine, I'll work on further reduction.