4 ms·

I wish they added some way of exporting wasm funcs as well so that they could be called from host. Tinygo wasm target supports both "exports" and "imports". The

I wish they added some way of exporting wasm funcs as well so that they could be called from host. Tinygo wasm target supports both "exports" and "imports". The other thing that is worse compared to tinygo is the generated binary size seems to be about 10x larger. From my brief look at the transpiled .wat printout a lot of included funcs aren't being called anywhere...

jsd1982 3y ago
The go-compiled wasm is also extremely slow compared to tinygo's wasm. Doing simple things like `fmt.Printf()` degraded performance significantly.
- alecthomas 3y ago
  I wonder if fmt.Printf() in particular is slow due to the CGo transition? Assuming there even is a CGo transition when compiled to WASM...
  - jbrandhorst 3y ago
    There's no CGO involved when compiling to Wasm. The sometimes slow performance is due to the hoops the compiled code has to jump through to support the Go runtime and goroutine preemption on a single thread.
    - alecthomas 3y ago
      I understand there's no CGo specifically, but I'm wondering if the Go runtime when running under WASM still has to manage switching out the goroutine stacks for "WASM stacks" when it's calling out through the WASM VM. Edit edit: from this comment it sounds like it is, as you say, just the general overhead of managing goroutine stacks. I wonder if TinyGo is more performant. [1] https://news.ycombinator.com/item?id=37501552 https://news.ycombinator.com/item?id=37501552
      - Patrickmi 3y ago
        Tinygo runtime don’t have g or m threads that’s why it’s Cgo is zero cost
viccuad 3y ago
I'm also waiting for that :) See https://github.com/golang/go/issues/42372 https://github.com/golang/go/issues/42372
- dilyevsky 3y ago
  Yeah there is an escape hatch via js package but it’s annoying
rockwotj 3y ago
FWIW we simulate exports by instead having `main` call an imported function that blocks until it's ready to return with the needed data. So instead of: `host -> call foo on guest -> return to host` `host -> call guest main -> call foo on host -> host returns when ready -> guest calls foo when done` FWIW the scheduler (so goroutines) don't work in go if you're not calling from an main, so anytime you call a custom export then try to use a goroutine you'll get panics. 10x size is about the blowup we see as well. It's also likely to be slower (some of the Tinygo authors said ~20% slowdown compared to tinygo) probably due to the simpler/smaller runtime and LLVM being better at optimizing.
- Seb-C 3y ago
  The only time I tried wasm in Go, the wasm compiled by the native Go was so slow that the equivalent Javascript was faster. Tinygo produced decent performance however.
jbrandhorst 3y ago
Exports are something we'd like to work on but it turns out it's pretty complicated to reconcile the Go runtime with the WebAssembly environment, especially when there's only a single thread. We'll get to exports as soon as we can but it may require Wasm threads to be stable first.
- dilyevsky 3y ago
  Just curious what state is it (thread support) in now? I saw wasmtime already supporting some pthread style threads so assumed proposal has already been accepted but it’s super hard to actually figure out what state anything is in with wasm…
  - beanjuiceII 3y ago
    I would like to second that last statement. If anyone knows a good place to keep up with it all I'd appreciate it
    - cplli 3y ago
      Threads are Phase 3 https://github.com/WebAssembly/proposals https://github.com/WebAssembly/proposals You can also check out: https://webassembly.org/roadmap/ https://webassembly.org/roadmap/ And for Go, the proposal project on Github has many interesting conversations from the devs. And as a reminder to anyone interested in using Go WASM, it’s experimental and does not come with the same compatibility promise as Go itself: https://github.com/golang/go/wiki/WebAssembly https://github.com/golang/go/wiki/WebAssembly
      - dilyevsky 3y ago
        Yes it's been in phase 3 for what like 2-3 years at this point (judging by when it landed in browsers)? No eta and no next steps. The tp says they are waiting until "it's stable" so I'm assuming phase 4. It qualifies browser support and "at least one toolchain" criteria[0] (zig) and seems like all the other conditions too except maybe "CG consensus" whatever that means, so for all I know it could take anywhere between tomorrow and in a few years from now... [0] https://github.com/WebAssembly/meetings/blob/main/process/phases.md#4-standardize-the-feature-working-group https://github.com/WebAssembly/meetings/blob/main/process/ph...

