On Thursday 23 July 2015 10:31:01 René J. V. Bertin wrote: > And actually, I'm now fooling around with a project that just builds qtbase > (5.4.2), and it seems that I need -r even immediately after calling > configure.
configure should generate exactly one Makefile: the top-level. > > That's also why Qt 4's configure had the -fast option. Which wasn't the > > default. I don't know why anyone would intentionally choose a slow build > > with no further benefits... > > ? If -fast just let configure skip the recursive qmake call, what difference > did it really make? In the end you'd be doing all those qmake calls > anyway... Actually, there are three solutions: 1) use qmake to generate the Makefiles 2) generate a stub Makefile that calls qmake on first run 3) generate only the top-level Makefile #1 was the default in Qt 2, 3, and 4. #2 was Qt 4's -fast option. Qt 5 switched to #3. And you're perceptive... in certain situations, -fast is slower than the regular slow build! > But in that register: why is qmake itself not built in parallel? I've been > patching the configure script to "fix" that, and it works fine. export MAKEFLAGS=-jN Boom! Now it is! Supported since 2001. > > The compilation itself is faster because there's no code generation for > > GCC > > (due to -fno-fat-lto-objects). I don't remember whether Clang -flto > > produces > Hmm, I forced fat lto objects in the Qt 4.8.7 build on Linux, just to be > sure (I don't want to end up with binaries that force me to use LTO for > everything all the time). Again a feature of ltcg.prf: it turns fat binaries back on for static libraries. For dynamic libraries, there are no ill effects. > > LLVM and code or just LLVM bytecode. I know ICC doesn't, but for me it > > takes 30 minutes to link QtCore and an infinite amount of time for QtGui > > (it gets OOM-killed due to swap exhaustion before it finishes). > > With Qt 5 and ICC? Actually, ever since 4.7, which is when Intel first gave me a licence to use ICC 11. I've never been able to do an IPO build of QtGui -- I've never had enough RAM for it. > > Unless you're me, you don't want to do this. > > Do I have any reason to be you? :) Yes. That's when you disassemble the generated code to check if it is optimal. Reading the assembly in a .o is faster and easier than waiting for the full link. > > I only have evidence for other projects, where LTO did have noticeable > > runtime performance effect. > > I certainly hope this is going to pay off on my slow(er) machines, as well > as during periods of high CPU loads. Any reduction in GUI (and middleware) > overhead is a gain, IMHO, esp. if it can be obtained with build options. I watched Jon Kalb's session this week at the PDXCPP meeting and he mentioned large, modern datacentres report the largest costs are: * hardware * power distribution * cooling * power So even if you make software only 1% faster, there's still a gain because you consumed 1% less power (actually, I think he said that gives you a 0.91% power reduction). > BTW: OS X's -mdynamic-no-pic option used to give me an approx. 15% gain, > which I think is impressive for a single option that doesn't even increase > compile time (and I was equally impressed with the Shark tool that pointed > out to me that I should be using it). That was on a 32bit PPC machine; I > haven't clocked its impact on Intel architecture. > In 64bit mode it can be used systematically, even for shared libraries. Does > Qt use it? I've never heard of it. I'll investigate. I've been tracking GCC 6's -fno-plt option, which also shows great promise. > > better able to eliminate dead code. That's often the result of the > > -fwhole- > > program part of -flto. > > GCC's documentation (man page) isn't really clear on -fwhole-program and > when it applies or should be used. Apparently I should understand that the > linker plugin knows when to apply it? -flto activates -fwhole-program when linking a binary. You shouldn't worry about it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest