Optimizing by default

[tanadeau]

Thanks. I’ll take a look and see if there’s already an issue for that. I’d like to get into the Rust code, and that seems like it would be an easy task.

Another thing still to consider is the integer overflow behavior. Currently/before 1.0 the plan is only to have integer overflow or underflow detection in “debug” builds. If we change the default to optimize but keep debug behavior, does the overflow checking stay on? It seems reasonable that it should, but that code generation can prevent a lot of peephole optimizations due to the jump. It would definitely hurt the performance of numerics-heavy code.

[cmr]

There is a great document somewhere describing the different build types, the C committee’s opinion on them, and why NDEBUG is the correct choice, but I can’t seem to find it right now

[dhardy]

#ifndef NDEBUG ... is used in C because it means that if there is a typo in the macro name or somebody forgot about it, the section is turned on (which usually means assertions enabled). The first reason doesn’t apply to Rust code because the compiler will tell you if the macro names are wrong.

Optimisation levels: are there only two (on/off)? GCC supports many (extracts from man page):

With -O, the compiler tries to reduce code size and execution time, without performing any optimizations that take a great deal of compilation time.

-O2 Optimize even more.  GCC performs nearly all supported optimizations that do not involve a space-speed tradeoff.  As compared to -O, this option increases both compilation time and the performance of the generated code.

-O3 Optimize yet more.

-O0 Reduce compilation time and make debugging produce the expected results.  This is the default.

-Os Optimize for size.  -Os enables all -O2 optimizations that do not typically increase code size.  It also performs further optimizations designed to reduce code size.

As noted here, disabling optimisations can be useful to reduce compilation time and to make code behave in a more expected manner when run in a debugger. This implies that under specific circumstances disabling optimisations is useful, but not that this needs to be the default.

From my point of view, an optimisation level equivalent to -O1 or -O2 would be a good default. (Not -O3 because some of those optimisations result in numeric approximations or in some cases, significantly larger code size and maybe other draw-backs.)

[ahmedcharles]

I agree with optimizing by default for rustc, at least, since by the time you need to debug anything, you already know (or will rapidly learn) how to turn optimizations off. For cargo it’s harder to say since I don’t want to have to type significantly more when developing to get a debug build rather than a release one. But that could be fixed by adding a marker in Cargo.toml which specifies what the default is for a simple cargo build and let the user decide.

[Valloric]

Yet another example of a newcomer to Rust using unoptimized builds by accident and concluding that Rust is slow.

[tbu]

From my Github comment:

Complaining about the status quo like this is not necessarily good – you can’t see if the other option would raise similar problems with users about the even slower compilation speed.

What I mean is that you obviously don’t get user stories about overlong compilation times, because currently, release is not the default.

[llogiq]

And one more example.

Yep, it really trips people.

[vks]

I agree that optimizing is a much more reasonable default. The increased compile time shouldn’t be an issue for new users, and experienced users can explicitly pass the debug flag. I also would prefer this option over noisy warnings.

[llogiq]

Could there be a reasonable middle ground — that is, optimize, but not to the point of losing debugging information? Yes, it might make compilation a bit slower (though not as slow as --release/-O3), but it won’t trip newbies as hard. Then --debug could still disable all optimizations, while --release enables all.

[tbu]

But then you have a not-so-obviously incorrect solution. It works somewhat fast but not as fast as it could. The current non-solution at least makes it obvious that something is wrong, people are asking others what they are doing wrong.

[llogiq]

So you want full optimization settings on by default, so that enough people complain about the compiler being slow which compels the rust team to improve the compiler. Clever. Sneaky, yes, but clever.

[carllerche]

It should also be possible to add a local config (stored in ~/.cargo/config) that allows changing the default options for cargo build

[DanielKeep]

I don’t see why we can’t just have both cargo and rustc tell the user what they’re doing by default. If you don’t specify debug/release or an optimisation level, the compiler just says the equivalent of “oh, by the way, I’m compiling in debug mode with no optimisations.”

Silently changing the default will just shift complaints to “man, Rust takes forever to compile, even when I’m not asking for optimisation!” and we’ll be back here arguing over changing the default back.

[comex]

Well, it’s a pretty well-regarded (if often ignored) tradition that Unix programs should be silent on success. (This only matters for rustc; cargo is already noisy of course.)

[DanielKeep]

I think educating users is more important than blind adherence to tradition in the face of clear practical disadvantages.

[tbu]

I don’t think we need to make rustc noisy, making cargo's output more obvious in that regard should be fine.

[tanadeau]

There’s currently a Cargo PR by @alexcrichton to have it output the used build profile (release or debug).

[iox]

Here is another example of someone getting confused by this.

[Valloric]

I created an RFC asking for rustc and cargo to produce optimized code by default.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.