Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

misc/wasm: webassembly performance worse than JavaScript? #41599

Closed
lianghx-319 opened this issue Sep 24, 2020 · 4 comments
Closed

misc/wasm: webassembly performance worse than JavaScript? #41599

lianghx-319 opened this issue Sep 24, 2020 · 4 comments
Labels
arch-wasm WebAssembly issues FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@lianghx-319
Copy link

lianghx-319 commented Sep 24, 2020

What version of Go are you using (go version)?

$ go version
1.14.8

Does this issue reproduce with the latest release?

benchmark link

What operating system and processor architecture are you using (go env)?

go env Output
$ go env

macOS

test in chrome and firefox.

What did you do?

Fibonacci

Same code implement in C/C++, Golang and Javascript
image

SumInt

For some reason, I can't implement the same as C/C++ in Golang. It's very hard to pass an array to golang wasm, then get the element like slice. So I call js.Value.Index(i).Int() a lot.
image

What did you expect to see?

Are there someway to improve golang wasm performance?

@cherrymui
Copy link
Member

I briefly looked at the source code of the benchmarks. It seems the Go case does a lot more work than the JavaScript case. In each iteration, it invokes a callback from JS side, enters the Go runtime, which schedules a goroutine to run the function. It is much more than just computing a number, which is basically what the JS function does.

It is true that there is a non-trivial cost for calling from JS to Go. In practice, you may want to reduce the number of crosses, do as much work on one side as possible then cross to the other side and do as much work.

@lianghx-319
Copy link
Author

I briefly looked at the source code of the benchmarks. It seems the Go case does a lot more work than the JavaScript case. In each iteration, it invokes a callback from JS side, enters the Go runtime, which schedules a goroutine to run the function. It is much more than just computing a number, which is basically what the JS function does.

It is true that there is a non-trivial cost for calling from JS to Go. In practice, you may want to reduce the number of crosses, do as much work on one side as possible then cross to the other side and do as much work.

The fib case is almost the same as JS. But the sum case, I cannot find a better way to get a JS array in Golang.

@cagedmantis cagedmantis changed the title Golang Webassembly performance worse than JavaScript? misc/wasm: webassembly performance worse than JavaScript? Sep 28, 2020
@cagedmantis cagedmantis added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Sep 28, 2020
@cagedmantis cagedmantis added this to the Backlog milestone Sep 28, 2020
@cagedmantis cagedmantis added the arch-wasm WebAssembly issues label Sep 28, 2020
@neelance
Copy link
Member

fib case

This is probably due to the overhead of fib calling itself. This overhead is necessary to enable goroutines with webassembly. The proposal https://github.com/WebAssembly/funclets could improve this, but it has been stalled for a long time and I think it is unlikely that it will ever land. WebAssebly coroutines may be another solution, but I can't even find a proposal for them yet.

sum case:

As @cherrymui already said, using syscall/js to cross the boundary from Go to JS is slow. A better way to implement this would be to use a TypedArray, copy it to Go and then do the calculation.

@neelance
Copy link
Member

There is no specific improvement apparent at the moment. Closing.

@golang golang locked and limited conversation to collaborators Oct 27, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-wasm WebAssembly issues FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

5 participants