Thanks for testing - yeah, that seems likely, the speedup I expect would show up only on large projects.
On Wed, Aug 19, 2015 at 7:40 AM, Floh <[email protected]> wrote: > PS: may be it's interesting to know that linking these demo as native exes > in clang (for instance in Xcode) is basically instant, so may be the actual > llvm-linker time is so small in this case that the optimization doesn't > matter much). > > > Am Mittwoch, 19. August 2015 16:35:12 UTC+2 schrieb Floh: >> >> Hmm despite my best efforts to skew the results I don't see much >> difference ;) >> >> The biggest demo (TurboBadgerDemo) takes around 17 seconds to link in >> master, and around 16 seconds on incoming, all the other demos take much >> less (around 5 seconds). >> >> I won't rule out that I made an error switching between incoming and >> master (although I double-checked a few things, like making sure that the >> right emcc from the right SDK path is used). >> >> Cheers, >> -Floh. >> >> Am Mittwoch, 19. August 2015 11:50:13 UTC+2 schrieb Floh: >>> >>> "Subjectively yes", but I didn't measure the difference and since the >>> demos are small the link step is only a couple seconds anyway :) >>> >>> I'll try to do a quick comparison with master. >>> >>> -Floh. >>> >>> Am Dienstag, 18. August 2015 22:46:46 UTC+2 schrieb Alon Zakai: >>>> >>>> Great, thanks! >>>> >>>> Did you notice any compilation speed improvements? >>>> >>>> On Tue, Aug 18, 2015 at 1:25 PM, Floh <[email protected]> wrote: >>>> >>>>> Tested with the Oryol demos and all looking good :) >>>>> >>>>> Cheers, >>>>> -Floh >>>>> >>>>> >>>>> Am Montag, 17. August 2015 22:46:05 UTC+2 schrieb Alon Zakai: >>>>>> >>>>>> The incoming branches now have an optimization which avoids llvm-link >>>>>> when possible. This is kind of a hack, but looks like it's worth it - it >>>>>> pushes linking into the opt call we do afterwards anyhow, which avoids >>>>>> saving and then loading the entire module. On large codebases, this >>>>>> matters >>>>>> a lot it turns out, much more than I expected. >>>>>> >>>>>> I also optimizing llvm linking in some other ways (avoid a copy of >>>>>> the first input), and disabled extra verifications in optimized builds. >>>>>> >>>>>> On incoming, I see a 30% speedup on Poppler and 35% on Unity, on -O2 >>>>>> builds. >>>>>> >>>>>> This did change some toolchain code, please test and report bugs if >>>>>> you find any. >>>>>> >>>>>> Side note, it looks like linking order matters a lot in llvm. It is >>>>>> always better to have the larger file first in the link command, because >>>>>> the llvm linker starts with the first module, then links the second into >>>>>> it. So you want to write >>>>>> >>>>>> emcc bigger-bitcode.bc smaller-bitcode.bc >>>>>> >>>>>> both when linking them to bitcode and when compiling to JS. (Of >>>>>> course, sometimes you can't change the link order, like when using .a >>>>>> files >>>>>> where the order matters.) >>>>>> >>>>>> - Alon >>>>>> >>>>>> -- >>>>> 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 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.