jsd1982 3y ago

The go-compiled wasm is also extremely slow compared to tinygo's wasm. Doing simple things like `fmt.Printf()` degraded performance significantly.

alecthomas 3y ago
I wonder if fmt.Printf() in particular is slow due to the CGo transition? Assuming there even is a CGo transition when compiled to WASM...
- jbrandhorst 3y ago
  There's no CGO involved when compiling to Wasm. The sometimes slow performance is due to the hoops the compiled code has to jump through to support the Go runtime and goroutine preemption on a single thread.
  - alecthomas 3y ago
    I understand there's no CGo specifically, but I'm wondering if the Go runtime when running under WASM still has to manage switching out the goroutine stacks for "WASM stacks" when it's calling out through the WASM VM. Edit edit: from this comment it sounds like it is, as you say, just the general overhead of managing goroutine stacks. I wonder if TinyGo is more performant. [1] https://news.ycombinator.com/item?id=37501552 https://news.ycombinator.com/item?id=37501552
    - Patrickmi 3y ago
      Tinygo runtime don’t have g or m threads that’s why it’s Cgo is zero cost

viccuad 3y ago

I'm also waiting for that :) See https://github.com/golang/go/issues/42372 https://github.com/golang/go/issues/42372

dilyevsky 3y ago
Yeah there is an escape hatch via js package but it’s annoying

rockwotj 3y ago

FWIW we simulate exports by instead having `main` call an imported function that blocks until it's ready to return with the needed data. So instead of: `host -> call foo on guest -> return to host` `host -> call guest main -> call foo on host -> host returns when ready -> guest calls foo when done` FWIW the scheduler (so goroutines) don't work in go if you're not calling from an main, so anytime you call a custom export then try to use a goroutine you'll get panics. 10x size is about the blowup we see as well. It's also likely to be slower (some of the Tinygo authors said ~20% slowdown compared to tinygo) probably due to the simpler/smaller runtime and LLVM being better at optimizing.

Seb-C 3y ago
The only time I tried wasm in Go, the wasm compiled by the native Go was so slow that the equivalent Javascript was faster. Tinygo produced decent performance however.

jbrandhorst 3y ago

Exports are something we'd like to work on but it turns out it's pretty complicated to reconcile the Go runtime with the WebAssembly environment, especially when there's only a single thread. We'll get to exports as soon as we can but it may require Wasm threads to be stable first.

dilyevsky 3y ago
Just curious what state is it (thread support) in now? I saw wasmtime already supporting some pthread style threads so assumed proposal has already been accepted but it’s super hard to actually figure out what state anything is in with wasm…
- beanjuiceII 3y ago
  I would like to second that last statement. If anyone knows a good place to keep up with it all I'd appreciate it
  - cplli 3y ago
    Threads are Phase 3 https://github.com/WebAssembly/proposals https://github.com/WebAssembly/proposals You can also check out: https://webassembly.org/roadmap/ https://webassembly.org/roadmap/ And for Go, the proposal project on Github has many interesting conversations from the devs. And as a reminder to anyone interested in using Go WASM, it’s experimental and does not come with the same compatibility promise as Go itself: https://github.com/golang/go/wiki/WebAssembly https://github.com/golang/go/wiki/WebAssembly
    - dilyevsky 3y ago
      Yes it's been in phase 3 for what like 2-3 years at this point (judging by when it landed in browsers)? No eta and no next steps. The tp says they are waiting until "it's stable" so I'm assuming phase 4. It qualifies browser support and "at least one toolchain" criteria[0] (zig) and seems like all the other conditions too except maybe "CG consensus" whatever that means, so for all I know it could take anywhere between tomorrow and in a few years from now... [0] https://github.com/WebAssembly/meetings/blob/main/process/phases.md#4-standardize-the-feature-working-group https://github.com/WebAssembly/meetings/blob/main/process/ph...