Hi,
I am replying to both at once.
I commited a slightly different version of the diff. Only changing 'opt-level'
for now.
On Fri, Jun 05, 2020 at 02:48:00PM +0200, Leo Unglaub wrote:
> Hey,
> i have a question about that change. Is there a reason to disable LTO? I
> always enable it for my Rust projects and it works very well. If you dont
> mind me asking, what is the reason behind that default?
>
link-time-optimization isn't bad. but it is resource and time consuming option.
at least, it is my impression.
for now, I discarded this change from default, and I will try to measure it.
rust has two differents LTO strategies: "fat" and "thin". According to the
documentation, "thin" is similar to "fat", but takes substantially less time to
run while still achieving performance gains similar to "fat".
one possible problem I found with 'false' default value, it is the fact that it
enables lto=thin or lto=off depending others parameters (codegen units and
opt-level).
On Sat, Jun 06, 2020 at 06:04:23PM +0100, Laurence Tratt wrote:
> On Fri, Jun 05, 2020 at 09:31:42AM +0200, Sebastien Marie wrote:
>
> Hello Sebastien,
>
> A few thoughts on default Cargo options for release compilation: take them
> for what they're worth, which might not be very much!
I am a reluctant to playing to much with compilation options. It expects I am
know what I am doing, and I am far to know the exact implications of changing
defaults, specially when it implies changes in toolchain in Rust and in LLVM.
>From the options you cited, only "lto" has been changed from its default (and I
didn't commit this change and kept the default for now).
>
> > + echo "overflow-checks = false" >>${WRKDIR}/.cargo/config; \
>
> Personally I wouldn't mind if we experimented with "overflow-checks = true"
> since although overflow in Rust is not undefined behaviour, I've not yet
> seen a use that wasn't a bug (since people should use the 'unchecked'
> variants in such cases). I have heard various figures given for the
> performance impact of this, none of them very recent. If it turns out to
> make things horribly slow, I think we'd soon find out from users and could
> turn the overflow checks off!
>
> > + echo "lto = 'off'" >>${WRKDIR}/.cargo/config; \
>
> My experience is that LTO gives around a 5% performance increase on average,
> at the cost of noticeable increases in compilation time. I believe it once
> used to trigger bugs in LLVM, although I have not seen this happen in the
> couple of years that I've been using this in my projects. If we can bear the
> compilation time hit (and I know that Rust ports are already slow to
> compile), this might be worth turning on.
>
> > + echo "panic = 'unwind'" >>${WRKDIR}/.cargo/config; \
>
> Most Rust programs that I've seen don't make use of 'unwind' and can be
> 'abort', which leads to slightly smaller binaries. I'm not sure what to do
> about those programs that really do require 'unwind' though: make them turn
> it on via a flag?
>
> > + echo "codegen-units = 4" >>${WRKDIR}/.cargo/config; \
>
> This one is tricky, because you get better optimisation at codegen-units=1,
> but less parallel compilation. However, that might not be a problem in the
> main usecase of building with dpb, where restricting compilation to a single
> core might even be thought an advantage?
Thanks to both for your comments.
--
Sebastien Marie
