Oh I can absolutely see why you might not want to enable it by default, but
in special cases where performance is worth the extra manual fuss of
working around its very occasional bugs, it's quite useful.
So I did a release build of our current primary project without LTO, and
compared it to our build with LTO.
Before I present the results though, some peculiarities of our build
process to be aware of:
- We compile all our libraries statically, including libc and libc++
under windows. In addition we make heavy use of templates and Boost, so
our resulting generated object size is large.
- We include large binary blobs in our release executable itself (game
music, textures) which increase the final binary size considerably. I
subtract these (approximate) blob sizes from the final result for the code
size difference comparison.
- There are no debugging symbols included in our release build and the
binary is stripped with strip -spv.
- This version is 32bit only. You may see very different results for
64bit builds.
Project properties:
- 27000LOC without includes
- 200 compiled objects for the linker
- 26 pre-compiled libraries, 9.27MB
- 47 binary blobs, 140MB
- 127 compiled objects (project code), remainder of the size
- A lot of heavy optimisation options, including -Ofast and several
unsafe maths optimisations, but also tweaked optimiser params giving the
optimiser much higher memory limits and function size growth etc than would
be allowed by default. Here's a pastebin of all optimisation flags used:
http://pastebin.com/R6dNCMhP
- The only difference between the tests was disabling
-fuse-linker-plugin and -flto for the without-lto build. Both were built
from scratch.
Comparison results:
........................Without LTO.....................With
LTO................Difference
Build time 20m 51s 28m
2s +34%
Object size 152,243,279 bytes 169,512,168
bytes +11%
Object size minus blobs 4,977,685 bytes 22,246,874
bytes +346%
File size 152,585,216 bytes 150,350,848
bytes -2%
File size minus blobs 5,319,622 bytes 3,085,254
bytes -42%
Benchmark time 1m 53s 1m
47s -6%
This is probably not a very good generalisation for the use of LTO since my
use-case is quite specific, but these numbers might be of interest
nevertheless.
In summary, you're basically paying 34% more compilation time (from scratch
- haven't compared partial compiles) and 300% more pre-linked objet size,
and in return getting 42% smaller compiled code size and 6% performance
improvement. In games, absolutely any measurable performance improvement
is worth any amount of extra compile-time cost, but that may not be true
for other fields.
Regards,
Riot
On 29 May 2015 at 13:27, Ruben Van Boxem <vanboxem.ru...@gmail.com> wrote:
> 2015-05-29 13:36 GMT+02:00 Riot <rain.back...@gmail.com>:
>
>> I have to disagree. I use lto in large production builds with great
>> success. My use case is performance critical (games) and I build with
>> -Ofast as well as lto and other heavy optimisations without problems,
>> generating executable binaries of over a hundred megabytes in size when
>> stripped and consisting of hundreds of translation units.
>>
>> Prior to 4.8 lto was incomplete and problematic but most bugs seem to
>> have been eradicated by gcc 5.0.
>>
>
> Interesting, because lto, even on Linux, causes quite some grievances up
> to te point distributions are refusing to enable it for their packages by
> default.
>
> Would you have any performance numbers (and I guess file sizes) comparing
> lto vs no-lto builds (all the other options remaining unchanged of course)?
> It'd be very interesting to see how lto actually changes things.
>
> Thanks!
>
> Ruben
>
>> In my experience RTTI problems are more likely related to linking objects
>> that were built with a different version of gcc using lto. Try rebuilding
>> all your libraries and any linked objects with the same gcc version and
>> settings. It may also be worth it to try static linking.
>>
>> Riot
>> On 29 May 2015 12:21, "Etienne Sandré-Chardonnal" <etienne.san...@m4x.org>
>> wrote:
>>
>>> That's difficult to know, since the debugger seems to miss some
>>> information.
>>> The current function where the crash occurs is unknown :?? in the level
>>> 1 stack view
>>> For levels 2,3 and 4 I have the function name, but I have no access to
>>> the location in the code.
>>> Only level 5 of the stack is fully working in the debugger (all symbols
>>> + location in code)
>>>
>>> Level 2 is an default assignment operator of my ImageBuffer class. The
>>> class only contains basic types and std:: containers, no user defined
>>> pointers, so it likely crashes when copying one of the containers.
>>>
>>> The -flto is clearly not fully usable yet. I was trying it to see if it
>>> increases performance in a speed-critical app, which has a complex code and
>>> a lot of function calls between non-virtual classes. This seemed to be a
>>> good candidate for LTO.
>>>
>>> What did your debugger say? Was the segfault caused by dereferencing a
>>> pointer returned by a failed dynamic_cast?
>>>>
>>>> To my knowledge flto has never been working perfectly since g++ 4.8 on
>>>> Windows: multiple definitions, undefined references, pointer-to-function
>>>> referring garbage memory, valid pointers becoming null, random segment
>>>> faults, etc...
>>>> I strongly suggest you not use flto in production builds.
>>>>
>>>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
------------------------------------------------------------------------------
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
