5 ms·

The CLR and BLC provided a lot of services, of course this code taking some space. It’s totally a WASM problem since there is not other way to ship the C# runti

The CLR and BLC provided a lot of services, of course this code taking some space. It’s totally a WASM problem since there is not other way to ship the C# runtime and libraries than downloading them each time. Exactly what plugins (Flash, Silverlight) were avoid...

achn 6y ago
There are some big improvements in .net 5 that allow more granular linking and should help reduce solitary binary size, and that may trickle down to Mono and Wasm soon.
flohofwoe 6y ago
IMHO the main problem is choosing a language which needs a big runtime in the first place. UNO seems to be at a point where the Unity game engine was about 5 years ago in their asm.js/WASM efforts. In the end they realized that it's impossible to get the .NET runtime small enough for the web (at least for typical C# code which uses common standard library features). The way Unity solves this is by creating their own C# dialect, compiler and minimal runtime (without GC etc). Sort of a brute-force approach, but until the standard .NET ecosystem solves the bloat problem it would have been better to build on a different language ecosystem.
- withinboredom 6y ago
  This is basically the same thing that Android did with Java. I think it’s probably best to pick a productive language and solve the problem from there. Low level languages are rough to work with when compared to what you get from unity.
- kevingadd 6y ago
  While you're correct that Unity "solved" the problem, you can't generalize their solution to things other than games. You end up needing a bunch of custom ecosystems for specific problems and when we're talking about enterprise, education, etc apps they often end up needing everything because sometimes you just end up with a massive Our Company's App that has 20 different responsibilities. To put it another way: Adobe can ship Photoshop using Emscripten, and big companies can probably eventually ship their internal C# business apps using Uno or Blazor, but you're not going to ship either of those using Unity's stock approach without building out all of the platform APIs they stripped out and adding back runtime features that were removed. The decisions they made were perfect for games, but people building general-purpose platforms can't cut all those corners.
  - gamblor956 6y ago
    Unity has supported the .Net Framework (using .Net 4x) for several years... However, they do not guarantee that the APIs in the .Net framework will work on all platforms, as some of them are still Windows specific. https://docs.unity3d.com/2019.1/Documentation/Manual/dotnetProfileSupport.html https://docs.unity3d.com/2019.1/Documentation/Manual/dotnetP...
- gamblor956 6y ago
  Unity uses normal C#. They switched to using the Rosyln compiler several years ago. https://yadiyasheng.medium.com/confusing-threesome-in-unity-c-mono-and-il2cpp-df2a2e85949a https://yadiyasheng.medium.com/confusing-threesome-in-unity-... They do take the IL generated by Rosyln and convert it to executable code using their own custom transpiler.
  - flohofwoe 6y ago
    I mean the new "DOTS" stuff: Burst compiler, the HPC# language dialect, new ECS, and "Project Tiny". All except Project Tiny is being built mainly to improve performance, but it also benefits the web as target platform.
