Rust 1.12 release announcement #126
Conversation
|
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
|
|
||
| ### What's in 1.12.0 stable | ||
|
|
||
| Oh my god! So much stuff! |
There was a problem hiding this comment.
Ha! I think brson put this in as a joke. I don't mind something fun here since there is a lot of stuff in this release, but maybe "Oh my god!" is a step too far.
There was a problem hiding this comment.
Yeah, I just imported the raw text for now 😄 I've just pushed a commit that re-works the intro a bit.
| excited to see what you think of them: | ||
|
|
||
|  |
There was a problem hiding this comment.
Do we want to use the same trait error in both this section and the expanded section below? Might read better to have pictures of a different kind of error here.
|
|
||
| With 1.12 we're introducing a new error format which helps to surface a lot of | ||
| the internal knowledge about why an error is occurring to you, the developer. It | ||
| does this by focusing on your code, and the points of interest in your code that |
There was a problem hiding this comment.
i would put it here, but i over-comma, so 👍
| The new Rust "mid-level IR", usually called "MIR", gives the compiler a simpler | ||
| way to think about Rust code than it's previous way of operating entirely on the | ||
| Rust abstract syntax tree. It makes analysis and optimizations possible that | ||
| have previously been difficult to implement correctly. The first of many |
There was a problem hiding this comment.
We just said "previous" in the sentence prior. Maybe "that would otherwise have been difficult to implement correctly"
There was a problem hiding this comment.
giving "historically" a try
| but this resulted in significant extra memory being used at runtime. | ||
|
|
||
| MIR exposes perfect information about the program's control flow, so the | ||
| compiler knows exactly whether types are moved or not, in which case it knows |
| hyper.0.5.0 24.03s 5.23s -78.2% | ||
| helloworld 0.17s 0.14s -16.4% | ||
| regex.0.1.30 9.63s 2.39s -75.2% | ||
| ``` |
There was a problem hiding this comment.
We were thinking of this being a table. We may also want to turn the negative percentages into a column called "compile time" and change the percentage to a multiplier of improvement. Maybe something like:
2.35x faster
4.58x faster
1.20x faster
4.03x faster
|
|
||
| ### Contributors to 1.12.0 | ||
|
|
||
| We had 176 individuals contribute to 1.12.0. Thank you so much! |
There was a problem hiding this comment.
Do we want to point out how many more people are in this one than before? Looking at 1.11 we had 126 and 1.10 had 139. It's not like an order of magnitude more, but the bump is noticeable at least.
There was a problem hiding this comment.
I am of two minds. It will then be conspicuously absent in the future 😉
|
I'm increasingly feeling that the initial error should be different than the one we use in the description. What's the best error message we've seen so far? |
|
@steveklabnik - lemme poke around the 1.12 release and see if there's a good one we can use. Will report back |
|
|
||
| The Rust team is happy to announce the latest version of Rust, 1.12.0. Rust is | ||
| a systems programming language with the slogan "fast, safe, concurrent: pick | ||
| three." |
There was a problem hiding this comment.
I'm warming to Aaron's "Safe, fast, convenient"(?) especially since we're talking about some of the convenience improvements in this post.
There was a problem hiding this comment.
I thought it was concurrent. I'm also happy to switch it to whatever. @aturon ?
| passes in LLVM to reason about. The end result is less work for the compiler and | ||
| less bloat at runtime. | ||
|
|
||
| The improvements in compile times of some workloads due to this change alone are |
There was a problem hiding this comment.
Does "this change" refer to static drop, or to MIR trans?
There was a problem hiding this comment.
@brson mentioned yesterday this was from the non-zeroing drop. Brian, can we confirm that?
There was a problem hiding this comment.
I figured two tables here made more sense. Maybe we should also change to the "1.x faster" style? @jonathandturner can you do that math real quick? I always mess it up.
| | inflate-0.1.0 | 10.17s | 4.32s | -57.5% | | ||
| | hyper.0.5.0 | 24.03s | 5.23s | -78.2% | | ||
| | helloworld | 0.17s | 0.14s | -16.4% | | ||
| | regex.0.1.30 | 9.63s | 2.39s | -75.2% | |
There was a problem hiding this comment.
I'm betting you're just moving things around, but wanted to have a FIXME that this is the same table as the one above, just with a different last column.
There was a problem hiding this comment.
👍 I actually didn't totally realize that, i was just transcribing from the irccloud link
| less bloat at runtime. | ||
|
|
||
| The improvements in compile times of some workloads due to this change alone are | ||
| significant: |
There was a problem hiding this comment.
We may also want to say something to the effect "though not all workloads will see these improvements" or something to help set expectations. I don't want people to be like "but 1.12 doesn't compile my codebase 4.5x faster :( :("
| | inflate-0.1.0 | 175MB | 135MB | -22.9% | | ||
| | hyper.0.5.0 | 321MB | 302MB | -5.9% | | ||
| | helloworld | 127MB | 90MB | -29.1% | | ||
| | regex.0.1.30 | 230MB | 194MB | -15.7% | |
There was a problem hiding this comment.
| 1.11 | 1.12 | % of orig size | |
|---|---|---|---|
| inflate-0.1.0 | 175MB | 135MB | 77.1% |
| hyper.0.5.0 | 321MB | 302MB | 94.1% |
| helloworld | 127MB | 90MB | 70.9% |
| regex.0.1.30 | 230MB | 194MB | 84.3% |
|
@steveklabnik - here are some other possibilities. I can give you the hi-res original to use:
|
| * Bastien Dejean | ||
| * Ben Boeckel | ||
| * Ben Stern | ||
| * bors |
There was a problem hiding this comment.
bots are people too! @bors has been credited in every release so far. They work really hard!
|
also have to integrate the smaller stuff from https://raw.githubusercontent.com/brson/rust/relnotes/RELEASES.md |
| update every one of `rustc`s errors to the new format. We're excited to see | ||
| what you think of them: | ||
|
|
||
|  |
There was a problem hiding this comment.
In the preview this image looks hella big :) We may want to scale it down a bit
There was a problem hiding this comment.
psssh loud and proud! :p
There was a problem hiding this comment.
Hehe, the other new error image is also a bit big (though not as big as this one)
| |---------------|--------|-------|--------------| | ||
| | inflate-0.1.0 | 10.17s | 4.32s | 2.35x faster | | ||
| | hyper-0.5.0 | 24.03s | 5.23s | 4.58x faster | | ||
| | hellworld | 0.17s | 0.14s | 1.20x faster | |
There was a problem hiding this comment.
I... wouldn't want to name my program that. Perhaps you meant helloworld?
| To maintain the semantics of Rust's `Drop` implementation, we always need to | ||
| check whether a type must be dropped when it goes out of scope. Historically, | ||
| this has been done by adding a special flag to all types that implement `Drop`, | ||
| but this resulted in significant extra memory being used at runtime. |
There was a problem hiding this comment.
This paragraph and the one before need to go (although you can say that MIR doesn't need to fill memory with a specific byte pattern to know when to drop values), as the full removal of old trans and drop flags is only in 1.13.
There was a problem hiding this comment.
@eddyb - we saw the compile time performance from perf.rust-lang.org. How would you describe what happened between 1.11 and 1.12 to improve compile-time performance?
There was a problem hiding this comment.
The MIR backend is barely faster - however it's possible some of @nikomatsakis performance improvements to type/trait-related instrumentation to be in there, warrants further investigation.
There was a problem hiding this comment.
I am removing these paras but we should talk about it.
| don't match: | ||
|
|
||
|  |
There was a problem hiding this comment.
Please use a screenshot which doesn't include the //~ comments from the test suite. Otherwise, it looks like errors are printed twice.
There was a problem hiding this comment.
@jonathandturner mind sending a PR to my PR with new screenshots?
|
|
||
| The largest internal change in this release is moving to a new compiler backend | ||
| based on the new Rust [MIR]. While this feature does not result in any new | ||
| user-visible features, it paves the way for a number of future compiler |
There was a problem hiding this comment.
Repeating the word "feature" sounds weird, I would change the first occurrence to "change".
| #### MIR code generation | ||
|
|
||
| The new Rust "mid-level IR", usually called "MIR", gives the compiler a simpler | ||
| way to think about Rust code than it's previous way of operating entirely on the |
| error](/images/2016-09-Rust-1.12/old-mismatched-trait-error.png) | ||
|
|
||
| In the new error format we represent the error by instead showing the points in | ||
| the code that matter the most. Here the relevant line in the trait declaration, |
There was a problem hiding this comment.
There's a missing word after "Here" -- "is" or "it shows"?
| error](/images/2016-09-Rust-1.12/mismatched-trait-error.png) | ||
|
|
||
| Initially, this error design was built to aid borrow-checking errors, but we | ||
| found, like the error above, the format can be broadly applied to a wide variety |
|  | ||
|
|
||
| Initially, this error design was built to aid borrow-checking errors, but we |
| #### MIR code generation | ||
|
|
||
| The new Rust "mid-level IR", usually called "MIR", gives the compiler a simpler | ||
| way to think about Rust code than it's previous way of operating entirely on the |
| | inflate-0.1.0 | 175MB | 135MB | 77.1% | | ||
| | hyper.0.5.0 | 321MB | 302MB | 94.1% | | ||
| | helloworld | 127MB | 90MB | 70.9% | | ||
| | regex.0.1.30 | 230MB | 194MB | 84.3% | |
There was a problem hiding this comment.
Is this the memory usage of rustc or of the compiled program? Might want to clarify that.
There was a problem hiding this comment.
I think it is better to use the percent decrease with a minus sign, I initially wondered if the MIR transition were that good.
| |---------------|--------|-------|---------------| | ||
| | inflate-0.1.0 | 10.17s | 4.32s | 2.35x faster | | ||
| | hyper-0.5.0 | 24.03s | 5.23s | 4.58x faster | | ||
| | helloworld | 0.17s | 0.14s | 1.20x faster | |
There was a problem hiding this comment.
The | is not aligned in the markdown here.
I'd like to elaborate a bit more on cargo stuff
| | | 1.11 | 1.12 | compile time | | ||
| |---------------|--------|-------|--------------| | ||
| | inflate-0.1.0 | 10.17s | 4.32s | 2.35x faster | | ||
| | hyper-0.5.0 | 24.03s | 5.23s | 4.58x faster | |
There was a problem hiding this comment.
I'm trying to reproduce this, but so far I'm not seeing this improvement.
"cargo build" of a project that depends on hyper 0.5.0:
1.11: 0m26.975s
beta: 0m31.901s
"cargo build --release" of a project that depends on hyper 0.5.0:
1.11: 0m40.412s
beta: 0m43.502s
Does anyone know how to repro this chart? @eddyb? @nikomatsakis?
There was a problem hiding this comment.
I should mention that I got the table numbers from perf.rust-lang.org
There was a problem hiding this comment.
FIXME FIXME FIXME FIXME FIXME
WARNING WARNING WARNING
The perf numbers could not be verified. It seems perf.rust-lang.org was giving us bogus values. We tried to repro the improvements and were not able to.
We'll need to remove these, sadly :(
On the plus side, I did see improvements compared to nightly, so there are some improvements coming. They're just not in 1.12.
There was a problem hiding this comment.
@jonathandturner The improvements you are seeing in nightly are likely due to rust-lang/rust#36524
| | | 1.11 | 1.12 | compile time | | ||
| |---------------|--------|-------|--------------| | ||
| | inflate-0.1.0 | 10.17s | 4.32s | 2.35x faster | | ||
| | hyper-0.5.0 | 24.03s | 5.23s | 4.58x faster | |
There was a problem hiding this comment.
FIXME FIXME FIXME FIXME FIXME
WARNING WARNING WARNING
The perf numbers could not be verified. It seems perf.rust-lang.org was giving us bogus values. We tried to repro the improvements and were not able to.
We'll need to remove these, sadly :(
On the plus side, I did see improvements compared to nightly, so there are some improvements coming. They're just not in 1.12.
|
|
||
| The largest internal change in this release is moving to a new compiler backend | ||
| based on the new Rust [MIR]. While this feature does not result in anything | ||
| user-visible, it paves the way for a number of future compiler optimizations, |
|
|
||
| With 1.12 we're introducing a new error format which helps to surface a lot of | ||
| the internal knowledge about why an error is occurring to you, the developer. It | ||
| does this by focusing on your code and the points of interest in your code that |
There was a problem hiding this comment.
"It does this by putting your code front and center, highlighting the parts relevant to the error with annotations describing what went wrong"
| (https://github.com/rust-lang/rust/pull/35060). | ||
| These targets produce statically-linked binaries. There are no binary release | ||
| builds yet though. | ||
| * In error descriptions, |
| * [`Cell::as_ptr`](https://doc.rust-lang.org/std/cell/struct.Cell.html#method.as_ptr) | ||
| and | ||
| [`RefCell::as_ptr`](https://doc.rust-lang.org/std/cell/struct.RefCell.html#method.as_ptr) | ||
| * `IpAddr`, `Ivp4Addr`, and `Ipv6Addr` have a few new methods. |
There was a problem hiding this comment.
They're all separate, and there's a ton of them. Not sure how best to do the links here.
|
|
||
| Cargo has some modest improvments: | ||
|
|
||
| * [Support local mirrors of |
There was a problem hiding this comment.
This one seems like a biggie -- maybe worth pulling out into a brief paragraph? Maybe talk to @alexcrichton about it?
There was a problem hiding this comment.
Ah yeah, how about something like:
The biggest feature added to Cargo this cycle is the ability to [override the source of a crate](link here). Using this tools like cargo-vendor and cargo-local-registry allow vendoring dependencies locally in a robust fashion. Eventually this support will be the foundation of supporting mirrors of crates.io as well.
There was a problem hiding this comment.
Sounds great. I wanted to do this, but it got lost in the rest of it.
| user-visible, it paves the way for a number of future compiler optimizations, | ||
| and for some codebases it already results in improvements to compile times and | ||
| reductions in code size. | ||
| user-visible today, but it paves the way for a number of future compiler |
There was a problem hiding this comment.
nice catch, thank you
|
Okay, I think this is good to go. @rust-lang/core? |
|
👍 @brson is doing the final prep for the release right now in terms of artifacts I believe, and after that should be good to go |
Not ready to merge yet, of course.
rendered