Re: Default Rust optimization level decreased from 2 to 1

Le 25/04/2018 à 18:26, Bobby Holley a écrit : Could we instead have the profiler UI throw up a warning if the build was not compiled with --enable-release? I filed https://github.com/devtools-html/perf.html/issues/976 to discuss about it. Thanks, -- Julien

Re: Default Rust optimization level decreased from 2 to 1

On Wed, Apr 25, 2018 at 7:11 PM, Gregory Szorc wrote: > The build peers have long thought about adding the concept of “build > profiles” to the build system. Think of them as in-tree mozconfigs for > common, supported scenarios. This would be good to have. It would also

Re: Default Rust optimization level decreased from 2 to 1

On 04/25/2018 08:38 PM, Bobby Holley wrote: On Wed, Apr 25, 2018 at 10:21 AM, Ted Mielczarek wrote: On Wed, Apr 25, 2018, at 12:32 PM, Jeff Muizelaar wrote: At minimum we should make --enable-profiling build with rust-opt. This sounds reasonable, although the quirk is

Re: Default Rust optimization level decreased from 2 to 1

On Wed, Apr 25, 2018 at 10:21 AM, Ted Mielczarek wrote: > On Wed, Apr 25, 2018, at 12:32 PM, Jeff Muizelaar wrote: > > At minimum we should make --enable-profiling build with rust-opt. > > This sounds reasonable, although the quirk is that we default > --enable-profiling on

Re: Default Rust optimization level decreased from 2 to 1

On Wed, Apr 25, 2018, at 12:32 PM, Jeff Muizelaar wrote: > At minimum we should make --enable-profiling build with rust-opt. This sounds reasonable, although the quirk is that we default --enable-profiling on for nightly[1], so anyone building m-c will have it enabled. We could make the build

Re: Default Rust optimization level decreased from 2 to 1

I think that makes sense as a default, with the ability to explicitly --disable-release if people are profiling something specific, know what they're doing, and want faster builds. On Wed, Apr 25, 2018 at 9:32 AM, Jeff Muizelaar wrote: > At minimum we should make

Re: Default Rust optimization level decreased from 2 to 1

At minimum we should make --enable-profiling build with rust-opt. -Jeff On Wed, Apr 25, 2018 at 11:35 AM, Emilio Cobos Álvarez wrote: > There's a fair amount of people bitten by this constantly, which see long > style profiling markers and what's really happening is that

Re: Default Rust optimization level decreased from 2 to 1

Could we instead have the profiler UI throw up a warning if the build was not compiled with --enable-release? On Wed, Apr 25, 2018 at 9:23 AM, Emilio Cobos Álvarez wrote: > > > On 4/25/18 6:11 PM, Gregory Szorc wrote: > >> >> >> On Apr 25, 2018, at 08:35, Emilio Cobos Álvarez

Re: Default Rust optimization level decreased from 2 to 1

On 4/25/18 6:11 PM, Gregory Szorc wrote: On Apr 25, 2018, at 08:35, Emilio Cobos Álvarez wrote: There's a fair amount of people bitten by this constantly, which see long style profiling markers and what's really happening is that they're profiling a local opt build,

Re: Default Rust optimization level decreased from 2 to 1

> On Apr 25, 2018, at 08:35, Emilio Cobos Álvarez wrote: > > There's a fair amount of people bitten by this constantly, which see long > style profiling markers and what's really happening is that they're profiling > a local opt build, and thus the Rust code in style has

Re: Default Rust optimization level decreased from 2 to 1

There's a fair amount of people bitten by this constantly, which see long style profiling markers and what's really happening is that they're profiling a local opt build, and thus the Rust code in style has barely any optimization and is slow. I know that shouldn't be a thing, and that people

Re: Default Rust optimization level decreased from 2 to 1

On 10/31/17 3:21 PM, Gregory Szorc wrote: It is "wrong" for the set of "people performing profiling." Just to be clear, that set is "everyone". Now the set of "people performing profiling on builds they create themselves" is a separate question -Boris

Re: Default Rust optimization level decreased from 2 to 1

On Tue, Oct 31, 2017 at 03:39:39PM -0400, Jeff Muizelaar wrote: On Tue, Oct 31, 2017 at 3:21 PM, Gregory Szorc wrote: It is "wrong" for the set of "people performing profiling." This set is different from "people compiling Gecko." Which is different from "people who actually

Re: Default Rust optimization level decreased from 2 to 1

Would it be possible to have our profiling tools warn if about:compiler optimization flags are not in about:buildconfig? On Tue, Oct 31, 2017 at 3:39 PM, Jeff Muizelaar wrote: > On Tue, Oct 31, 2017 at 3:21 PM, Gregory Szorc wrote: > > On Tue, Oct 31,

Re: Default Rust optimization level decreased from 2 to 1

On Tue, Oct 31, 2017 at 3:21 PM, Gregory Szorc wrote: > On Tue, Oct 31, 2017 at 12:02 PM, Jeff Muizelaar > wrote: >> >> As another piece of evidence in support opt-level=1 being the wrong >> default, Glenn also got bitten profiling with the wrong

Re: Default Rust optimization level decreased from 2 to 1

