Go WASM performance

[brillout]

There are some concerns about Go performing poorly with WASM (e.g. here).

What are your thoughts on this?

[jakebailey]

I haven't seen any info in these threads about how to reproduce it. I don't see why a basic example would take a full second. It doesn't help that this all is happening on Twitter where I can't view the threads without logging in either...

https://jakebailey.dev/esbuild-playground/ for example does not work that slowly for esbuild.

[jakebailey]

Also, these tests really need to disable multi threading via --singleThreaded. That hasn't been done so they are all incurring context switch costs.

I would really have liked for people to not go spread perf numbers far and wide without actually talking to us about them...

[styfle]

It looks like https://jakebailey.dev/esbuild-playground/ doesn’t do type checking?

Here’s the link from the tweet: https://tsgo.sxzz.dev/

Is there another url that uses those best practices so we can try out type checking in the browser with TS GO + WASM?

[0xdevalias]

Are all of these examples including the load time or something?

Might be..

Loading https://tsgo.sxzz.dev/ gives me like 2-3sec on their little timer; but then if I adjust the code slightly it completes in like 700-800ms.

(Completely non scientific vibes test off my iPhone)

[HerringtonDarkholme]

Hi @jakebailey! Tweet author here. I didn't mean to spread negativity on social media and am very happy to provide additional information if you need.

The code for the playground https://github.com/sxzz/typescript-go-playground
Playground itself https://tsgo.sxzz.dev/
The code I was testing in the tweet. microsoft/TypeScript#14833 (comment)

TS-go wasm is not an official product and probably the team is not prioritizing shipping a playground at the moment. But if you want some more investigation I am very happy to help here!

[jakebailey]

I stand corrected; I just tested locally in wasmtime and setting --singleThreaded makes it slower. Wow. I guess it's not heavy preemption (though Go will still preempt without us spwaning goroutines).

[Jorropo]

For context relevant issues in Go:

• cmd/compile: performance of go wasm is very poor golang/go#65440
• runtime: implement WASM-GC golang/go#63904

Copying what I've said in a response in the go slack:

Wasm support in Go works very well*.
It's just slow at basic things like loops or compute

Among other things:

• WASM lack support for JMP instructions (CFG is emulated with for continue and a huge switch statement) cmd/compile: performance of go wasm is very poor golang/go#65440
• WASM GC doesn't support interior pointers and is radical paradigm shift requiring a huge amount of compiler work to get working
• No way for arbitrary indirect jumps required to implement goroutines (emulated same way as point 1)

A lot of this could be improved by spending lots of time in the Go compiler, but this is disincentivized because new better spec like https://github.com/WebAssembly/stack-switching would reshape the whole landscape of what is possible and how it would be achieved,
And then when they show up (like wasm-gc) turns out there is one tiny design hole that makes it close to unusable ✨.
I was told tinygo is better at this, which is not surprising because they use LLVM.

As someone who touches the Go compiler, I don't think any of this is a language issue (see tinygo), it's an implementation issue due to the go compiler having been designed to target traditional assembly,
WASM is closer to a reverse engineered V8 IR than to riscv or amd64 and there have been less engineering time put into making the go compiler's backend as good than LLVM's at this.

*by that I mean, unlike what I often hear, the full language is supported, making a compiler is lot of work and gopherjs is still working on generics support for example.

[HerringtonDarkholme]

As a comparison, the esbuild wasm build is using standard go compiler, with GOARCH=wasm

And the performance is okay. Maybe it is caused by tsgo playground's compilation issue?

[Jorropo]

Do you have numbers for the exact same esbuild workload on linux / macos / windows ?