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 below
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 to
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:
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
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 differe
(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 i
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 requestAnimationFram
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 n
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 thoug
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. I
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 a
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.
https://git
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,
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 (78.13.
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? If
15 matches
Mail list logo
