Re: [go-nuts] Re: Help with WASM performance

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

Re: [go-nuts] Re: Help with WASM performance

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 wrote: > >  > WASM goes through the browser - so it is very different. Are you using OpenGL >

Re: [go-nuts] Re: Help with WASM performance

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 > wrote: > >  > I'm comparing the results of a program compiled for AMD64 and WASM > architectures. The code is the same except for the change of

Re: [go-nuts] Re: Help with WASM performance

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. On Friday, 22 September 2023 at 20:16:20 UTC+1 Robert Engels wrote:

Re: [go-nuts] panic: nil dereference in autogenerated hash function

On Fri, Sep 22, 2023 at 9:15 AM Shivaram Lingamneni wrote: > > I'm having difficulty understanding how this code could produce a nil > dereference, unless some runtime assumptions are being violated (maybe the > string pointer and length are out of sync due to a data race)? I agree: this looks

Re: [go-nuts] Re: Help with WASM performance

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 > wrote: > >  > I've been thinking some more about this problem this week. I found the > performance

[go-nuts] Re: Help with WASM performance

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

[go-nuts] panic: nil dereference in autogenerated hash function

I'm seeing the following panic on both Go 1.20.7 and Go 1.21.0 (amd64): panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x46e421] goroutine 368 [running]:

Re: [go-nuts] NTFS deduplicated files changed from regular to symlink in go 1.21

Thanks for reporting Simon. That change was intentional, intended to fix fix for https://github.com/golang/go/issues/42919. The commit description mentions the performance implications of the changes because it requires one more syscall to stating symlinks. Setting the ModeIrregular bit for

Re: [go-nuts] NTFS deduplicated files changed from regular to symlink in go 1.21

Our resident historian Jakob found that this isn't the first time we are running into ntfs deduplication issues, that already happened back in 2015 and might have relevant context around the question of "what's the expected behaviour for go std lib here": Go bug (resolved in 2017):