A pretty big performance hit after a recent change (PR #51361)

[ljedrz]

Browsing the perf page I noticed a pretty big regression:

coercions-check | avg: 58.3%? | min: 31.0%? | max: 106.3%?
coercions-opt | avg: 31.8%? | min: 22.9%? | max: 49.1%?
coercions-debug | avg: 26.9%? | min: 19.8%? | max: 45.9%?
tuple-stress-check | avg: 31.7% | min: 9.0% | max: 43.4%
tuple-stress-opt | avg: 15.9% | min: 13.1% | max: 18.0%
tuple-stress-debug | avg: 15.7% | min: 12.9% | max: 18.0%

I have tracked it down to one of these changes. This might be a necessary evil, but I'd rather make sure.

cc @RalfJung, @oli-obk

[RalfJung]

Are these CTFE-heavy crates? Still it's somewhat strange as only the final result of CTFE is supposed to be checked, not every intermediate value. (That's something I wanted to add, actually, but maybe that should be a miri-only feature.)

I opened #52291 because I wasn't sure we are stressing CTFE enough in perf, but maybe we are?

[kennytm]

tuple-stress is a 2.4 MB source file consisting of a static array of length 65535.

static BIG_ARRAY_OF_TUPLES: [(i32, (f64, f64, f64)); 0xffff] = [
    (641161, (2.988, 10.544, 29.598)),
    ...
    (209150, (5.216, 15.229, 23.389)),
];

fn main() {
    assert!(BIG_ARRAY_OF_TUPLES.len() == 0xffff);
}

coercions is a similar 1.8 MB file again with a 65535-length array.

pub static MAPPING: [&'static str; 0xffff] = [
    "\u{0}",
    ...
    "",
];

fn main() { }

[oli-obk]

Yea. A regression there is pretty much expected. But we can do better. Right now we'd keep reopening the allocation at least 2^20 times in the tuple-stress case.

We should move a bunch of methods from Memory to Allocation and just keep working the Allocation.

Candidates are the methods reading integers, pointers or primvals in general

[RalfJung]

Right now we'd keep reopening the allocation at least 2^20 times in the tuple-stress case.

That's just get_mut though, right?

[oli-obk]

get, and only transitively. But in order to not keep hitting it we'd need to move all the other methods that ever end up calling get to Allocation and a bunch of other methods, too, e.g. check_bounds or check_align, which are called almost every time get is

[RalfJung]

a 2.4 MB source file consisting of a static array of length 65535

Ah, so it's just a big constant.
Still, 64k is not such a big number for a machine, I am surprised it makes such a big impact.

[RalfJung]

This looks like the same regression: The following code regressed from the previous nightly (2018-07-24) to today's (2018-07-30):

#![feature(const_fn, const_let)]

// Try to make CTFE actually do a lot of computation, without producing a big result.
// And without support for loops.

macro_rules! const_repeat {
    // Recursive case: Take a 16
    ([16 $($n: tt)*] $e: expr, $T: ty) => {{
        const fn e() -> $T { const_repeat!([$($n)*] $e, $T) }
        e(); e(); e(); e();
        e(); e(); e(); e();
        e(); e(); e(); e();
        e(); e(); e(); e()
    }};
    // Recursive case: Take a 2
    ([2 $($n: tt)*] $e: expr, $T: ty) => {{
        const fn e() -> $T { const_repeat!([$($n)*] $e, $T) }
        e(); e()
    }};
    // Base case
    ([] $e: expr, $T: ty) => {$e};

    // 16^4 * 2^2 = 2^(4*4+2) = 2^18 = 256k repetitions
    ($e: expr, $T: ty) => (const_repeat!([16 16 16 16 2 2] $e, $T));
}
macro_rules! expensive_static {
    ($name: ident : $T: ty = $e : expr) =>
        (pub static $name : $T = const_repeat!($e, $T);)
}

pub trait Trait: Sync {}
impl Trait for u32 {}
const fn nop<T>(t: T) -> T { t }
const fn inc(i: i32) -> i32 { i + 1 }

expensive_static!(RELOCATIONS : &'static str = "hello");
expensive_static!(FIELDS: &'static i32 = &("bar", 42, "foo", 3.14).1);
expensive_static!(CHECKED_INDEX: u8 = b"foomp"[3]);
expensive_static!(UNSIZING: &'static [u8] = b"foo");
expensive_static!(UNSIZE_TRAIT: &'static Trait = &42u32);
expensive_static!(CHAIN: usize = 42i32 as u8 as u64 as i8 as isize as usize);
expensive_static!(OPS: i32 = ((((10 >> 1) + 3) * 7) / 2 - 12) << 4);
expensive_static!(FORCE_ALLOC: i32 = *****(&&&&&5));
expensive_static!(CONST_FN_BASELINE: i32 = nop(42));
expensive_static!(CONST_FN_SIMPLE: i32 = inc(42));

Old:13s
New: 29s

With 2^20 runs, it doesn't even seem to terminate at all now (5min and still going, likely in FIELDS), whereas it is 50s previously. This is strange because behavior otherwise seemed linear.

That's definitely fishy, because the final constant (that is supposed to be sanity checked only) is pretty small.

[RalfJung]

Is it possible that it is now doing something for every allocation, even those that are not reachable from the final constant? That would explain why FIELDS specifically got slower.

[RalfJung]

Interestingly, the "it diverges" part of the regression goes away when I change the macro to just repeat $e 16 times for the innermost part -- instead of wrapping it in a const fn and calling that 16 times.

Function calls seem to have regressed a lot.

Also, according to perf, all that time it diverges is spent hashing. Might be related to #51702? However, the "good" nightly 2018-07-24 already contains that PR as well.

[nnethercote]

Presumably the "Sanity-check all constants" commit is the one responsible, given that coercions and tuple-stress both contains enormous constants.