On Sun, Sep 25, 2022 at 3:21 PM Mark Sibly <[email protected]> wrote:
> After playing around with -pthread for a (very) short time, I don't think > it's generally a good idea to use -pthread only when compiling, as I'm > guessing it causes the compiler to generate code that depends on symbols > that can only be resolved by also linking with -pthread, so depending on > what you #include you may or may not get a bunch of missing symbols at link > time. > > I think I'm OK with the overhead of -pthread at the source level (eg: > adding locks to ref counts etc?) I guess what I'm really worried about is > how much overhead a -pthread app will incur at runtime even if it doesn't > create any threads. I vaguely remember hearing that web workers effectively > 'forked' the entire process and am a bit worried that pthreads may do the > same, even though it now seems like they shouldn't have to, given that the > HEAP is now shared and CODE is read-only in wasm world. And the > -sTHREAD_POOL_SIZE (I think) option implies to me emscripten is > preallocating workers/threads which is a waste IMO if they are actually > processes and my app never needs any of them! Maybe -sTHREAD_POOL_SIZE=0 > could be used to indicate 'don't preallocate any workers' or something? > Maybe it already does? > > Indeed, the default for THREAD_POOL_SIZE is zero which means no workers will be created until you call pthread_create. Gotta say though that the state of threads in Emscripten is way past when I > last tried to use them a couple of years back! However, I do feel like the > docs are lacking a bit. In particular, I feel like there should be a page > for covering emscripten/threading.h that may be missing? Or can I just not > find it? This file contains the hugely useful MAIN_THREAD_EM_ASM*() and > MAIN_THREAD_ASYNC_EM_ASM() APIs (and I'm guessing is basically what gets > imported when linking with -pthread), and it's only because these are > briefly mentioned on the Wasm Workers API page I discovered they existed at > all! However, for what I'm doing they were the last piece in the puzzle > that let me add full thread support to the wasm version of my project, very > cool! > > Bye, > Mark > > On Thu, Sep 22, 2022 at 4:08 PM 'Thomas Lively' via emscripten-discuss < > [email protected]> wrote: > >> Hi Mark, >> >> If you do that, the output will be roughly the same, but any atomic >> accesses you have would still use the atomic instructions. My understanding >> is that V8 at least uses the same codegen for atomic instructions no matter >> whether the memory is shared or not, so those atomic accesses would be >> slower than normal loads and stores. In principle V8 could optimize to use >> non-atomic loads and stores in this case, but I don't think it does. >> Compiling with threads enabled might also inhibit some optimizations around >> those atomic accesses that LLVM would have been able to do otherwise. >> >> If you do end up trying this out, I would be very curious to hear what >> the overhead ends up being. >> >> Best, >> >> Thomas >> >> On Wed, Sep 21, 2022 at 7:23 PM Mark Sibly <[email protected]> wrote: >> >>> Hi, >>> >>> Does anyone have any idea what the overhead of using the -pthread >>> compiler option is? >>> >>> If I'm writing a simple single thread app, is it OK to just leave this >>> on for all compilation units, but link the final exe without either >>> -pthread or -sPTHREAD_POOL_SIZE? Would this give roughly the same >>> output as compiling everything without -pthread? >>> >>> Bye! >>> Mark >>> >>> >>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/emscripten-discuss/40ce5767-d11d-4e7e-b44a-247137524b57n%40googlegroups.com >>> <https://groups.google.com/d/msgid/emscripten-discuss/40ce5767-d11d-4e7e-b44a-247137524b57n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "emscripten-discuss" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/emscripten-discuss/kFbIbXAGVd0/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EWKYUgXAfOXFBYLFG384ciWN_DFjDmP%2B0MvtETrkWHrHA%40mail.gmail.com >> <https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EWKYUgXAfOXFBYLFG384ciWN_DFjDmP%2B0MvtETrkWHrHA%40mail.gmail.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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/CAK32ozj8H7tvHLUU9Gv9LTMwd9z2QER_eDYqhf%3D5_EzNndMTZw%40mail.gmail.com > <https://groups.google.com/d/msgid/emscripten-discuss/CAK32ozj8H7tvHLUU9Gv9LTMwd9z2QER_eDYqhf%3D5_EzNndMTZw%40mail.gmail.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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2_mfR5dXB82YVN9zmj_4m74UqWoD5hFqoRFzZUQgMJSYw%40mail.gmail.com.
