I said that, but then I read your message about the native optimizer being disabled with -g4. 1.29 (non-native optimizer?) is definitely generating less .bc output than 1.27, and that makes a sizable speedup in the link and memory use. I am assuming STL/iostream in C++11 must be the bloating factor here, but I don't have a specific breakdown yet. I think I tried with g2 and g4, and the size of the bc files wasn't considerably different. I'm still not seeing @line directives survive the link, so I may not be seeing the full impact of debug info.
On Monday, February 9, 2015 at 11:26:38 AM UTC-8, Alon Zakai wrote: > > I can imagine that 500MB of bc takes 4 times as much RAM - there is more > structure and waste when processing it in memory. But, 500MB of bc is huge! > I assume most of that size is removed when not including debug info? This > is a known issue with LLVM. > > Nice to see the native optimizer helping here. > > - Alon > > > On Wed, Feb 4, 2015 at 11:31 PM, Alecazam <[email protected] <javascript:>> > wrote: > >> This appears to be an artifact of 1.27 vs 1.29. Alon, does it seem >> reasonable that linking 500MB of bc files needs 2GB of memory to link? >> It's certainly better than the 10x multiplier without the native >> optimizer. This is with -g4 on the command line in both cases. >> >> 1.29 >> 2.2GB llvm-link >> 1.3GB opt >> Link 1m 51s >> BC Files 483MB >> >> 1.27 >> 8.6GB llvm-link >> 4.2GB opt >> Link 4m 23s >> BC Files - 681MB >> >> On Wednesday, February 4, 2015 at 4:37:35 PM UTC-8, Alon Zakai wrote: >>> >>> I used -g on compile, -g4 on link (-g4 during compile would be the >>> same), and I verified I could see the generated source map at the end. >>> >>> Your app must be hitting something that i can't see on bullet, that is, >>> something must be different in your project. Going from 23 seconds to over >>> 4 minutes means something is going very wrong. Perhaps profiling the stages >>> that take a long time (llvm-link and opt?) could show something, just a >>> guess. >>> >>> - Alon >>> >>> >>> On Tue, Feb 3, 2015 at 5:12 PM, Alecazam <[email protected]> wrote: >>> >>>> Hmm. Did you look at Bullet memory use in Activity Monitor? You >>>> might need a library with more C++11 in it (STL?). It's unclear from the >>>> build suggestions as to whether you put -g4 on both the command and link >>>> lines (I do both). The directions say to use -g on compile, and -g4 on >>>> the >>>> link. I don't think I have that specificity in my build scripts, but I >>>> wonder if it could be from setting in on both. I also have -O2 >>>> --llvm-opts 2 --llvm-lto 0 on the compile lines as well. Something is >>>> generating a ton of source to the link phase to accumulate 9GB. opt then >>>> sees the results of that with around 5GB. >>>> >>>> 4m15s link with -g4 set. High memory use reported for llvm-link and >>>> opt. >>>> 23s link with -g2 and -g3 set. I don't see the high memory use with >>>> either of these. >>>> >>>> -- >>>> 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] <javascript:>. >> 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.
