Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add changelog for 1.13.0 #37600

Merged
merged 1 commit into from Nov 12, 2016
Merged

Add changelog for 1.13.0 #37600

merged 1 commit into from Nov 12, 2016

Conversation

@brson
Copy link
Contributor

brson commented Nov 5, 2016

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
Copy link
Contributor Author

brson commented Nov 5, 2016

@brson brson added the beta-nominated label Nov 5, 2016
@Mark-Simulacrum
Copy link
Member

Mark-Simulacrum commented Nov 5, 2016

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
Copy link
Contributor Author

brson commented Nov 5, 2016

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.

RELEASES.md Outdated
* [Optimize the parser's last token handling][36527]
* [Only instantiate #[inline] functions in codegen units referencing
them][36524]. This leads to big improvements in rare cases, including the
common winapi crate.

This comment has been minimized.

@bluss

bluss Nov 5, 2016 Member

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

This comment has been minimized.

@alexcrichton

alexcrichton Nov 6, 2016 Member

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?

This comment has been minimized.

@retep998

retep998 Nov 6, 2016 Member

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

This comment has been minimized.

@brson

brson Nov 7, 2016 Author Contributor

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

@steveklabnik
Copy link
Member

steveklabnik commented Nov 5, 2016

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.

RELEASES.md Outdated
* [Add --all-features flag to cargo][cargo/3038]
* [Reject path-based dependencies in `cargo package`][cargo/3060]
* [Don't parse the home directory more than once][cargo/3078]
* [Don't try to generate Gargo.lock on empty workspaces][cargo/3092]

This comment has been minimized.

@steveklabnik

steveklabnik Nov 5, 2016 Member

s/G/C/ 😄

@jonathandturner
Copy link
Contributor

jonathandturner commented Nov 5, 2016

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
Copy link
Member

Mark-Simulacrum commented Nov 5, 2016

@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
Copy link
Contributor

thepowersgang commented Nov 6, 2016

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

@bors
Copy link
Contributor

bors commented Nov 6, 2016

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

@alexcrichton
Copy link
Member

alexcrichton commented Nov 6, 2016

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
Copy link
Member

alexcrichton commented Nov 6, 2016

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
Copy link
Contributor

jonathandturner commented Nov 6, 2016

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
Copy link
Member

Mark-Simulacrum commented Nov 6, 2016

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

From what I can tell, it's not.

@alexcrichton
Copy link
Member

alexcrichton commented Nov 6, 2016

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
Copy link
Member

alexcrichton commented Nov 6, 2016

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
Copy link
Member

retep998 commented Nov 6, 2016

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
Copy link
Member

bluss commented Nov 6, 2016

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
Copy link
Contributor

xen0n commented Nov 7, 2016

@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
Copy link
Contributor

jonathandturner commented Nov 7, 2016

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
Copy link
Contributor

jonathandturner commented Nov 7, 2016

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

@brson
Copy link
Contributor Author

brson commented Nov 7, 2016

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 brson force-pushed the brson:relnotes-1.13 branch from a8a012f to a4e8e07 Nov 7, 2016
@brson
Copy link
Contributor Author

brson commented Nov 7, 2016

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
Copy link
Contributor Author

brson commented Nov 7, 2016

I'm going to port this to beta now.

@brson brson force-pushed the brson:relnotes-1.13 branch from a4e8e07 to 6a5682e Nov 7, 2016
@brson brson force-pushed the brson:relnotes-1.13 branch from 6a5682e to 0f817a0 Nov 7, 2016
@brson brson removed the beta-nominated label Nov 8, 2016
@brson
Copy link
Contributor Author

brson commented Nov 8, 2016

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

@Mark-Simulacrum
Copy link
Member

Mark-Simulacrum commented Nov 8, 2016

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
Copy link
Member

retep998 commented Nov 8, 2016

@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
Copy link
Member

bluss commented Nov 8, 2016

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).

* [Stabilize the `?` operator][36995]. `?` is a simple way to propagate
errors, like the `try!` macro, described in [RFC 0243].
* [Stabilize macros in type position][36014]. Described in [RFC 873].
* [Stabilize attributes on statements][36995]. Described in [RFC 0016].

This comment has been minimized.

@Razican

Razican Nov 9, 2016 Contributor

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

This comment has been minimized.

@brson

brson Nov 9, 2016 Author Contributor

Yes. They were stabilized in the same PR.

@brson
Copy link
Contributor Author

brson commented Nov 9, 2016

@CryZe
Copy link
Contributor

CryZe commented Nov 9, 2016

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
Copy link
Member

bluss commented Nov 10, 2016

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

@CryZe
Copy link
Contributor

CryZe commented Nov 10, 2016

@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
Copy link
Member

bluss commented Nov 10, 2016

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
Copy link

mrageh commented Nov 10, 2016

Hey Folks

any ideas on when 1.13 will be stable?

@jonathandturner
Copy link
Contributor

jonathandturner commented Nov 10, 2016

@alexcrichton
Copy link
Member

alexcrichton commented Nov 10, 2016

@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
Copy link
Contributor Author

brson commented Nov 11, 2016

Yeah this needs an r+.

@alexcrichton
Copy link
Member

alexcrichton commented Nov 11, 2016

@bors: r+

Ok!

@bors
Copy link
Contributor

bors commented Nov 11, 2016

📌 Commit 0f817a0 has been approved by alexcrichton

eddyb added a commit to eddyb/rust that referenced this pull request Nov 11, 2016
Add changelog for 1.13.0

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](https://gist.github.com/brson/1404c4bf4868d7d108f240a6ecba7f31).

This desires to be backported to beta for 1.13.

Sadly, the [1.12.1 changelog PR](rust-lang#37317) has not merged to master yet, and is sitting in a [rollup PR](rust-lang#37597).

r? @rust-lang/lang @rust-lang/compiler @rust-lang/libs @rust-lang/core
bors added a commit that referenced this pull request Nov 12, 2016
Rollup of 29 pull requests

- Successful merges: #37190, #37368, #37481, #37503, #37527, #37535, #37545, #37551, #37584, #37600, #37615, #37659, #37662, #37669, #37682, #37688, #37690, #37692, #37693, #37694, #37695, #37696, #37698, #37699, #37705, #37708, #37709, #37716, #37724
- Failed merges: #37640, #37689
eddyb added a commit to eddyb/rust that referenced this pull request Nov 12, 2016
Add changelog for 1.13.0

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](https://gist.github.com/brson/1404c4bf4868d7d108f240a6ecba7f31).

This desires to be backported to beta for 1.13.

Sadly, the [1.12.1 changelog PR](rust-lang#37317) has not merged to master yet, and is sitting in a [rollup PR](rust-lang#37597).

r? @rust-lang/lang @rust-lang/compiler @rust-lang/libs @rust-lang/core
bors added a commit that referenced this pull request Nov 12, 2016
@bors bors merged commit 0f817a0 into rust-lang:master Nov 12, 2016
1 check failed
1 check failed
continuous-integration/travis-ci/pr The Travis CI build failed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

You can’t perform that action at this time.