<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><div style="direction: inherit;"><br></div></div><div><br>On Sep 16, 2016, at 7:02 PM, Carsten Mattner <<a href="mailto:carstenmattner@gmail.com">carstenmattner@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span>On Sat, Sep 17, 2016 at 3:17 AM, Mehdi Amini <<a href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a>> wrote:</span><br><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>On Sep 16, 2016, at 6:13 PM, Carsten Mattner <<a href="mailto:carstenmattner@gmail.com">carstenmattner@gmail.com</a>> wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>On Sat, Sep 17, 2016 at 2:07 AM, Teresa Johnson via llvm-dev</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Yes and to add on - the ThinLTO backend by default will</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>kick off std::thread::hardware_concurrency # of threads, which I'm finding is</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Is it just me or does that sound not very intuitive or at least a</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>little unexpected?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>It's good that it uses the resources eagerly, but in terms of build systems this</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>is certainly surprising if there's no control of that parameter via</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>make/ninja/xcode.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>You can control the parallelism used by the linker, but the option is linker dependent</span><br></blockquote><blockquote type="cite"><span>(On MacOS: -Wl,-mllvm,-threads=1)</span><br></blockquote><span></span><br><span>That's what I meant. Maybe lld can gain support for that and allow us to use</span><br><span>the same ld pass-through via the compile driver so that it works on Linux and</span><br><span>BSD too.</span></div></blockquote><blockquote type="cite"><div><span></span><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>too much for machines with hyperthreading. If that ends up being an issue I can</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>give you a workaround (I've been struggling to find a way that works on various</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>OS and arches to compute the max number of physical cores to fix this in the source).</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I've been using ninja -jN so far. I suppose when building with ThinLTO I should</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>run ninja -j1. Would that</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>What's the workaround?</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Seems like you missed my previous email: : cmake -DLLVM_PARALLEL_LINK_JOBS=1</span><br></blockquote><span></span><br><span>I didn't miss that and it will hopefully help with limiting LTO link phase</span><br><span>resource use, but I do wonder if it means it's either linking one binary</span><br><span>or compiling objects and not both at parallel.</span><br></div></blockquote><div style="direction: inherit;"><br></div><div style="direction: inherit;">I believe it only limits the number of concurrent links, without interacting with the compile phase, but I'd have to check to be sure.</div><div style="direction: inherit;"><br></div><blockquote type="cite"><div><span></span><br><blockquote type="cite"><span>Also, ninja is parallel by default, so no need to pass -j.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>This way you get nice parallelism during the compile phase,</span><br></blockquote><blockquote type="cite"><span>and ninja will issue only one link job at a time.</span><br></blockquote><span></span><br><span>I know, but I use ninja for C++ project because those are the most</span><br><span>frequent CMake user, and compiling C++ often requires limited it</span><br><span>to less than NUM_CORES.</span><br></div></blockquote><br><div>ThinLTO is quite lean on the memory side. What's you bottleneck to throttle you -j?</div><div><br></div><div>-- </div><div>Mehdi</div></body></html>