Add changelog for 1.13.0

[brson]

The diagnostics PRs are excellent and some have excellent examples thanks @jonathandturner @estebank.

Here are some notes about the performance changes during the release.
Compile times are improved %40 in some cases.

This desires to be backported to beta for 1.13.

Sadly, the 1.12.1 changelog PR has not merged to master yet, and is sitting in a rollup PR.

r? @rust-lang/lang @rust-lang/compiler @rust-lang/libs @rust-lang/core

[brson]

Rendered.

[Mark-Simulacrum]

For the reasoning behind improvement to compile times, the compile-time optimizations are the most likely causes.

I don't believe any other PRs intentionally optimized the compiler (at least majorly). If you or @steveklabnik want to note it, I know that there are at least a few more places that I know of where we may be able to make some potentially large gains in terms of memory usage at least, and possibly performance too. Edit: By "note it" I mean in the blog post that someone (@steveklabnik?) writes up.

[brson]

This release includes builds for several new platforms, the standard library, compiler, and cargo:

• powerpc-unknown-linux-gnu
• powerpc64-unknown-linux-gnu
• powerpc64le-unknown-linux-gnu
• mips-unknown-linux-gnu
• mipsel-unknown-linux-gnu
• mips64-unknown-linux-gnuabi64
• mips64el-unknown-linux-gnuabi64
• s390x-unknown-linux-gnu

The builds have a deficiency though. I don't see "rust" packages for them on beta, so they can't be installed easily, either by "rust" tarball or by rustup toolchain install s930x-unknown-linux-gnu. I think the only way to install them from binary is by downloading therustcbinary and thecargo` nightly.

It may not be worth mentioning them yet if they are hard to install.

[bluss]

Depending on how big, but significant improvements are not rare. Many libraries compile a lot faster.

[alexcrichton]

Hm I just compiled the winapi crate on stable/beta/nightly and it took 30s on stable, 25s on beta, and 25s on nightly. We may not want to claim too much of a perf improvement here?

[retep998]

winapi 0.2 did not have every single function marked as inline, unlike winapi 0.3 which does.

[brson]

It looks like winapi 0.3 isn't out yet, so I better change this to not claim anything about it.

[steveklabnik]

By "note it" I mean in the blog post that someone (@steveklabnik?) writes up.

Yes, usually @brson writes the release notes and then I write the draft of the blog post.

[steveklabnik]

s/G/C/ 😄

[jonathandturner]

Can we repro the perf improvements by hand rather than using the perf.rust-lang.org? We had some problems last time trying to repro them.

[Mark-Simulacrum]

@jonathandturner At least for the #[inline] function fix, @retep998 commented here. That comment reports relatively huge decreases in compile time (LLVM passes down by an order of magnitude, trans down by 31% (628ms - 433ms).

[thepowersgang]

The ? operator appears to be stable in current beta - This should be in these release notes, right?

[bors]

☔️ The latest upstream changes (presumably #37597) made this pull request unmergeable. Please resolve the merge conflicts.

[alexcrichton]

One of the major improvements to compile time was the futures-rs-test-all test case which is basically exactly what #35761 targeted. Compiling the current test locally goes from 5.2s on stable to 4.7 on beta, but note that the test in the futures-rs repo is likely no longer exactly what's on the benchmark suite (I think I broke it up as it took too long to compile). Compiling the entire test suite of futures-rs takes 9.3s on stable and 9.2s on beta.

We... may not want to claim 40% perf improvements?

[alexcrichton]

Hm so testing again, I wonder, is perf.rust-lang.org doing --release? The numbers I just gave for futures were in debug mode, but compiling the entire test suite in release mode takes 22.7s on stable and 16.9s on beta, a 25% improvement. Maybe that's what's being measured?

[jonathandturner]

25% in release mode sounds good. Can we check a few more packages just to be sure?  (I'd do it but I'm traveling today)

Jonathan

On Sun, Nov 6, 2016 at 12:30 PM -0500, "Alex Crichton" notifications@github.com wrote:

Hm so testing again, I wonder, is perf.rust-lang.org doing --release? The numbers I just gave for futures were in debug mode, but compiling the entire test suite in release mode takes 22.7s on stable and 16.9s on beta, a 25% improvement. Maybe that's what's being measured?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[Mark-Simulacrum]

Hm so testing again, I wonder, is perf.rust-lang.org doing --release?

From what I can tell, it's not.

[alexcrichton]

Whoa ok scratch that I was accidentally using nightly when I thought I was using stable ok, current numbers I'm getting are:

• debug futures-rs-test-all (in the futures repo) - 8.37s on stable, 4.8 on beta, 5.3 on nightly
• debug futures-rs all tests - 15.6s on stable, 9.4 on beta, 9.7 on nightly
• release futures-rs all tests - 20.7s on stable, 16.9 on beta, 20.57 on nightly
• debug winapi - 29.8s on stable, 25.1s on beta, 25.7 on nightly
• release winapi - 35.6s on stable, 29.9s on beta, 32.1s on nightly

So it actually looks kind bad in some cases. While we universally improved stable -> beta we ended up regressing almost universally beta -> nightly.

[alexcrichton]

Compilers I used were:

rustc 1.12.1 (d4f39402a 2016-10-19)
rustc 1.13.0-beta.2 (85ca935b3 2016-10-19)
rustc 1.14.0-nightly (5665bdf3e 2016-11-02)

[retep998]

For winapi 0.3 where every single function is inline.

rustc 1.12.0 (3191fbae9 2016-09-23) Finished release [optimized] target(s) in 11.66 secs

rustc 1.14.0-nightly (19ac57926 2016-10-08) Finished release [optimized] target(s) in 7.37 secs

This is a 37% reduction in time, which is pretty close to 40%.

[bluss]

My impression was that the inline PR had a huge impact on build times of various libraries.

Trying a relatively small library I get this now:

ndarray 0.6.8 clean build (including dependencies)  rev 6fd2f989a

rustc 1.12.1 (d4f39402a 2016-10-19)

cargo build -j1

    Finished debug [unoptimized + debuginfo] target(s) in 13.10 secs
    Finished debug [unoptimized + debuginfo] target(s) in 12.98 secs

rustc 1.13.0-beta.3 (106d18793 2016-11-04)

cargo build -j1

    Finished debug [unoptimized + debuginfo] target(s) in 6.45 secs
    Finished debug [unoptimized + debuginfo] target(s) in 6.50 secs

That's basically reducing the build time by 50%.

For the curious, the timing on current nightly is

rustc 1.14.0-nightly (cae6ab1c4 2016-11-05)
cargo build -j1
    Finished debug [unoptimized + debuginfo] target(s) in 5.89 secs

[xen0n]

@brson

The builds have a deficiency though. I don't see "rust" packages for them on beta, so they can't be installed easily, either by "rust" tarball or by rustup toolchain install s930x-unknown-linux-gnu. I think the only way to install them from binary is by downloading the rustc binary and the cargo nightly.

Can confirm that the above is true for MIPSel and MIPS64el, as libc on MIPS lacks SIGCHLD which is holding wait-timeout, a rustup dependency. For rustup to work we would have to wait until we fix libc. I'm preparing a fix but 1.13.0 release is imminent and libc changes really shouldn't be rushed, so perhaps it's worth a little explanation for users of said platforms. But again non-x86 development platforms are a minority at present, so I wouldn't expect any significant warning note or something like that; a one-line remainder should be enough.

[jonathandturner]

Yeah, looks good -

hyper-0.5.0: 57.25s (stable) vs 36.93s (beta)
inflate-0.1.0: 18.91s (stable) vs 17.4s (beta)
regex-0.1.30: 7.67s (stable) vs 6.91s (beta)
rust-encoding.0.2.32: 6.70s (stable) vs 5.61s (beta)

Definitely some improvement there.

[jonathandturner]

@alexcrichton - did you file issues on the perf regressions?

[brson]

The ? operator appears to be stable in current beta - This should be in these release notes, right?

Oh yes! Thanks for pointing that out. Also attributes on statements: #36995

[brson]

Updated to add ? and statement attributes, and I removed mention of the new ports, which aren't fully working, and the ability to not install rust-docs since I failed to deploy that change to the buildbot on Friday.

[brson]

I'm going to port this to beta now.

[brson]

@Mark-Simulacrum would either winapi-0.3 or ndarray-0.6.8 be good for the perf suite?

[Mark-Simulacrum]

I'd guess that winapi would be non-trivial to add since (AFAIK) it compiles next to nothing on *nix platforms, which is what the perf server is. Adding ndarray should be relatively trivial--let me know if you'd like that to happen, and I'll try and get it done soon.

[retep998]

@Mark-Simulacrum Cross compilation of winapi is trivially easy because it's just an rlib so you don't even need a linker or system libraries. Just libcore compiled for a windows target is enough. Don't forget to pass --features everything.

[bluss]

please don't use ndarray for that. Maybe I can propose some application of it to use instead (i.e. where the ndarray operations are actually instantiated and used).

[Razican]

Is this issue number correct? it has the same ID as the Stabilize the ? operator, and redirects to the same PR.

[brson]

Yes. They were stabilized in the same PR.

[brson]

r? @steveklabnik

[CryZe]

I'm a bit confused how the ? operator is already hitting stable, if it just got stabilized 4 weeks ago? Isn't it supposed to be in beta first? Seems like it just skipped a cycle? Also the code suggests that it should be in 1.14 instead: https://github.com/rust-lang/rust/blob/master/src/libsyntax/feature_gate.rs#L357

// `expr?`
(accepted, question_mark, "1.14.0", Some(31436)),

[bluss]

@CryZe Stabilised and nominated for beta backport in #36995, so yes, it ran a slightly sped-up path to get here.

[CryZe]

@bluss Yeah, people told me about it in IRC by now. Seems like the "1.14.0" should be updated though. Looks like there's already a PR for this though: #37661

[bluss]

Another new feature in 1.13 that I can't see in the changelog: Reflect was removed, so you can now call TypeId::of::<T> with only the bound T: 'static, previously T: Reflect or equivalently T: Any was required.

This simplifies ad-hoc type based dispatch on stable (as used by ndarray to call f32- and f64-specific linear algebra functions).

[mrageh]

Hey Folks

any ideas on when 1.13 will be stable?

[jonathandturner]

@mrageh - today: https://www.rust-lang.org/en-US/downloads.html

[alexcrichton]

@brson is this just waiting for an r+? Given that we just shipped 1.13.0 seems like no, but just wanted to make sure :)

[brson]

Yeah this needs an r+.

[alexcrichton]

@bors: r+

Ok!

[bors]

📌 Commit 0f817a0 has been approved by alexcrichton