devel2 build flavour thoughts
lists at richarde.dev
Thu Mar 31 16:23:51 UTC 2022
Interesting -- thanks for taking the time to do this.
> Full build + test: Near identical
> Testsuite run: Near identical
> Recompile: Near identical - (2) is slower
> Build Cabal: 167s vs 259s
I assume from your statement that (2) is 167s and (1) is 259s?
These results surprise me, in a few ways:
- My understanding is that devel2 does not optimise (-O0) the stage-2 compiler. So I'm surprised that the testsuite runs in the same amount of time for both: I would expect (2) to be measurably faster.
- And if the testsuite is the same for both, then I would expect "Build Cabal" to be the same for both: both measurements are looking at the performance of the stage-2 compiler. Yet the difference in time in "Build Cabal" is drastic. Why is this not echoed in the testsuite? (Maybe the testsuite overhead dwarfs the efficiency of the compiler itself?)
- As we have discovered, devel2 behaves differently in the testsuite than your flavour (2). But your text suggests that the only difference is that devel2 is completely unoptimised... and yet the testsuite-behavior differences are not (I think) about performance. So there's some *other* difference.
My key requirements in a build flavor are:
A. assertions enabled
B. quick recompilation
C. < 3 spurious test case failures when running the testsuite locally
I don't have any particular attachment to devel2, per se, other than that (with `make`, at least), it delivers A,B,C. My struggle with Hadrian is that devel2 no longer delivers C. If a different flavor provides A,B,C with Hadrian, I'm happy to give it a go. I'm a little worried about "(2) is slower" above, so my money is still with devel2, as delivering A,B,C better. Building packages is not one of my requirements.
In any case, this is a good conversation to have, because it may yield an understanding that we should jettison or replace devel2. Thanks for starting it!
> So if you want to build packages use flavour 2 but otherwise it seems
> to make little difference.
> ghc-devs mailing list
> ghc-devs at haskell.org
More information about the ghc-devs