www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - D WebAssembly working differently than C++, Zig

reply Allen Garvey <allen.garvey gmail.com> writes:
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
* D 
https://github.com/allen-garvey/wasm-error-propagation-dither-comparison/blob/master/wasm/d/main.d
* C++ 
https://github.com/allen-garvey/wasm-error-propagation-dither-comparison/blob/master/wasm/cpp/main.cpp
* Zig 
https://github.com/allen-garvey/wasm-error-propagation-dither-comparison/blob/master/wasm/zig/main.zig

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
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
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
parent Allen Garvey <allen.garvey gmail.com> writes:
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
prev sibling next sibling parent reply kinke <noone nowhere.com> writes:
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
parent reply Allen Garvey <allen.garvey gmail.com> writes:
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 16 2022
parent reply Adam D Ruppe <destructionator gmail.com> writes:
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
parent reply Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
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
parent Adam D Ruppe <destructionator gmail.com> writes:
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.
May 17 2022
prev sibling parent reply Sergey <kornburn yandex.ru> writes:
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
parent Tejas <notrealemail gmail.com> writes:
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