Compile to LLVM or WASM

[tarsa]

hmm, so you want to leverage scala-on-wasm to bring scala to more platforms rather than achieve speedups, because you don’t believe in the speedups? well, at least something tiny, but concrete actually is now understandable from your rant.

wasm gives you full set of primitives. javascript gives you only type number (which is double, i.e. 64-bit floating point) and int (32-bit signed integer if your code fits into certain shape). longs (64-bit signed integers) and other types of numbers have to be emulated, which slows things down (sometimes several times). that stuff alone could give significant speedup when number crunching. also there’s fixed-simd extension for wasm (and it’s already finished: proposals/finished-proposals.md at main · WebAssembly/proposals · GitHub ) that replaces the simd.js (which is now removed). next in line is GitHub - WebAssembly/relaxed-simd: Relax the strict determinism requirements of SIMD operations. which will allow you to use the full width of simd units in your cpu. that would be a major speedup compared to scalar javascript code.

@MateuszKowalewski

But Scala Native is much closer. That’s the whole point.

as stated previously by others, non-ignorable parts scala-native ecosystem requires unrestrained pointer arithmetic, so to migrate to wasm they would need to be rewritten. in order not to lose performance when compiling to bare metal, you would need two versions of scala code targeting scala-native: one with unrestricted pointer arithmetic (to get full performance) and one with restricted pointer arithmetic (to get wasm compatibility).

scala.js-to-wasm in the first prototype would allow you to compile programs to wasm without major modifications.

@MateuszKowalewski

Which means lowering the Scala IR down to a level that is close to what you need to run Scala on a bare C abstract machine. Which is reimplementing Scala Native…

i highly doubt that most of the effort would be spent on implementing wasm backend in scala.js. most probably rewriting the standard libraries and ecosystem to not depend on browser-specific apis would be the major effort. and with scala-native you also need to rewrite libraries, from plain libc to wasi-libc.

@MateuszKowalewski

Nothing compared to what LLVM (or actually the JS JITs) could do.

You would need to implement all these AOT optimizations to be even just theoretically competitive. But like mentioned a few times: Often even Rust code, compiled and optimized though LLVM, does not come anywhere close to the efficiency of JIT compiled JS.

why scala compiler has to implement all aot optimizations? the wasm runtime is optimizing too. the more metadata you give it (by using correct built-in primitives that wasm platform gives you), the more optimizations it sees.

@MateuszKowalewski

Scala.js-on-WASM makes no sense. It won’t bring Scala to a new platform all in all. That’s dead end effort.

that’s just your opinion. there’s a plan already to make scala.js-to-wasm that is free of browser-specific apis.

@MateuszKowalewski

At least this would explain why they doing these crazy things at all. Do you have a source? Because I also never understood why MS is burning such ridiculous amounts of money on something that quite obviously doesn’t work well (and likely never will).

i don’t get it. blazor does work. it’s slow, contrary to the hype, but it works. developer experience is probably ok. their objective was probably to allow coding webapps in c# on client side, which they achieved with blazor wasm.

i don’t have definitive sources (i don’t fancy spending a lot of time digging through whole asp.net repo to find details about blazor wasm memory management low-level details), but the issues about blazor wasm support for wasm gc suggest that blazor wasm doesn’t yet use wasm gc at all:
[Blazor] WASM GC · Issue #82974 · dotnet/runtime · GitHub
which is closed because the issue is now tracked at
.NET Notes · Issue #77 · WebAssembly/gc · GitHub