Re: [go-nuts] Re: WASM Performance

2021-09-09 Thread Stephen Illingworth
Even when I remove all rendering and just run the Go WASM in a web worker, like this: const go = new Go(); WebAssembly.instantiateStreaming(fetch("web2600.wasm"), go.importObject).then((result) => { go.run(result.instance); }); The binary is still performing a long way

Re: [go-nuts] Re: WASM Performance

2021-09-07 Thread David Suarez
reading emails in reverse, apologies, may be similar to what I just sent.  Is it easy enough to try the request animation frame approach?  may help rule out an error in web worker code or approach if you emulate his flow to start, then start optimizing back to web worker if it solves

Re: [go-nuts] Re: WASM Performance

2021-09-07 Thread David Suarez
Did moving rendering to the browser side (just have the other side prep the data to be rendered) solve for the difference?  how much?  Did he do the same in the Doom article to get it to OK? On 09/07/2021 8:34 AM Stephen Illingworth wrote:

Re: [go-nuts] Re: WASM Performance

2021-09-07 Thread Stephen Illingworth
Yes. I'm seeing a 10x difference in speed too. So at least I know I'm not doing anything fundamentally wrong. It's a general problem at the moment. Thanks. On Tuesday, 7 September 2021 at 09:31:41 UTC+1 ma...@eliasnaur.com wrote: > In my experience (Gio projects), WASM is very slow compared to

Re: [go-nuts] Re: WASM Performance

2021-09-07 Thread ma...@eliasnaur.com
In my experience (Gio projects), WASM is very slow compared to native code; my investigations are part of #32591. You may find https://github.com/golang/go/issues/32591#issuecomment-517835565 relevant, because I cut out rendering to eliminate the JS<=>Go crossing overhead. It was a ~10x

Re: [go-nuts] Re: WASM Performance

2021-09-05 Thread Stephen Illingworth
(Links to screenshots) https://github.com/JetSetIlly/Gopher2600-Utils/blob/master/web2600/Doom_profile.png https://github.com/JetSetIlly/Gopher2600-Utils/blob/master/web2600/Web2600_profile.png On Sunday, 5 September 2021 at 15:13:32 UTC+1 Stephen Illingworth wrote: > Thanks for that, it was

Re: [go-nuts] Re: WASM Performance

2021-09-05 Thread Stephen Illingworth
Thanks for that, it was interesting reading. The problem he was describing in the Doom case seems to be have been caused by the WASM program taking up all the CPU time, meaning the browser itself is unresponsive. I've solved that by using a Web Worker. From what I understand

Re: [go-nuts] Re: WASM Performance

2021-09-05 Thread da...@suarezhouse.net
I had read an article that may be useful (format was different so may not be the same) --> https://github.com/diekmann/wasm-fizzbuzz (goes from basic WASM to Doom) The key thing in the Doom port that I recall was needed was to change the perspective of the owning thread (now the browser) so

Re: [go-nuts] Re: WASM Performance

2021-09-04 Thread Stephen Illingworth
I was hoping it was the rendering code that was the problem but I'm almost 100% certain that it isn't. If I just allow the emulation to run without drawing anything to the HTML canvas (and just writing a frame count to the console) the performance is still the same. Good tip about Ebiten

Fwd: [go-nuts] Re: WASM Performance

2021-09-04 Thread Stephen Illingworth
I was hoping it was the rendering code that was the problem but I'm almost 100% certain that it isn't. If I just allow the emulation to run without drawing anything to the HTML canvas (and just writing a frame count to the console) the performance is still the same. Good tip about Ebiten though.

Re: [go-nuts] Re: WASM Performance

2021-09-04 Thread Arnaud Delobelle
Hi Stephen, I haven't really looked at your code in detail but one obvious difference between your version and the original is the rendering code. Are you certain that the slowness is not confined to your rendering code (I have no reason to believe it is btw)? Here is a suggestion. I have had

Re: [go-nuts] Re: WASM Performance

2021-09-04 Thread Stephen Illingworth
I don't think I'm going to be able to make any progress with this. I chopped away enough code so that it compiles with TinyGo. It works but it's even slower. I was hoping to find a way of profiling the WASM code but I see DWARF support for WASM binaries is still a work in progress.

Re: [go-nuts] Re: WASM Performance

2021-09-03 Thread Stephen Illingworth
To follow up on this I should clarify what my questions are: 1) How much of a performance drop (when compared to AMD64 for example) should I expect when compiling to the WASM target? 2) Is there anything obvious I can do to counter any performance drops? And I suppose this is a non-Go question,

Re: [go-nuts] Re: WASM Performance

2021-09-03 Thread Stephen Illingworth
On Fri, Sep 3, 2021 at 10:15 AM Brian Candler wrote: > Could you explain a bit more about what you're comparing? > > - Is the wasm version running in a browser? If so, which one? Or have you > got a way to run wasm directly on the host (in which case, what is it)? > Running it in Firefox

[go-nuts] Re: WASM Performance

2021-09-03 Thread Brian Candler
Could you explain a bit more about what you're comparing? - Is the wasm version running in a browser? If so, which one? Or have you got a way to run wasm directly on the host (in which case, what is it)? - How is the linux/amd64 version running, if it's not talking to a DOM-type environment?