madeofpalk 6y ago
Is this a "WASM" problem or is a "hey we decided to ship all of C# to the browser" problem? I think this is a fine tradeoff for certain contexts and usages, but I don't think the general usecase for WASM is to build general web applications in C# and ship all of the CLR for things like gmail.
- flohofwoe 6y ago
  There's some inherent overhead in a .NET runtime which will be hard to get rid of, like the garbage collector. In the end it probably comes down to .NET being "too dynamic", making it hard to identify and eliminate dead code. Also typical high-level C# code tends to use a lot of 'standard library' features, basically the opposite of the 'embedded coding mindset' needed for small WASM apps.
  - jlaban-uno 6y ago
    - Uno dev here If anything, the BCL or common libraries are too "static", where some pieces of code reference statically all features available. One great example is JSON.NET: That library has basically one big method that type-checks all possible inputs, making unconditionally reachable every dependency for all features of the library. In this case, JSON.NET pulls the XML reader, DataSets, and many huge libraries that are generally not needed. In Uno, we generally don't AOT those libraries and use the interpreter for that (otherwise the payload would explode). Such libraries need to be changed to be configurable, and dynamically enable dependencies as per the user's needs. Conversely, many pieces of code are excluded by configuration because of reflection uses, but the .NET team is improving that scenario (https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-5/#trimming https://devblogs.microsoft.com/dotnet/performance-improvemen...) with attributes to tag dependencies and hint the linker.
    - flohofwoe 6y ago
      A similar problem exists in the C/C++ world: designing a library in a way that supports good dead-code-elimination isn't something that many library authors think about. Interestingly plain C libraries often do this better than C++ libraries (e.g. too generous use of virtual-method-interfaces in C++ libraries, or making heavy use of C++ stdlib containers when simple C-style arrays would do as well). The Unity engine also suffered from a similar problem: If you used a simple physics feature like a stabbing collision check somewhere in your code, the entire physics module was pulled in, even though the code needed for stabbing checks is only a few percent of that physics module. This is why I'm a bit sceptical that improvements in the .NET "machinery" alone can solve this problem. You also need to restrict language features and select the right dependencies. This is a general problem, not just web-specific, it's just that reducing the output binary size typically isn't a high-priority problem outside the web.
chabad360 6y ago
I guess we'll just have to wait for WASM binaries to support dynamic linking, at which point we'll get services like "cdnwasm" or "wasmdelivr".

achn 6y ago

There are some big improvements in .net 5 that allow more granular linking and should help reduce solitary binary size, and that may trickle down to Mono and Wasm soon.

flohofwoe 6y ago

IMHO the main problem is choosing a language which needs a big runtime in the first place. UNO seems to be at a point where the Unity game engine was about 5 years ago in their asm.js/WASM efforts. In the end they realized that it's impossible to get the .NET runtime small enough for the web (at least for typical C# code which uses common standard library features). The way Unity solves this is by creating their own C# dialect, compiler and minimal runtime (without GC etc). Sort of a brute-force approach, but until the standard .NET ecosystem solves the bloat problem it would have been better to build on a different language ecosystem.

withinboredom 6y ago
This is basically the same thing that Android did with Java. I think it’s probably best to pick a productive language and solve the problem from there. Low level languages are rough to work with when compared to what you get from unity.
kevingadd 6y ago
While you're correct that Unity "solved" the problem, you can't generalize their solution to things other than games. You end up needing a bunch of custom ecosystems for specific problems and when we're talking about enterprise, education, etc apps they often end up needing everything because sometimes you just end up with a massive Our Company's App that has 20 different responsibilities. To put it another way: Adobe can ship Photoshop using Emscripten, and big companies can probably eventually ship their internal C# business apps using Uno or Blazor, but you're not going to ship either of those using Unity's stock approach without building out all of the platform APIs they stripped out and adding back runtime features that were removed. The decisions they made were perfect for games, but people building general-purpose platforms can't cut all those corners.
- gamblor956 6y ago
  Unity has supported the .Net Framework (using .Net 4x) for several years... However, they do not guarantee that the APIs in the .Net framework will work on all platforms, as some of them are still Windows specific. https://docs.unity3d.com/2019.1/Documentation/Manual/dotnetProfileSupport.html https://docs.unity3d.com/2019.1/Documentation/Manual/dotnetP...
gamblor956 6y ago
Unity uses normal C#. They switched to using the Rosyln compiler several years ago. https://yadiyasheng.medium.com/confusing-threesome-in-unity-c-mono-and-il2cpp-df2a2e85949a https://yadiyasheng.medium.com/confusing-threesome-in-unity-... They do take the IL generated by Rosyln and convert it to executable code using their own custom transpiler.
- flohofwoe 6y ago
  I mean the new "DOTS" stuff: Burst compiler, the HPC# language dialect, new ECS, and "Project Tiny". All except Project Tiny is being built mainly to improve performance, but it also benefits the web as target platform.

madeofpalk 6y ago

Is this a "WASM" problem or is a "hey we decided to ship all of C# to the browser" problem? I think this is a fine tradeoff for certain contexts and usages, but I don't think the general usecase for WASM is to build general web applications in C# and ship all of the CLR for things like gmail.

flohofwoe 6y ago
There's some inherent overhead in a .NET runtime which will be hard to get rid of, like the garbage collector. In the end it probably comes down to .NET being "too dynamic", making it hard to identify and eliminate dead code. Also typical high-level C# code tends to use a lot of 'standard library' features, basically the opposite of the 'embedded coding mindset' needed for small WASM apps.
- jlaban-uno 6y ago
  - Uno dev here If anything, the BCL or common libraries are too "static", where some pieces of code reference statically all features available. One great example is JSON.NET: That library has basically one big method that type-checks all possible inputs, making unconditionally reachable every dependency for all features of the library. In this case, JSON.NET pulls the XML reader, DataSets, and many huge libraries that are generally not needed. In Uno, we generally don't AOT those libraries and use the interpreter for that (otherwise the payload would explode). Such libraries need to be changed to be configurable, and dynamically enable dependencies as per the user's needs. Conversely, many pieces of code are excluded by configuration because of reflection uses, but the .NET team is improving that scenario (https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-5/#trimming https://devblogs.microsoft.com/dotnet/performance-improvemen...) with attributes to tag dependencies and hint the linker.
  - flohofwoe 6y ago
    A similar problem exists in the C/C++ world: designing a library in a way that supports good dead-code-elimination isn't something that many library authors think about. Interestingly plain C libraries often do this better than C++ libraries (e.g. too generous use of virtual-method-interfaces in C++ libraries, or making heavy use of C++ stdlib containers when simple C-style arrays would do as well). The Unity engine also suffered from a similar problem: If you used a simple physics feature like a stabbing collision check somewhere in your code, the entire physics module was pulled in, even though the code needed for stabbing checks is only a few percent of that physics module. This is why I'm a bit sceptical that improvements in the .NET "machinery" alone can solve this problem. You also need to restrict language features and select the right dependencies. This is a general problem, not just web-specific, it's just that reducing the output binary size typically isn't a high-priority problem outside the web.

chabad360 6y ago

I guess we'll just have to wait for WASM binaries to support dynamic linking, at which point we'll get services like "cdnwasm" or "wasmdelivr".