Thanks Alon, I have verified that Emscripten indeed picks up my own implementation of the vector instead of the STL when it is able to find the former.
On Thu, Jul 24, 2014 at 11:29 AM, Alon Zakai <[email protected]> wrote: > As mentioned above, if you link with your own implementation of the STL, > emscripten will not link in the emscripten STL (libc++). It only links it if > it sees it is needed. But if you want to forcefully disable linking of the > STL, on the incoming branch you can use > > EMCC_FORCE_STDLIBS=libc,libcextra,libcxxabi,gl EMCC_ONLY_FORCED_STDLIBS=1 > emcc [..] > > which forces the linker to use those stdlibs (can remove gl for example, if > not using opengl) and no others. > > - Alon > > > > On Wed, Jul 23, 2014 at 7:09 PM, Kevin Cheung <[email protected]> wrote: >> >> Thanks for your reply Alon. Unfortunately, I am inheriting some legacy >> code which I do not hope to touch, so is it possible to still keep the >> code that references a vector intact e.g.: >> >> #include <vector> >> >> int main() >> { >> std::vector<int> a; >> a.push_back(5); >> } >> >> but force Emscripten to not link with STL (perhaps thru a compiler >> setting) and at the same time, put in my own Vector implementation? >> >> On Thu, Jul 24, 2014 at 2:45 AM, Alon Zakai <[email protected]> wrote: >> > If you use STL things and the linker sees unresolved symbols, then STL >> > will >> > be linked for you. If you implement yourself parts of STL, then there >> > will >> > be no unresolved symbols and it should not include STL. >> > >> > - Alon >> > >> > >> > >> > On Wed, Jul 23, 2014 at 3:19 AM, Kevin Cheung <[email protected]> >> > wrote: >> >> >> >> Thanks for the link, I will check out tools/find_bigfuncs.py when I >> >> have the time. >> >> >> >> Just to bring out my previous question in case it got lost in the >> >> thread: >> >> >> >> I am currently trying to port some legacy code which uses only a few >> >> STL containers such as vectors and maps. Is there a way for me to not >> >> build STL with the generated JS and replace the vector and map classes >> >> with my own implementation without touching the legacy code? Such as >> >> thru DEFAULT_LIBRARY_FUNCS_TO_INCLUDE for e.g.? >> >> >> >> On Wed, Jul 23, 2014 at 12:25 AM, Jukka Jylänki <[email protected]> >> >> wrote: >> >> > Just for cross-referencing, >> >> > https://github.com/kripken/emscripten/issues/2527 would help >> >> > immensely >> >> > here >> >> > in tracking what causes big output sizes and why, although we don't >> >> > currently have anyone working on such a tool. >> >> > >> >> > >> >> > 2014-07-22 18:43 GMT+03:00 Floh <[email protected]>: >> >> > >> >> >> Hmm, LTO might also increase code size because it inlines more stuff >> >> >> (but >> >> >> I found that this inlining is quite important for performance), on >> >> >> the >> >> >> other >> >> >> hand it should a do pretty aggressive dead-code elimination. >> >> >> >> >> >> Not sure if this helps in your case, but I'm currently compiling >> >> >> like >> >> >> this: >> >> >> >> >> >> Object files: -Oz >> >> >> Linker Stage : -Oz --llvm-lto 3 --closure 1 >> >> >> >> >> >> (plus some other stuff which shouldn't be relevant for size or >> >> >> performance). >> >> >> >> >> >> I've used -O2 before, and may decide to switch back depending on >> >> >> performance tests I'm doing from time to time. >> >> >> >> >> >> >> >> >> Am Dienstag, 22. Juli 2014 12:55:01 UTC+2 schrieb awt: >> >> >>> >> >> >>> Thanks Floh and Alon for your detailed replies. Really appreciate >> >> >>> it. >> >> >>> >> >> >>> I tried to use both --llvm-opts and --llvm-lto but interestingly, >> >> >>> the >> >> >>> size of the JS increased from 2202kb to 2328kb. These are my build >> >> >>> parameters: >> >> >>> >> >> >>> emcc vector.cpp -o hello.html --llvm-opts 3 --llvm-lto 1 >> >> >>> >> >> >>> Is there something wrong with the way that I am using the >> >> >>> parameters >> >> >>> above? I could use -Oz and -profiling because that would still give >> >> >>> me >> >> >>> debuggable code but just want to clarify if the -Oz optimization >> >> >>> already >> >> >>> includes --llvm-lto? >> >> >>> >> >> >>> I am currently trying to port some legacy code which uses a only >> >> >>> few >> >> >>> STL >> >> >>> containers such as vectors and maps. Is there a way for me to not >> >> >>> build STL >> >> >>> with the generated JS and replace the vector and map classes with >> >> >>> my >> >> >>> own >> >> >>> implementation without touching the legacy code? Such as thru >> >> >>> DEFAULT_LIBRARY_FUNCS_TO_INCLUDE for e.g.? >> >> >>> >> >> >>> >> >> >>> >> >> >>> On Tuesday, July 22, 2014 6:51:53 AM UTC+8, Alon Zakai wrote: >> >> >>>> >> >> >>>> std::vector causes emscripten to pull in libc++, a full >> >> >>>> implementation >> >> >>>> of the C++ standard library. It then tries to strip out code it >> >> >>>> can >> >> >>>> prove is >> >> >>>> not used, but in practice just including std::vector is enough to >> >> >>>> keep quite >> >> >>>> a bit alive. std::iostream is worse. >> >> >>>> >> >> >>>> Building with LTO may decrease the size somewhat (--llvm-lto 1). >> >> >>>> >> >> >>>> - Alon >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> On Mon, Jul 21, 2014 at 2:59 AM, awt <[email protected]> wrote: >> >> >>>>> >> >> >>>>> Hi, >> >> >>>>> >> >> >>>>> I wrote 2 simple programs to compare the size of the Javascript >> >> >>>>> files >> >> >>>>> generated in unoptimized mode for both array and vector: >> >> >>>>> >> >> >>>>> 1. Array version: >> >> >>>>> >> >> >>>>> int main() >> >> >>>>> { >> >> >>>>> int arr1[2000]; >> >> >>>>> add(arr1); >> >> >>>>> return 0; >> >> >>>>> } >> >> >>>>> >> >> >>>>> void add(int arr[]) >> >> >>>>> { >> >> >>>>> for(int i=0;i<2000;i++) >> >> >>>>> { >> >> >>>>> arr[i]=i; >> >> >>>>> } >> >> >>>>> } >> >> >>>>> >> >> >>>>> 2. Vector version: >> >> >>>>> >> >> >>>>> int main() >> >> >>>>> { >> >> >>>>> vector<int> v1; >> >> >>>>> add(v1); >> >> >>>>> return 0; >> >> >>>>> } >> >> >>>>> >> >> >>>>> void add(vector<int>& v) >> >> >>>>> { >> >> >>>>> for(int i=0;i<2000;i++) >> >> >>>>> { >> >> >>>>> v.push_back(i); >> >> >>>>> } >> >> >>>>> } >> >> >>>>> >> >> >>>>> I was quite surprised that the size of the JS file generated for >> >> >>>>> the >> >> >>>>> array is only 203KB but the vector version took up 2393KB. Are >> >> >>>>> there >> >> >>>>> built-in optimizations for STL classes in Emscripten that I could >> >> >>>>> leverage >> >> >>>>> on to shrink the file size or do I have to implement my own >> >> >>>>> vector >> >> >>>>> classes? >> >> >>>>> Any suggestions would be much appreciated. Thanks in advance. >> >> >>>>> >> >> >>>>> -- >> >> >>>>> 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]. >> >> >>>>> For more options, visit https://groups.google.com/d/optout. >> >> >>>> >> >> >>>> >> >> >> -- >> >> >> 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]. >> >> >> For more options, visit https://groups.google.com/d/optout. >> >> > >> >> > >> >> > -- >> >> > 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/WTHJTJcsWPA/unsubscribe. >> >> > To unsubscribe from this group and all its topics, send an email to >> >> > [email protected]. >> >> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> >> >> >> -- >> >> In His grace, >> >> Kevin Cheung >> >> >> >> -- >> >> 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]. >> >> For more options, visit https://groups.google.com/d/optout. >> > >> > >> > -- >> > 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/WTHJTJcsWPA/unsubscribe. >> > To unsubscribe from this group and all its topics, send an email to >> > [email protected]. >> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> In His grace, >> Kevin Cheung >> >> -- >> 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]. >> For more options, visit https://groups.google.com/d/optout. > > > -- > 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/WTHJTJcsWPA/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. -- In His grace, Kevin Cheung -- 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]. For more options, visit https://groups.google.com/d/optout.
