Thread overview
D WebAssembly working differently than C++, Zig
May 16, 2022
Allen Garvey
May 16, 2022
Adam D Ruppe
May 16, 2022
Allen Garvey
May 16, 2022
kinke
May 16, 2022
Allen Garvey
May 17, 2022
Adam D Ruppe
May 17, 2022
Siarhei Siamashka
May 17, 2022
Adam D Ruppe
May 17, 2022
Sergey
May 17, 2022
Tejas
May 16, 2022

I'm working on a comparison of WebAssembly performance for error propagation dithering using D, C++ and Zig. So far C++ and Zig work as expected, but for D, despite using the same algorithm and similar code the output is different.

You can see the differences here https://wasm-error-propagation-dither-comparison.netlify.app/ by opening an image.

Code

Any help would be appreciated. From my extensive debugging it seems that calculating the pixel lightness is working correctly, it has something to do with either saving or retrieving the stored error in the float arrays.

May 16, 2022
I would suspect it is something to do with your memset... even if it needs to take the int (wtf but ldc is weird) you might want to reinterpret cast it to float to avoid any extra conversions.
May 16, 2022

The problem is the memset signature. You assume the length is the number of floats, while it's the number of bytes to be set to the specified value. https://en.cppreference.com/w/c/string/byte/memset

May 16, 2022
On Monday, 16 May 2022 at 18:05:00 UTC, Adam D Ruppe wrote:
> I would suspect it is something to do with your memset... even if it needs to take the int (wtf but ldc is weird) you might want to reinterpret cast it to float to avoid any extra conversions.

I was thinking memset might be the case, but I tried changing it to ignore the int value and just hard-coding 0 and the result was the same.
May 16, 2022

On Monday, 16 May 2022 at 18:14:13 UTC, kinke wrote:

>

The problem is the memset signature. You assume the length is the number of floats, while it's the number of bytes to be set to the specified value. https://en.cppreference.com/w/c/string/byte/memset

Thanks so much, that fixed the problem! You have no idea have long I have spent trying to debug this!

May 17, 2022

On Monday, 16 May 2022 at 17:32:20 UTC, Allen Garvey wrote:

>

I'm working on a comparison of WebAssembly performance for error propagation dithering using D, C++ and Zig. So far C++ and Zig work as expected, but for D, despite using the same algorithm and similar code the output is different.

Hm D version is the slowest one?!

May 17, 2022

On Tuesday, 17 May 2022 at 09:38:31 UTC, Sergey wrote:

>

On Monday, 16 May 2022 at 17:32:20 UTC, Allen Garvey wrote:

>

I'm working on a comparison of WebAssembly performance for error propagation dithering using D, C++ and Zig. So far C++ and Zig work as expected, but for D, despite using the same algorithm and similar code the output is different.

Hm D version is the slowest one?!

It's faster than the JS version atleast. But yeah, C++ and Zig being 30+% faster than the D solution doesn't look good on us :(

May 17, 2022
On Monday, 16 May 2022 at 18:17:03 UTC, Allen Garvey wrote:
> Thanks so much, that fixed the problem! You have no idea have long I have spent trying to debug this!

Oh I should have checked my impl, where I did all this already!

https://github.com/adamdruppe/webassembly/blob/master/arsd-webassembly/object.d#L263


And also might be able to just have the function forward to the ldc intrinsic:

https://github.com/ldc-developers/druntime/blob/ldc/src/ldc/intrinsics.di#L160

might help speed up a lil too, i don't know though (I didn't do it here for me)
May 17, 2022

On Tuesday, 17 May 2022 at 11:36:21 UTC, Adam D Ruppe wrote:

>

Oh I should have checked my impl, where I did all this already!

https://github.com/adamdruppe/webassembly/blob/master/arsd-webassembly/object.d#L263

Looks like you forgot to increment the pointer and need "*d++ = cast(ubyte) c;" there. And filling the buffer one byte at a time is likely slow.

May 17, 2022
On Tuesday, 17 May 2022 at 11:43:45 UTC, Siarhei Siamashka wrote:
> Looks like you forgot to increment the pointer and need "*d++ = cast(ubyte) c;" there.


hahaha yup.

> And filling the buffer one byte at a time is likely slow.

prolly but meh, that's where the intrinsics are nice.