Re: incremental compilation for opt Rust builds

[Simon Sapin]

On 05/04/18 14:19, Henri Sivonen wrote:

Can we make a particular vendored crate (encoding_rs) use -O3 while
the default for Rust code remains at -O2?


There’s an accepted RFC for "per-crate profiles" but it’s not 
implemented yet: https://github.com/rust-lang/rust/issues/48683


--
Simon Sapin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: incremental compilation for opt Rust builds

[Henri Sivonen]

On Tue, Mar 13, 2018 at 3:35 PM, Nathan Froyd  wrote:
> On Tue, Mar 13, 2018 at 3:10 AM, Henri Sivonen  wrote:
>> On Tue, Mar 13, 2018 at 2:56 AM, Nathan Froyd  wrote:
>>> (Our release builds use -O2 for Rust code.)
>>
>> What does cargo bench use by default?
>> (https://internals.rust-lang.org/t/default-opt-level-for-release-builds/4581
>> suggests -O3.)
>
> As mentioned by Alexis, -O3 is indeed what gets used by default.
>
>> That is, is cargo bench for a crate that's vendored into m-c
>> reflective of that crate's performance when included in a Firefox
>> release?
>
> I do not know.  I know that folks working on WebRender were finding
> that -O3 produces *much* better code for certain things; they filed
> bugs for rustc that I can't find right now.  I don't know if those
> bugs have been addressed.
>
> When Stylo was getting off the ground a year ago, mbrubeck did some
> -O2 vs. -O3 size analysis, which led to some -O2 vs. -O3 performance
> analysis in https://bugzilla.mozilla.org/show_bug.cgi?id=1328954.  The
> conclusion there is that -O3 wasn't worth it and came with a
> reasonably large codesize increase.
>
> I guess the answer is "probably, but you should measure to make sure"?

For encoding_rs, -O2 vs -O3 has pretty big performance effects in both
directions. (Didn't measure code size.) I think I'd rather have the
-O3 scenario than the -O2 scenario for encoding_rs.

Can we make a particular vendored crate (encoding_rs) use -O3 while
the default for Rust code remains at -O2?

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: incremental compilation for opt Rust builds

[Nathan Froyd]

On Tue, Mar 13, 2018 at 3:10 AM, Henri Sivonen  wrote:
> On Tue, Mar 13, 2018 at 2:56 AM, Nathan Froyd  wrote:
>> (Our release builds use -O2 for Rust code.)
>
> What does cargo bench use by default?
> (https://internals.rust-lang.org/t/default-opt-level-for-release-builds/4581
> suggests -O3.)

As mentioned by Alexis, -O3 is indeed what gets used by default.

> That is, is cargo bench for a crate that's vendored into m-c
> reflective of that crate's performance when included in a Firefox
> release?

I do not know.  I know that folks working on WebRender were finding
that -O3 produces *much* better code for certain things; they filed
bugs for rustc that I can't find right now.  I don't know if those
bugs have been addressed.

When Stylo was getting off the ground a year ago, mbrubeck did some
-O2 vs. -O3 size analysis, which led to some -O2 vs. -O3 performance
analysis in https://bugzilla.mozilla.org/show_bug.cgi?id=1328954.  The
conclusion there is that -O3 wasn't worth it and came with a
reasonably large codesize increase.

I guess the answer is "probably, but you should measure to make sure"?

-Nathan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: incremental compilation for opt Rust builds

[Alexis Beingessner]

Oh and here's the one documented in the nightly docs, just for completeness

# The benchmarking profile, used for `cargo bench` and `cargo test
--release`.[profile.bench]opt-level = 3debug = falserpath = falselto =
falsedebug-assertions = falsecodegen-units = 1panic =
'unwind'incremental = falseoverflow-checks = false



On Tue, Mar 13, 2018 at 9:24 AM, Alexis Beingessner  wrote:

> The defaults of the various cargo profiles are documented here:
> https://doc.rust-lang.org/cargo/reference/manifest.html
>
> The relevant entry is:
>
> # The benchmarking profile, used for `cargo bench` and `cargo test 
> --release`.[profile.bench]opt-level = 3debug = falserpath = falselto = 
> falsedebug-assertions = falsecodegen-units = 1panic = 'unwind'
>
> Note that we always build with panic=abort which improves codegen; not
> sure about which conditions we use lto for rust code off the top of my head.
>
>
> On Tue, Mar 13, 2018 at 3:10 AM, Henri Sivonen 
> wrote:
>
>> On Tue, Mar 13, 2018 at 2:56 AM, Nathan Froyd  wrote:
>> > (Our release builds use -O2 for Rust code.)
>>
>> What does cargo bench use by default?
>> (https://internals.rust-lang.org/t/default-opt-level-for-rel
>> ease-builds/4581
>> suggests -O3.)
>>
>> That is, is cargo bench for a crate that's vendored into m-c
>> reflective of that crate's performance when included in a Firefox
>> release?
>>
>> --
>> Henri Sivonen
>> hsivo...@hsivonen.fi
>> https://hsivonen.fi/
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: incremental compilation for opt Rust builds

[Alexis Beingessner]

The defaults of the various cargo profiles are documented here:
https://doc.rust-lang.org/cargo/reference/manifest.html

The relevant entry is:

# The benchmarking profile, used for `cargo bench` and `cargo test
--release`.[profile.bench]opt-level = 3debug = falserpath = falselto =
falsedebug-assertions = falsecodegen-units = 1panic = 'unwind'

Note that we always build with panic=abort which improves codegen; not sure
about which conditions we use lto for rust code off the top of my head.


On Tue, Mar 13, 2018 at 3:10 AM, Henri Sivonen  wrote:

> On Tue, Mar 13, 2018 at 2:56 AM, Nathan Froyd  wrote:
> > (Our release builds use -O2 for Rust code.)
>
> What does cargo bench use by default?
> (https://internals.rust-lang.org/t/default-opt-level-for-
> release-builds/4581
> suggests -O3.)
>
> That is, is cargo bench for a crate that's vendored into m-c
> reflective of that crate's performance when included in a Firefox
> release?
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: incremental compilation for opt Rust builds

[Henri Sivonen]

On Tue, Mar 13, 2018 at 2:56 AM, Nathan Froyd  wrote:
> (Our release builds use -O2 for Rust code.)

What does cargo bench use by default?
(https://internals.rust-lang.org/t/default-opt-level-for-release-builds/4581
suggests -O3.)

That is, is cargo bench for a crate that's vendored into m-c
reflective of that crate's performance when included in a Firefox
release?

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

incremental compilation for opt Rust builds

[Nathan Froyd]

Hi all,

In bug 1437627, I turned on incremental compilation for Rust for local
developer opt builds as the default behavior.  Debug builds should be
using incremental compilation already, and automation builds continue
to *not* use incremental compilation, due to environmental
considerations that would make incremental builds unprofitable.

If you use local builds for performance analysis purposes, you should
set --enable-release or set RUSTC_OPT_LEVEL to 2 or 3 in your
mozconfig.  This condition was reached after looking through the
discussion at 
https://lists.mozilla.org/pipermail/dev-platform/2017-October/020324.html
when the default Rust optimization level was changed to -O1 from -O2.
Discussion in that thread suggested that -O2 or -O3 for Rust
compilation was more suitable for performance analysis than the
default of -O1.  (Our release builds use -O2 for Rust code.)

If you have issues or suggestions on how to improve, please file
blocking bugs for bug 1437627 and CC me.

Thanks,
-Nathan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform