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

Comments

@lianghx-319
Copy link

@lianghx-319 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
Contributor

@cherrymui cherrymui commented Sep 24, 2020

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

@lianghx-319 lianghx-319 commented Sep 25, 2020

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 this to the Backlog milestone Sep 28, 2020
@neelance
Copy link
Member

@neelance neelance commented Oct 15, 2020

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

@neelance neelance commented Oct 27, 2020

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

@neelance neelance closed this Oct 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.