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? 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.
