...hm ok I did a quick check on my 8-bit emulators, and I have to agree. I'm seeing about 10% size agree for the generated WASM (which I'd be willing to eat if the performance would improve too), but performance isn't any noticeably better. I guess the WASM runtimes either do the inlining themselves, or can the function call overhead doesn't matter as much as it used to.
On Friday, 28 February 2020 12:16:39 UTC+1, Floh wrote: > > When I last tested I generally saw quite noticeable improvements for > inlined code (which LTO does across compilation units). Most of my code is > straight C without inline functions in headers. I guess this scenario > benefits more from LTO than typical C++ code where usually a lot of > implementation code sits in inline/template functions (at the cost of > increasing compile time for each compilation unit, versus increasing > link-time once for LTO). > > I think it depends extremely on the code base at hand whether LTO is > useful or not :) > > On Friday, 28 February 2020 11:32:09 UTC+1, Gabriel CV wrote: >> >> Glad to! >> >> By the way, I don't find that LTO brings any performance improvements >> compared to a non-LTO builds (on latests Emscripten backend). Maybe +1% at >> most (more probably benchmark noise to me), but sometime more than 10% >> worse, and at the expense of a *significant *link time increase and >> *significant >> *binary size increase! >> >> So I am not sure this is really an interesting option anymore... >> >> >> Le 28/02/2020 à 11:14, Floh a écrit : >> >> Whoops, thanks for making me aware of WASM_OBJECT_FILES being 1 by >> default... I've been building with LTO all the time (since the asm.js days) >> and was expecting that the WASM backend would behave identically there. >> >> -Floh. >> >> On Friday, 28 February 2020 10:07:11 UTC+1, Gabriel CV wrote: >>> >>> Hi, >>> >>> Try to remove --llvm-lto 3, as it might increase binary size >>> significantly when combined with -O2 or -O3 (and I am not sure it is very >>> usefull without using -DWASM_OBJECT_FILES=0) >>> Le 28/02/2020 à 08:12, Rohit Saini a écrit : >>> >>> Hi All, >>> >>> Previously we were using 1.38.28 emscripten version. Recently we updated >>> to latest llvm backend 1.39.7. But with new backend there is drastic >>> increase in wasm size. Size of my side modules become almost double and >>> size of my main module also increased from 2.7mb to almost 4mb. Firstly we >>> are compiling to object files then we are linking them to make wasm. Below >>> are the flags I am passing while compiling and linking. Is this size >>> increase intentional or do I have to change compiling or linking flags >>> someway. >>> >>> Compiling flags for main module: >>> -Oz -fPIC >>> -s DISABLE_EXCEPTION_CATCHING=0 -Wno-builtin-macro-redefined >>> -Wno-dollar-in-identifier-extension >>> >>> Compiling flags for side module: >>> -std=c++14 -fPIC >>> >>> Linking flags for main module: >>> >>> -O3 -s EVAL_CTORS=0 --closure 0 -s ALIASING_FUNCTION_POINTERS=0 -s >>> ELIMINATE_DUPLICATE_FUNCTIONS=1 -s ELIMINATE_DUPLICATE_FUNCTIONS_PASSES=12 >>> --llvm-lto 3 -s FORCE_FILESYSTEM=1 -s ERROR_ON_UNDEFINED_SYMBOLS=0 -s >>> 'EXTRA_EXPORTED_RUNTIME_METHODS=["getTempRet0","setTempRet0", "cwrap"]' -s >>> [email protected] >>> -s DISABLE_EXCEPTION_CATCHING=2 -s >>> [email protected] >>> >>> Linking flags for side module: >>> -s SIDE_MODULE=1 -s WASM=1 -Oz -s EVAL_CTORS=0 --closure 0 -s >>> ALIASING_FUNCTION_POINTERS=0 -s ELIMINATE_DUPLICATE_FUNCTIONS=1 -s >>> ELIMINATE_DUPLICATE_FUNCTIONS_PASSES=12 --llvm-lto 3 -s >>> ERROR_ON_UNDEFINED_SYMBOLS=0 >>> -- >>> 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/5f30a113-7203-4eba-9426-9f626c51ec26%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/emscripten-discuss/5f30a113-7203-4eba-9426-9f626c51ec26%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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/emscripten-discuss/e8a9f44f-a8f5-46f2-b440-e2356f285d28%40googlegroups.com >> >> <https://groups.google.com/d/msgid/emscripten-discuss/e8a9f44f-a8f5-46f2-b440-e2356f285d28%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/38cfb2aa-6b9c-4dfb-a978-1c9c520d3693%40googlegroups.com.
