arielb1
commented
7 years ago Can confirm.
Semi-minified code (not to depend on formatters which generate tons of junk IR - plz fix @eddyb by introducing ):
#![crate_type="rlib"]
/// Audio sample rate for the test set, used for realtime speed
/// calculation
const SAMPLE_RATE: f64 = 48000.0;
/// Total length of samples the filter benchmarks are ran on
const SAMPLE_COUNT: u64 = 524288;
/// Select how many IIR filters should be applied consecutively
/// on each buffer during the benchmark
const FILTER_COUNT: usize = 100;
const BUFFER_LEN: usize = 128;
/// 2nd order biquad filter
#[derive(Copy)]
struct Biquad {
b0: f64,
b1: f64,
b2: f64,
a1: f64,
a2: f64,
x1: f64,
x2: f64,
y1: f64,
y2: f64,
}
impl Clone for Biquad {
fn clone(&self) -> Biquad {
*self
}
}
impl Biquad {
fn new() -> Biquad {
Biquad {
b0: 0.0,
b1: 0.0,
b2: 0.0,
a1: 0.0,
a2: 0.0,
x1: 0.0,
x2: 0.0,
y1: 0.0,
y2: 0.0,
}
}
}
fn iir(buf: &mut [f64], bq: &mut Biquad) {
for i in 0..buf.len() {
let x = buf[i];
buf[i] = (bq.b0 * x) + (bq.b1 * bq.x1) + (bq.b2 * bq.x2) - (bq.a1 * bq.y1) -
(bq.a2 * bq.y2);
bq.x2 = bq.x1;
bq.x1 = x;
bq.y2 = bq.y1;
bq.y1 = buf[i];
}
}
#[cfg(slow)]
pub fn foo() {
println!("Create an empty vector, resized then discarded");
let mut vec_test: Vec<f64> = Vec::new();
vec_test.resize(1234, 0.0);
}
#[inline(never)]
pub fn sample(buffer_len: usize) {
let buffer_count = SAMPLE_COUNT / buffer_len as u64;
for _ in 0..10 {
let mut buf = vec![0.0; buffer_len];
let mut biquads = [Biquad::new(); FILTER_COUNT];
for _ in 0..buffer_count {
for f in 0..FILTER_COUNT {
iir(buf.as_mut_slice(), &mut biquads[f]);
}
}
}
}The fast inner loop looks like:
bb7.i: ; preds = %bb7.i, %bb22
%.in87 = phi double [ %.pre14.i, %bb22 ], [ %236, %bb7.i ]
%232 = phi double [ %.pre.i, %bb22 ], [ %249, %bb7.i ]
%iter.sroa.0.013.i = phi i64 [ 0, %bb22 ], [ %234, %bb7.i ]
%233 = phi <2 x double> [ %226, %bb22 ], [ %248, %bb7.i ]
%234 = add nuw i64 %iter.sroa.0.013.i, 1
%235 = getelementptr inbounds double, double* %212, i64 %iter.sroa.0.013.i
%236 = load double, double* %235, align 8
%237 = fmul double %232, %227
%238 = fmul double %236, %228
%239 = fmul double %.in87, %229
%240 = fadd double %238, %239
%241 = fmul <2 x double> %233, %231
%242 = extractelement <2 x double> %241, i32 0
%243 = fadd double %240, %242
%244 = extractelement <2 x double> %241, i32 1
%245 = fsub double %243, %244
%246 = fsub double %245, %237
store double %246, double* %235, align 8
%exitcond.i = icmp eq i64 %234, %local_len.sroa.4.0.lcssa26.i.i
%247 = insertelement <2 x double> undef, double %.in87, i32 0
%248 = insertelement <2 x double> %247, double %246, i32 1
%249 = extractelement <2 x double> %233, i32 1
br i1 %exitcond.i, label %bb17.loopexit, label %bb7.i
bb17.loopexit: ; preds = %bb7.i
store double %236, double* %217, align 8
%216 = add nuw nsw i64 %iter4.sroa.0.080, 1
store double %.in87, double* %218, align 8
store double %246, double* %219, align 8
store double %249, double* %220, align 8
%exitcond = icmp eq i64 %216, 100
br i1 %exitcond, label %bb12.loopexit.loopexit, label %bb22And the slow one looks like (notice the additional, un-extracted stores - looks like some aliasing issue):
bb7.i: ; preds = %bb7.i, %bb22
%.in = phi double [ %.pre14.i, %bb22 ], [ %239, %bb7.i ]
%235 = phi double [ %.pre.i, %bb22 ], [ %250, %bb7.i ]
%iter.sroa.0.013.i = phi i64 [ 0, %bb22 ], [ %237, %bb7.i ]
%236 = phi <2 x double> [ %231, %bb22 ], [ %252, %bb7.i ]
%237 = add nuw i64 %iter.sroa.0.013.i, 1
%238 = getelementptr inbounds double, double* %buf.sroa.0.0.copyload, i64 %iter.sroa.0.013.i
%239 = load double, double* %238, align 8
%240 = fmul double %235, %.pre
%241 = fmul double %239, %.pre86
%242 = fmul double %.in, %.pre87
%243 = fadd double %241, %242
%244 = fmul <2 x double> %236, %233
%245 = extractelement <2 x double> %244, i32 0
%246 = fadd double %243, %245
%247 = extractelement <2 x double> %244, i32 1
%248 = fsub double %246, %247
%249 = fsub double %248, %240
store double %249, double* %238, align 8
store double %.in, double* %223, align 8
store double %239, double* %222, align 8
%250 = extractelement <2 x double> %236, i32 1
store double %250, double* %225, align 8
store double %249, double* %224, align 8
%exitcond.i = icmp eq i64 %237, %buf.sroa.8.0.copyload
%251 = insertelement <2 x double> undef, double %.in, i32 0
%252 = insertelement <2 x double> %251, double %249, i32 1
br i1 %exitcond.i, label %bb17.backedge, label %bb7.i
bb17.backedge: ; preds = %bb7.i
%234 = add nuw nsw i64 %iter4.sroa.0.080, 1
%exitcond = icmp eq i64 %234, 100
br i1 %exitcond, label %bb12.loopexit.loopexit, label %bb22
bluss
supercurio
QIvan
clubby789
A bug introduced with rustc 1.12.0 with MIR enabled. This was originally reported imprecisely as #40044
If anywhere in the code a vector is either resize() or extend_from_slice(), any algorithms operating on any other vector will run slower. The performance impact varies with the compiler targets and CPU characteristics.
Real world examples measured on an audio DSP algorithm
armv7
Raspberry Pi 3, Rustc 1.12.0: 14% slower Raspberry Pi 3, Rustc 1.15.1: 11% slower Nexus 5, Rustc 1.15: 1% slower
arm
Raspberry Pi, Rustc 1.15.1: 8% slower
x86-64
Core i5-750, Rustc 1.12.1 or Rustc 1.15.1: 0.4% slower
When compiling using Rustc 1.12.0 with MIR disabled, the performance regression does not occur.
Test and demo project
https://github.com/supercurio/rust-issue-mir-vec-slowdown