Trans refactor was major perf perturbance #3402
Comments
ghost
assigned 
|
not unexpected, will take a look |
|
The main cause seems to be larger stack size due to, I believe, deferred loads. This causes morestack to be invoked more often, leading to slower performance. I am looking into whether it's worth fixing this. |
|
i am surprised that morestack would alone be responsible for up to 2x hits on some test cases. maybe believable, though, if these rare ones are stack-heavy(?) tests. |
Should lead to smaller stack frames, hopefully reducing the perf hits we saw
|
Commit ee4ba44 appears to cause a segfault in |
|
@bblum fibonacci is basically all about calls. Basically all it does is morestack. |
|
@catamorphism where are you observing this segfault? I don't see it locally and the bots seem fine. |
|
fibo perf looks fine now. rustc performance is still lower, though that can be a result of many factors. When I test locally, however, rustc performs precisely the same both before and after the patch. |
|
@nikomatsakis It segfaults on my machine. The executable |
|
It also causes one of the libstd tests to segfault on my other machine. I haven't figured out which one yet. Reverting that patch fixes it. |
|
Segfault fixed in 14303ba |
|
I still haven't tracked down the |
|
Deferring to 0.5---I think this is basically "done" anyhow. |
|
044fbea caused a curious failure (the compile-fail test |
|
This is not really actionable anymore. |
set the TARGET envar for the stdsimd integration test
miri script: build with stable toolchain `./miri toolchain` sets up a `rustup override miri`. But then if something goes wrong and the `miri` toolchain doesn't work, one can't even run `./miri toolchain` again as building miri-script needs a toolchain... So let's always use stable to build miri-script, making it override-independent. I assume everyone will have that installed.
I can't say exactly whether it's good or bad, but the perf numbers went sideways a fair bit with the refactoring of trans in 5e36a99. Some numbers dropped, some went up a lot (factor of 2 on fibo and sudoku), and we lost about 5s on self-compile time.
All of this is potentially tolerable, I'm not suggesting we back it out (so nice!) but it's probably worth looking at a couple of the smaller benchmarks at least, maybe comparing a count-llvm-insns graph and/or the LLVM bitcode output, to see if something changed obviously (by mistake) in the code we're generating.
The text was updated successfully, but these errors were encountered: