Skip to content

miri interpretation of large array initialization is slow #49199

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

Open
2 tasks
oli-obk opened this issue Mar 20, 2018 · 1 comment
Open
2 tasks

miri interpretation of large array initialization is slow #49199

oli-obk opened this issue Mar 20, 2018 · 1 comment
Labels
A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) A-MIR Area: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.html A-mir-opt Area: MIR optimizations A-miri Area: The miri tool C-enhancement Category: An issue proposing an enhancement or a PR with one. C-optimization Category: An issue highlighting optimization opportunities or PRs implementing such I-compiletime Issue: Problems and improvements with respect to compile times. I-slow Issue: Problems and improvements with respect to performance of generated code. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@oli-obk
Copy link
Contributor

oli-obk commented Mar 20, 2018

Right now, if you are initializing a large array either manually or with an array repeat expression takes a long time during interpretation.

Arrays with lots of fields that are initialized as

static FOO: [T; N] = [A, B, C, ....., XX, XY];

are turned into the MIR equivalent of

static FOO: [T; N] = {
let array: [T; N] = mem::uninitialized();
let a = A;
let b = B;
let c = C;
....
let xx = XX;
let xy = XY;
array = [A, B, C, ...., XX, XY];
array
}

Which requires twice the memory (once for each variable and once for the array) and twice the instructions (initializing the variables and copying each variable into the array).

  • Instead, we should turn that MIR into
static FOO: [T; N] = {
let array: [T; N] = mem::uninitialized();
array[0] = A;
array[1] = B;
array[2] = C;
....
array[N-2] = XX;
array[N-1] = XY;
array
}

What do you think @eddyb ?

cc @Zoxc @bob_twinkles @rkruppe

@oli-obk oli-obk added the I-slow Issue: Problems and improvements with respect to performance of generated code. label Mar 20, 2018
@eddyb
Copy link
Member

eddyb commented Mar 20, 2018

@oli-obk That is part of removing Rvalue::Aggregate, which I want to do at some point.
The plan, wrt borrowck, is to have a SetDiscriminant(array, 0) to indicate the value is fully initialized.
Sadly, just doing the optimization after the fact is pretty expensive itself, see #48193.
cc @nikomatsakis

@oli-obk oli-obk added the A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) label Apr 26, 2018
@XAMPPRocky XAMPPRocky added C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 26, 2018
@oli-obk oli-obk self-assigned this Jan 28, 2019
@jonas-schievink jonas-schievink added I-compiletime Issue: Problems and improvements with respect to compile times. A-MIR Area: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.html A-mir-opt Area: MIR optimizations A-miri Area: The miri tool labels Apr 6, 2020
@oli-obk oli-obk removed their assignment Jul 7, 2022
@workingjubilee workingjubilee added the C-optimization Category: An issue highlighting optimization opportunities or PRs implementing such label Oct 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) A-MIR Area: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.html A-mir-opt Area: MIR optimizations A-miri Area: The miri tool C-enhancement Category: An issue proposing an enhancement or a PR with one. C-optimization Category: An issue highlighting optimization opportunities or PRs implementing such I-compiletime Issue: Problems and improvements with respect to compile times. I-slow Issue: Problems and improvements with respect to performance of generated code. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants