golang + wasm three times slower than javascript?

[netbrain]

So been playing around with go and wasm support on go version devel +479da24aac Fri Aug 10 00:47:31 2018 +0000 linux/amd64

Curious on performance i tried implementing a Fibonacci algorithm function in JS and compared it to it's equivalent in GO. Calculating fib(44) takes 11 seconds on my machine in JS and in GO it takes 36 seconds.

Any idea's to why I would get these results? I know wasm is very much an experimental feature of go, however I expected at least equal to or better performance than JS. Are there any browser optimizations which is running in my JS code which may not be in effect in wasm?

Test code available at https://github.com/netbrain/kata/tree/master/go/wasm

Cheers

Kim

[jucie....@zanthus.com.br]

As far as I know, Go is the very first garbage collected language to support WebAssembly. That is very important.
Remember the old motto: "first make it work, then make it right, and, finally, make it fast."
It is just natural that things will be improved in future releases, as always has been the case with Go.

Richard Musiol, from Germany, made at least 2 wonderful contributions to the Go ecosystem:
1. GopherJS - a Go compiler that generates JavaScript, supporting nearly the entire standard library, with goroutines, channels, etc.
2. WebAssembly code generation for the official Go toolkit.

While other communities will begin the effort to support WebAssembly, Richard and friends has already done the job for us to leverage this opportunity.

I want to send a big "THANK YOU" to Richard and everybody involved.

[peterGo]

Kim,

These are not useful results. Exponential recursive algorithms are known to be very expensive. Use an iterative algorithm.

See Fibonacci Numbers and Binomial Coefficients: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.137.752&rep=rep1&type=pdf

For example,

$ go version
go version devel +9ef5ee911c Tue Aug 7 14:36:14 2018 +0000 linux/amd64

$ go test fib_test.go -bench=.
goos: linux
goarch: amd64
BenchmarkRecursive-4              1    4617595761 ns/op
BenchmarkIterative-4       50000000            28.2 ns/op

Code: https://play.golang.org/p/zyXqNt3knAM

What results do you get with an iterative algorithm?

Peter

[Space A.]

Hi Kim,

check this out: https://medium.com/gopherjs/surprises-in-gopherjs-performance-4a0a49b04ecd

You will find some comparison of native Go vs C vs GopherJS (and JS itself, in general), with surprisingly "fast" JS* and "slow" Go. However the reason is not that obvious...

Regards

пятница, 10 августа 2018 г., 13:28:01 UTC+3 пользователь netbrain написал:

[Agniva De Sarker]

>  however I expected at least equal to or better performance than JS.

Hi,

Unfortunately, this expectation is incorrect. Wasm is NOT guaranteed to give you better or at least equal performance to javascript. This is even in the general case when you run wasm using emcc. The performance is very dependant on what you are running and on which browser (sometimes even browser versions matter). 

Take a look at this to see how does the performance vary - https://takahirox.github.io/WebAssembly-benchmark/.

Coming to Go, 1.11 will just have experimental support. We are just focusing on correctness as of now. Also, there are couple of issues in the wasm spec itself which impediments a language like Go which needs to unwind and restore the call stack when switching between goroutines. This is only related to Go though. But even in the general case, wasm performance is not always better than javascript. WebAssembly is not a silver bullet.

-Agniva