Help with WASM performance

[Stephen Illingworth]

Hello,

I'm hoping for some help with a Go WASM project I am working on.

The project is based on another project of mine, which runs very well and I have no concerns about its performance. The WASM project however performs poorly. The help I need is to determine whether the performance of the WASM version can be improved.

I apologise in advance if this is an inappropriate topic for this mailing list, but I think it presents an interesting case study.


The main project is an Atari 2600 emulator and located on github: https://github.com/JetSetIlly/Gopher2600

The WASM project is also on Github: https://github.com/JetSetIlly/Gopher2600-Utils

The ebiten_test directory is the WASM project. It uses the core of the main project to load and display a running Atari ROM file. When compiled natively, this ebiten program performs well.

However the WASM targeted compilation of the same ebiten project is significantly slower. On my hardware, the comparative performance is more than 60 FPS for the native version and less than 10 FPS for the WASM version.


My questions are:

Is such a performance drop expected in a WASM project?

How can I analyse the performance of the WASM program? I have used Go profiling to identify bottlenecks but how do I do something similar for WASM?


As you can tell, I am all at sea when it comes to modern web development so any help and advice would be much appreciated.


Regards

Stephen

[Brian Candler]

What WASM runtime are you using to execute the code?

[Stephen Illingworth]

I have tried running it in Firefox and Chromium. The webserve.sh script in the ebiten_test folder runs a small httpd server to serve up the binary to the browser.

[Stephen Illingworth]

I've been thinking some more about this problem this week. I found the performance profiler in Chrome and can see that the each frame is taking longer than the required 16.7ms to create. The duration for each frame is more like 100ms. The native performance meanwhile can reach about 7ms. I expected a drop in performance but not that much.

If anyone can offer any insight or if these figures seem wrong then I'd love to take some advice.

Regards

Stephen

[Robert Engels]

When you say negative performance are you talking about a native app running directly on the hardware what are you referring to exactly

On Sep 22, 2023, at 1:03 PM, Stephen Illingworth <stephen.i...@gmail.com> wrote:



--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/d8926ffb-9ca3-48ac-aabc-76a8a43947dan%40googlegroups.com.

[Stephen Illingworth]

I'm comparing the results of a program compiled for AMD64 and WASM architectures. The code is the same except for the change of architecture. The size of the difference in performance is unexpected to me but maybe it's normal.

[Robert Engels]

WASM goes through the browser - so it is very different. Are you using OpenGL or similar?

On Sep 22, 2023, at 3:44 PM, Stephen Illingworth <stephen.i...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1123a2da-3862-4da8-baf5-bc67dd2b7e6en%40googlegroups.com.

[Robert Engels]

Typically WASM performance is compared to JavaScript - ie. faster than JavaScript usually 1.5-10x. 

People don’t usually compare WASM with native apps. 

On Sep 22, 2023, at 7:04 PM, Robert Engels <ren...@ix.netcom.com> wrote:



[Stephen Illingworth]

Comparison to native speeds is the key attraction of WASM. From the go.org blog published 10 days ago: https://go.dev/blog/wasi

"WebAssembly (Wasm) is a binary instruction format originally designed for the web. It represents a standard that allows developers to run high-performance, low-level code directly in web browsers at near-native speeds."

And from the front page of webassembly.org

"The Wasm stack machine is designed to be encoded in a size- and load-time-efficient binary format. WebAssembly aims to execute at native speed by taking advantage of common hardware capabilities available on a wide range of platforms."

[TheDiveO]

The cynic in me notes the use of "aims".

IIRC is single-threaded, do you know if your code is single- threaded too, or does it use several core for decoding?

[Stephen Illingworth]

Heh. Yes, it is only an "aim" I suppose.

Yes. My code is single threaded. I note that threading will be added to the WASM spec in the near future so maybe there will be opportunity for me there when the change is added to the Go compiler.

I'll put this issue to rest for now and revisit it in a few months.

Thanks