On Tue, Oct 31, 2017 at 12:21:42PM -0700, Gregory Szorc wrote: On Tue, Oct 31, 2017 at 12:02 PM, Jeff Muizelaar wrote: As another piece of evidence in support opt-level=1 being the wrong default, Glenn also got bitten profiling with the wrong options.

Re: Default Rust optimization level decreased from 2 to 1

On Tue, Oct 31, 2017 at 12:02 PM, Jeff Muizelaar wrote: > As another piece of evidence in support opt-level=1 being the wrong > default, Glenn also got bitten profiling with the wrong options. > https://github.com/servo/webrender/issues/1817#issuecomment-340553613 It is

Re: Default Rust optimization level decreased from 2 to 1

On 31/10/17 19:30, Randell Jesup wrote: Note that this means that profiles taken with local builds will be "off" compared to Nightly/etc, unless you rebuild with extra options. How much off? probably not a lot unless you're super-focused on Rust code, but that's just a guess. This was also

Re: Default Rust optimization level decreased from 2 to 1

As another piece of evidence in support opt-level=1 being the wrong default, Glenn also got bitten profiling with the wrong options. https://github.com/servo/webrender/issues/1817#issuecomment-340553613 -Jeff On Thu, Oct 26, 2017 at 2:51 PM, Jeff Muizelaar wrote: > FWIW,

Re: Default Rust optimization level decreased from 2 to 1

>On 2017-10-25 1:34 PM, Gregory Szorc wrote: >> Adding --enable-release to your mozconfig (the configuration for builds we >> ship to users) enables -Copt-level=2. (i.e. we didn't change optimization >> settings for builds we ship to users.) > >I've added a note about this to our benchmarking

Re: Default Rust optimization level decreased from 2 to 1

On 2017-10-25 1:34 PM, Gregory Szorc wrote: Adding --enable-release to your mozconfig (the configuration for builds we ship to users) enables -Copt-level=2. (i.e. we didn't change optimization settings for builds we ship to users.) I've added a note about this to our benchmarking instructions

Re: Default Rust optimization level decreased from 2 to 1

On 10/26/17 2:51 PM, Jeff Muizelaar wrote: What's the use case for a --enable-optimize, opt-level=1 build? Fwiw, I ended up doing a fair amount of my work recently in a "--enable-optimize, --disable-debug, --enable-rust-debug" build, for the following reasons: 1) I was modifying Rust

Re: Default Rust optimization level decreased from 2 to 1

On Thu, Oct 26, 2017 at 3:08 PM, Gregory Szorc wrote: > Would it help if we had a separate --enable-optimize-rust (or similar) > option to control Rust optimizations so we have separate knobs? If we did > that, --disable-optimize-rust could be opt-level 0 or 1 and >

Re: Default Rust optimization level decreased from 2 to 1

On Thu, Oct 26, 2017 at 11:51 AM, Jeff Muizelaar wrote: > FWIW, WebRender becomes unusable opt-level=1. It also looks like style > performance takes quite a hit as well which means that our default > developer builds become unusable for performance work. I worry that >

Re: Default Rust optimization level decreased from 2 to 1

FWIW, WebRender becomes unusable opt-level=1. It also looks like style performance takes quite a hit as well which means that our default developer builds become unusable for performance work. I worry that people will forget this and end up rediscovering only when they look at profiles (as mstange

Re: Default Rust optimization level decreased from 2 to 1

On Wed, Oct 25, 2017 at 10:34 AM, Gregory Szorc wrote: > Compiling Rust code with optimizations is significantly slower than > compiling without optimizations. As was measured in bug 1411081, the > difference between rustc's -Copt-level 1 and 2 on an i7-6700K (4+4 cores) > for

Re: Default Rust optimization level decreased from 2 to 1

On 10/25/17 2:50 PM, Emilio Cobos Álvarez wrote: From mozilla-central I've been using ./mach cargo check gkrust, and I certainly expect it to keep working. Ah, excellent. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Default Rust optimization level decreased from 2 to 1

On Wed, Oct 25, 2017 at 11:50 AM, Emilio Cobos Álvarez wrote: > > > On 10/25/2017 07:59 PM, Boris Zbarsky wrote: > > On 10/25/17 1:34 PM, Gregory Szorc wrote: > >> Also, due to ongoing work around Rust integration in the build system, > it > >> is dangerous to rely on manual

Re: Default Rust optimization level decreased from 2 to 1

On 10/25/2017 07:59 PM, Boris Zbarsky wrote: > On 10/25/17 1:34 PM, Gregory Szorc wrote: >> Also, due to ongoing work around Rust integration in the build system, it >> is dangerous to rely on manual `cargo` invocations to compile Rust >> because >> bypassing the build system (not using `mach

Re: Default Rust optimization level decreased from 2 to 1

On 10/25/17 1:34 PM, Gregory Szorc wrote: Also, due to ongoing work around Rust integration in the build system, it is dangerous to rely on manual `cargo` invocations to compile Rust because bypassing the build system (not using `mach build`) may not use the same set of RUSTFLAGS that direct

Default Rust optimization level decreased from 2 to 1

Compiling Rust code with optimizations is significantly slower than compiling without optimizations. As was measured in bug 1411081, the difference between rustc's -Copt-level 1 and 2 on an i7-6700K (4+4 cores) for a recent revision of mozilla-central was 325s/802s wall/CPU versus 625s/1282s. This