Link-time optimization versus header-only

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Link-time optimization versus header-only

Hubert Tong via cfe-dev
Hi

I hope it's OK that I post here even though I'm not a developer on the clang compiler itself. Googling turns up a bunch of answers that appear to be pure speculation (even on StackOverflow), so I thought maybe the clang developers had more informed opinions about it.

Common wisdom says that one should keep c++ implementations in separate files (not in header files), to reduce recompilation times. However, that brings out the fear that it might hurt runtime performance, as the compiler might have less information available for inlining. But then again, clang does whole module optimization, so maybe there would be no difference performance-wise? On the other hand, there's the concept of precompiled headers, so maybe it wouldn't make any difference for compile times either.

So the questions are:
1) With link-time optimization set to monolithic, will a project split into separate compilation units be equally well optimized as with the header-only approach?
2) Will it make a difference to compilation times, compared to the header-only approach, using precompiled headers?

The longer link times with lto does not matter, because most of the time you'll be doing debug builds, without lto.

Per

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Link-time optimization versus header-only

Hubert Tong via cfe-dev
On Sat, Aug 8, 2020 at 7:01 PM Per Bull Holmen via cfe-dev
<[hidden email]> wrote:
>
> Hi
>
> I hope it's OK that I post here even though I'm not a developer on the clang compiler itself. Googling turns up a bunch of answers that appear to be pure speculation (even on StackOverflow), so I thought maybe the clang developers had more informed opinions about it.
>
> Common wisdom says that one should keep c++ implementations in separate files (not in header files), to reduce recompilation times. However, that brings out the fear that it might hurt runtime performance, as the compiler might have less information available for inlining. But then again, clang does whole module optimization, so maybe there would be no difference performance-wise? On the other hand, there's the concept of precompiled headers, so maybe it wouldn't make any difference for compile times either.
>
> So the questions are:
> 1) With link-time optimization set to monolithic, will a project split into separate compilation units be equally well optimized as with the header-only approach?

"With link-time optimization set to monolithic" - not sure what you're
referring to there, sounds like you might be using the terminology of
some non-clang product, like a 3rd party IDE, etc? I'd guess this
concept maps to LLVM's (non-thin) LTO.

I don't think it's a guarantee that the program will be exactly the
same when using LTO compared to moving code into a header - with LTO
there are two periods of optimization (frontend during the traditional
compilation step, then backend during the LTO step).

> 2) Will it make a difference to compilation times, compared to the header-only approach, using precompiled headers?

Will precompiled headers improve compile time compared to not using
them? Generally, yes.

> The longer link times with lto does not matter, because most of the time you'll be doing debug builds, without lto.

If that works for you, sounds fine - not how everyone does it (some
folks use ThinLTO (you might see this referred to as "incremental
LTO") for the ir daily development because they need the performance
to make the program even testable).

But, yeah, generally I would discourage moving code into headers for
the sake of optimizations if you can rely on some form of LTO (Thin or
full) to do the work.

- Dave
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev