On Sat, Jun 3, 2023 at 9:11 AM 'Dieter Weidenbrück' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:
> All,
> I think I have found the problem and a workaround. First, I got everything
> working using pthreads without problems. However, I wasn't too impressed
> with the time savings vs. single thread. So I went back and did some more
> debugging on the wasm workers.
> Using the flags -sMALLOC=emmalloc -sWASM_WORKERS , no sanitizer, no
> safe-heap, I stepped into the realloc routine of emmalloc. All goes well
> there if the existing ptr can be enlarged, however, if a new ptr is
> allocated, there is a problem sometimes. The new ptr gets allocated, but
> the memcpy goes wrong, as it looks. memcpy is not a part of emmalloc, of
> course.
> So I changed my central resizing routine to allocate a new block and copy
> the content myself:
>
> Error_T setMemPtrSize(MemPtr_T *p,uint32_T size){
> _MemPtr_T m = _MP(*p),mNew;
> MemPtr_T newPtr;
> uint32_T n;
> Error_T err = kErr_NoErr;
>
> LOCK_ACQUIRE();
> //newPtr = realloc(m,size + sizeof(_Mem_T));
>
> newPtr = (MemPtr_T)calloc(1,size + sizeof(_Mem_T));
> if (newPtr != NULLPTR) {
> mNew = (_MemPtr_T)newPtr;
> n = min(m->size,size) + sizeof(_Mem_T);
> memcpy(newPtr,m,n);
> free(m);
> mNew->size = size;
> *p = (MemPtr_T)((char_T*)mNew + sizeof(_Mem_T));
> }
> else
> err = kErr_MemErr;
> LOCK_RELEASE();
> ASSERT_LOCK_IS_NOT_ACQUIRED();
> return err;
> }
> I can not say what exactly goes wrong, because it is quite cumbersome to
> debug without have access to all the details. However, with this change,
> everything works beautifully now. Tested with both malloc and emmalloc,
> with different numbers of workers between 1 and 20, different file sizes up
> to 350 MB, and with both debug and release settings.
>
> Some times for processing the largest file:
> pthreads: between 489.537000 and 521.209450 secs in debug mode (using
> queues) using 10 threads
> wasm workers: in debug mode: 59.942190 secs using 10 workers, 54.108360
> secs using 20 workers
> wasm workers in release mode: 21.243100 secs using 10 workers, 19.642640
> secs using 20 workers
> single-thread: 50.066905 secs in release mode
>
>
Your results for pthreads look rather odd, so something strange must be
going on. In terms of performance there should be very little difference
between wasm workers and pthreads if you implement the same algorithm since
they are both based on the same shared memory primitives. Most of the
differences are related to the code size.
> Thanks for all your comments, they helped a lot.
> Best, Dieter
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/45762a6f-ea22-4149-a95b-6d882975fcf6n%40googlegroups.com
> <https://groups.google.com/d/msgid/emscripten-discuss/45762a6f-ea22-4149-a95b-6d882975fcf6n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/emscripten-discuss/CAL_va298VxCHpJx%3DoVtMK_ieEcoopqQohFJnGXtL%3Dc7sCJ5L%3DQ%40mail.gmail.com.
