MIR CopyPropagation is slow #36673
Comments
|
I figured out how to install older nightly versions with rustup - I'm going to try searching for the problem |
|
Is the code available somewhere (or a smaller reproduction of the bug)? Can you try running with |
|
I can definitely send the code in private, but unfortunately I can't make it publicly available at this point. I'd be more than happy to send you a targz (or some other format, if you prefer) I'll try a few different versions to see where it happens, and measure time-passes of the affected version(s) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
|
|
Oops, you're quite right. This is that: |
|
cc @pcwalton |
|
Is there anything I can do to help? |
nikomatsakis
added
I-nominated
I-compiletime
|
Nominated to discuss priority. Marked as regression. |
pnkfelix
added
regression-from-stable-to-beta
|
@chrivers You said that you were not willing to post the code publicly, but that you are willing to send it via some private channel? If you have some reduced test case to share, are you willing to share it with all the members of the rust compiler team? Or is there some non-disclosure agreement issues in play? |
|
I haven't really been able to figure out what causes this, but I believe it could be because I'm building a large-ish structure in memory. I actually ended up creating a template compiler just for this (kind of) use case: https://github.com/chrivers/transwarp It's nothing super secret at all, and sharing it with the rust language team is certainly fine. Just as long as it doesn't hit google, that's no problem :) There are some licensing terms I have to clear, before putting it on github. But nothing that prevents me from sharing it with a closed group of experts, certainly. @pnkfelix can you email me? I can send you a tarball |
|
Nominating to discuss how to fix this in compiler team mtg. |
|
Please assign someone. |
|
I think we should probably comment out the copy-propagation fix at least for beta:
But we should separately be moving on improving the performance/correctness of CopyPropagation, which is definitely an important thing to have. |
|
|
|
@arielb1 ah ok I was under the impression it did not do that yet. I have to go re-read the code. |
|
Conclusion from meeting: Proper fix then for nightly would be to try to cache work here, but for the beta branch an easy short-term fix is to disable copy-prop. I'll assign myself the beta PR. |
|
Monday is probably the cutoff for backporting to beta if this isn't in already. |
|
The test crate in question does not compile out of the box with the beta branch itself (it uses features only available on nightly). However, good news: The point in my experiments where the speed became acceptable again was the nightly from sept 27, which is this commit: d0623cf That commit, if I understand the output of |
|
triage: P-medium It is still a mystery why this is a problem, but not a burning issue at this point. |
|
Here is a small test case adapted from a vast reduction of the code that @chrivers sent. (In this reduction, I have left in some seemingly unrelated details, such as repeated calls to // one_file.rs
fn bit() -> Option<bool> { unimplemented!() }
macro_rules! def_thing_fields {
( { $($field:ident,)* } )
=>
{
pub struct Thing { $(pub $field: (),)* }
pub fn go()
{
Thing
{
$(
$field:
{
println!("Thing");
println!("{}", "Thing");
println!("{}", stringify!($field));
let b = match bit() {
Some(x) => x,
None => return,
};
if b {
let result = match bit() {
Some(x) => x,
None => return,
};
println!("next_bit -> {:?}", result);
}
}
),*
};
}
}
}
fn main() {
}
def_thing_fields! {
{
a00, a01, a02, a03, a04, a05, a06, a07, a08, a09,
a10, a11, a12, a13, a14, a15, a16, a17, a18, a19,
a20, a21, a22, a23, a24, a25, a26, a27, a28, a29,
a30, a31, a32, a33, a34, a35, a36, a37, a38, a39,
a40, a41, a42, a43, a44, a45, a46, a47, a48, a49,
a50, a51, a52, a53, a54, a55, a56, a57, a58, a59,
a60, a61, a62, a63, a64, a65, a66, a67, a68, a69,
a70, a71, a72, a73, a74, a75, a76, a77, a78, a79,
a80, a81, a82, a83, a84, a85, a86, a87, a88, a89,
a90, a91, a92, a93, a94, a95, a96, a97, a98, a99,
}
}Here are timing results showing that the same compilers I tested above show an analogous change in speed for this test case: |
|
Ah! Someone mentioned in the meeting that the time spent in Here's data that reflects this: (and with that knowledge, it seems obvious now why the problem "went away" -- pcwalton's commit 79cb2db deliberately avoids running the |
|
@brson the short version of all of this that I do not think there is anything that needs to be backported to beta at this point. |
arielb1
changed the title
arielb1
removed
the
regression-from-stable-to-beta
|
We untagged this as a regression but kept the issue open since we would like to eventually make copy-prop fast |
|
FYI: copy propagation has moved to -Zmir-opt-level=2 (default is 1) |
Mark-Simulacrum
added
the
C-enhancement
Don't actually create a full MIR stack frame when not needed r? @dotdash This should significantly reduce overhead during const propagation and reduce overhead *after* copy propagation (cc rust-lang#36673)
Don't actually create a full MIR stack frame when not needed r? @dotdash This should significantly reduce overhead during const propagation and reduce overhead *after* copy propagation (cc rust-lang#36673)
Hello everyone
I've tried searching for a github issue that reports this, but I couldn't find anything, so I hope this isn't a duplicate. I'm on nightly, since my project uses type macros. Overall, there is a good amount of macro expansion going on, since I build parsers for binary data based on structs.
Compilation time for a 5500 LOC project has been around 7-9 seconds on my Core i7-4770, going a bit up and down with changes in the project, and changes in nightly.
However, today this changed very drastically:
[chrivers@helios]~/git/artemis/oxide #cargo build
Compiling oxide v0.1.0 (file:///home/chrivers/git/artemis/oxide)
Finished debug [unoptimized + debuginfo] target(s) in 21.94 secs
This is more than twice as slow as before! Something pretty significant must have happened.
This version is definitely affected:
rustc 1.13.0-nightly (4f9812a59 2016-09-21)Honestly, I'm not quite sure when it worked, but I can say that the version I used yesterday, which was probably no more than 1 week old, worked much better.
The text was updated successfully, but these errors were encountered: