GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:40:56Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/9307LLVM vs NCG: floating point numbers close to zero have different sign2019-07-07T18:40:56Zjrp2014LLVM vs NCG: floating point numbers close to zero have different signCompiling HEAD with perf-llvm, (3.4.2) and running the nofib suite fails at the wave4main case. It is not clear to me whether wave4main should always produce the same output (and so the test fails because it does not do so) or whether th...Compiling HEAD with perf-llvm, (3.4.2) and running the nofib suite fails at the wave4main case. It is not clear to me whether wave4main should always produce the same output (and so the test fails because it does not do so) or whether the numbers generated depend on some feature of the build settings, or OS.
```
HC = /Users/xxx/Projects/ghc/inplace/bin/ghc-stage2
HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -cpp -fglasgow-exts -rtsopts
RUNTEST_OPTS = -ghc-timing
==nofib== wave4main: size of wave4main follows...
__TEXT __DATA __OBJC others dec hex
4091904 450560 0 4295947176 4300489640 1005443a8
==nofib== wave4main: time to run wave4main follows...
../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000;
real 0m0.217s
user 0m0.191s
sys 0m0.011s
././wave4main 4000 < /dev/null
expected stdout not matched by reality
--- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100
+++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest16932.1 2014-07-13 13:43:22.000000000 +0100
@@ -1 +1 @@
-69923/1465
+69096/1465
real 0m0.197s
user 0m0.186s
sys 0m0.008s
././wave4main 4000 < /dev/null
expected stdout not matched by reality
--- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100
+++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest16961.1 2014-07-13 13:43:22.000000000 +0100
@@ -1 +1 @@
-69923/1465
+69096/1465
real 0m0.201s
user 0m0.189s
sys 0m0.009s
././wave4main 4000 < /dev/null
expected stdout not matched by reality
--- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100
+++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17011.1 2014-07-13 13:43:22.000000000 +0100
@@ -1 +1 @@
-69923/1465
+69096/1465
real 0m0.201s
user 0m0.190s
sys 0m0.008s
././wave4main 4000 < /dev/null
expected stdout not matched by reality
--- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100
+++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17051.1 2014-07-13 13:43:23.000000000 +0100
@@ -1 +1 @@
-69923/1465
+69096/1465
real 0m0.200s
user 0m0.189s
sys 0m0.009s
././wave4main 4000 < /dev/null
expected stdout not matched by reality
--- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100
+++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17080.1 2014-07-13 13:43:23.000000000 +0100
@@ -1 +1 @@
-69923/1465
+69096/1465
make: *** [runtests] Error 1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | NoFib benchmark suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"wave4main in nofib fails","status":"New","operating_system":"","component":"NoFib benchmark suite","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":["wave4main"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\nCompiling HEAD with perf-llvm, (3.4.2) and running the nofib suite fails at the wave4main case. It is not clear to me whether wave4main should always produce the same output (and so the test fails because it does not do so) or whether the numbers generated depend on some feature of the build settings, or OS.\r\n\r\n\r\n{{{\r\nHC = /Users/xxx/Projects/ghc/inplace/bin/ghc-stage2\r\nHC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -cpp -fglasgow-exts -rtsopts\r\nRUNTEST_OPTS = -ghc-timing\r\n==nofib== wave4main: size of wave4main follows...\r\n__TEXT\t__DATA\t__OBJC\tothers\tdec\thex\r\n4091904\t450560\t0\t4295947176\t4300489640\t1005443a8\r\n==nofib== wave4main: time to run wave4main follows...\r\n../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000;\r\n\r\nreal\t0m0.217s\r\nuser\t0m0.191s\r\nsys\t0m0.011s\r\n././wave4main 4000 < /dev/null\r\nexpected stdout not matched by reality\r\n--- wave4main.stdout\t2014-07-08 20:57:14.000000000 +0100\r\n+++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest16932.1\t2014-07-13 13:43:22.000000000 +0100\r\n@@ -1 +1 @@\r\n-69923/1465\r\n+69096/1465\r\n\r\nreal\t0m0.197s\r\nuser\t0m0.186s\r\nsys\t0m0.008s\r\n././wave4main 4000 < /dev/null\r\nexpected stdout not matched by reality\r\n--- wave4main.stdout\t2014-07-08 20:57:14.000000000 +0100\r\n+++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest16961.1\t2014-07-13 13:43:22.000000000 +0100\r\n@@ -1 +1 @@\r\n-69923/1465\r\n+69096/1465\r\n\r\nreal\t0m0.201s\r\nuser\t0m0.189s\r\nsys\t0m0.009s\r\n././wave4main 4000 < /dev/null\r\nexpected stdout not matched by reality\r\n--- wave4main.stdout\t2014-07-08 20:57:14.000000000 +0100\r\n+++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17011.1\t2014-07-13 13:43:22.000000000 +0100\r\n@@ -1 +1 @@\r\n-69923/1465\r\n+69096/1465\r\n\r\nreal\t0m0.201s\r\nuser\t0m0.190s\r\nsys\t0m0.008s\r\n././wave4main 4000 < /dev/null\r\nexpected stdout not matched by reality\r\n--- wave4main.stdout\t2014-07-08 20:57:14.000000000 +0100\r\n+++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17051.1\t2014-07-13 13:43:23.000000000 +0100\r\n@@ -1 +1 @@\r\n-69923/1465\r\n+69096/1465\r\n\r\nreal\t0m0.200s\r\nuser\t0m0.189s\r\nsys\t0m0.009s\r\n././wave4main 4000 < /dev/null\r\nexpected stdout not matched by reality\r\n--- wave4main.stdout\t2014-07-08 20:57:14.000000000 +0100\r\n+++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17080.1\t2014-07-13 13:43:23.000000000 +0100\r\n@@ -1 +1 @@\r\n-69923/1465\r\n+69096/1465\r\nmake: *** [runtests] Error 1\r\n\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/13892Add some benchmarks to nofib from Andras Kovac's Eff benchmarks2019-07-07T18:19:37ZMatthew PickeringAdd some benchmarks to nofib from Andras Kovac's Eff benchmarksAndras has a bunch of different benchmarks for different effect handler code which stresses the optimiser in interesting ways. It would be good to add some of these benchmarks to nofib as they are likely quite different from a lot of the...Andras has a bunch of different benchmarks for different effect handler code which stresses the optimiser in interesting ways. It would be good to add some of these benchmarks to nofib as they are likely quite different from a lot of the examples already in there.
https://github.com/AndrasKovacs/misc-stuff/tree/master/haskell/Eff
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | michalt |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add some benchmarks to nofib from Andras Kovac's Eff benchmarks","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["michalt"],"type":"Task","description":"Andras has a bunch of different benchmarks for different effect handler code which stresses the optimiser in interesting ways. It would be good to add some of these benchmarks to nofib as they are likely quite different from a lot of the examples already in there. \r\n\r\nhttps://github.com/AndrasKovacs/misc-stuff/tree/master/haskell/Eff","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/23643Bump nofib submodule2023-07-18T14:37:45ZAndreas KlebingerBump nofib submoduleIt doesn't build with 9.4/9.6 but nofib master does.It doesn't build with 9.4/9.6 but nofib master does.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/22232nofib is incredibly greedy on disk space2022-10-11T14:19:44ZSimon Peyton Jonesnofib is incredibly greedy on disk spaceI keep running out of disk space, and it turns out to be the nofib build trees. Here is a listing
```
simonpj@LHR-WD-22561:~/code$ du -d 1 -h HEAD | sort -h -r
16G HEAD
6.4G HEAD/nofib
5.0G HEAD/_build
3.6G HEAD/.git
274M HEAD/testsuite...I keep running out of disk space, and it turns out to be the nofib build trees. Here is a listing
```
simonpj@LHR-WD-22561:~/code$ du -d 1 -h HEAD | sort -h -r
16G HEAD
6.4G HEAD/nofib
5.0G HEAD/_build
3.6G HEAD/.git
274M HEAD/testsuite
167M HEAD/libraries
47M HEAD/hadrian
38M HEAD/bootstrapping
32M HEAD/utils
27M HEAD/compiler
22M HEAD/inplace
5.1M HEAD/docs
4.7M HEAD/rts
2.5M HEAD/autom4te.cache
1.3M HEAD/libffi-tarballs
572K HEAD/ghc
356K HEAD/m4
256K HEAD/.gitlab
172K HEAD/mk
128K HEAD/linters
116K HEAD/driver
96K HEAD/distrib
24K HEAD/bindisttest
12K HEAD/libffi
```
Now it turns out that *each nofib run* takes another 4G. Compared with 5G for an entire GHC build, that seems like a lot.
If I do a daily nofib run in 4 build trees, that eats up 16G/day, and it's not long before I run out.
After I've run nofib, all I want are the results in `run.results.tsv`. Maybe a log file. The rest is just a waste of space.
Could we be more parsimonious somehow?Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/22108Improve nofib comparison output2024-01-16T17:23:40ZSimon Peyton JonesImprove nofib comparison outputWhen running nofib comparisons, I use [these instructions](https://gitlab.haskell.org/ghc/nofib/-/blob/master/shake/README.mkd)
But "Comparison" command, namely `$ cabal v2-run nofib-compare -- approach-b.results.csv approach-a.results....When running nofib comparisons, I use [these instructions](https://gitlab.haskell.org/ghc/nofib/-/blob/master/shake/README.mkd)
But "Comparison" command, namely `$ cabal v2-run nofib-compare -- approach-b.results.csv approach-a.results.csv`, generates output that is much less helpful than it used to be. Sample:
```
# bytes allocated
+-------------------------------++--+----------------------------------------------------------------+-----------+----------------------------------------+-----------+
| || | /home/simonpj/code/HEAD/nofib/_make/2022-08-19/run.results.tsv | std. err. | _make/2022-08-25/run.results.tsv (rel) | std. err. |
+===============================++==+================================================================+===========+========================================+===========+
| imaginary/bernouilli || | 2.823e9 | 0.0% | 0.00% | 0.0% |
| imaginary/digits-of-e1 || | 9.147e8 | 0.0% | 0.00% | 0.0% |
| imaginary/digits-of-e2 || | 2.279e9 | 0.0% | +0.01% | 0.0% |
| imaginary/exp3_8 || | 5.887e9 | 0.0% | 0.00% | 0.0% |
| imaginary/gen_regexps || | 9.102e8 | 0.0% | 0.00% | 0.0% |
....
| imaginary/integrate || | 3.424e9 | 0.0% | 0.00% | 0.0% |
| spectral/simple || | 1.201e9 | 0.0% | 0.00% | 0.0% |
| spectral/sorting || | 3.077e9 | 0.0% | 0.00% | 0.0% |
| spectral/sphere || | 2.236e9 | 0.0% | 0.00% | 0.0% |
| spectral/treejoin || | 2.796e9 | 0.0% | 0.00% | 0.0% |
+===============================++==+================================================================+===========+========================================+===========+
| geom mean || | | -0.03% | | |
+-------------------------------++--+----------------------------------------------------------------+-----------+----------------------------------------+-----------+
```
Problems:
* It is far too wide. I have to resize my editor window every time, and my screen becomes mostly blank.
* There is no min and max, only geometric mean.
* It's not obvious what the geom mean is for. It sits at the bottom of the "std error column" but I'm guessing it belongs in the next column.
* I have no idea what either "std err" column is. They are always zero, diverting attention.
* The old nofib-analyse started with a table that looked like this, where I'm comparing a baseline run with three comparator runs (X1, X2, and X3, say)
```
Benchmark Binary size change Runtime allocs change Runtime change
X1 X2 X3 X1 X2 X3 X1 X2 X3
spectral/sphere +2.8% -3% 0% +1% -1% +2.7% +0.8% +2% +6%
```
This was great for getting an overview of the key changes: binary size, allocs, runtime. (A column for compiler allocs would be great too.) Could we have this back?https://gitlab.haskell.org/ghc/ghc/-/issues/15976Can't run nofib in parallel2019-07-07T18:02:11ZSebastian GrafCan't run nofib in parallelI was under the impression that `make -j$n` within `nofib` would run benchmarks in parallel, but it doesn't. The following warning is indicative:
```
make[1]: warning: -jN forced in submake: disabling jobserver mode.
```
Whenever `make...I was under the impression that `make -j$n` within `nofib` would run benchmarks in parallel, but it doesn't. The following warning is indicative:
```
make[1]: warning: -jN forced in submake: disabling jobserver mode.
```
Whenever `make` is called recursively, any `-j` flags will lead to this warning and consequently disable parallelisation (which would lead to a number of jobs exponential in the depth of recursive calls).
Parallel benchmarks are useful to get deterministic metrics such as allocations or counted instructions really fast.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | NoFib benchmark suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Can't run nofib in parallel","status":"New","operating_system":"","component":"NoFib benchmark suite","related":[],"milestone":"⊥","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I was under the impression that `make -j$n` within `nofib` would run benchmarks in parallel, but it doesn't. The following warning is indicative:\r\n\r\n{{{\r\nmake[1]: warning: -jN forced in submake: disabling jobserver mode.\r\n}}}\r\n\r\nWhenever `make` is called recursively, any `-j` flags will lead to this warning and consequently disable parallelisation (which would lead to a number of jobs exponential in the depth of recursive calls).\r\n\r\nParallel benchmarks are useful to get deterministic metrics such as allocations or counted instructions really fast.","type_of_failure":"OtherFailure","blocking":[]} -->⊥https://gitlab.haskell.org/ghc/ghc/-/issues/12941Extend nofib with benchmarks focused on compiler performance2020-01-23T19:32:33ZMichal TerepetaExtend nofib with benchmarks focused on compiler performanceGHC seems to be missing a set of benchmarks focused on the compiler performance that would contain some realistic examples and make it easy to test even small changes in the compiler (by having a simple "before and after" comparison). Th...GHC seems to be missing a set of benchmarks focused on the compiler performance that would contain some realistic examples and make it easy to test even small changes in the compiler (by having a simple "before and after" comparison). The two main use cases would be:
- Anyone hacking on GHC could quickly check even for small performance differences (running the benchmark with and without their change).
- Tracking performance of GHC over time (potentially as part of perf.haskell.org)
We already have two collections of performance tests/benchmarks:
- `tests/perf/compiler` which contains actual tests (part of `validate`) and seems to be focused on larger regressions (if the bounds are too tight, it can generate a fair amount of noise).
- `nofib` which is mostly focused on benchmarking the code produced by GHC (the vast majority of the modules compile within 400ms).
The current idea is to extend `nofib` with some modules that are only checking the performance of GHC (e.g., might be a library module that doesn't contain `main`).
Please see: https://mail.haskell.org/pipermail/ghc-devs/2016-December/013323.html for an initial discussion about this.
Also related:
- Ticket focused on improvements to `tests/perf/compiler` #12758
- Proposal of having a similar tests but hosted in a separate repo on github: https://github.com/ghc-proposals/ghc-proposals/pull/26
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | NoFib benchmark suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Extend nofib with benchmarks focused on compiler performance","status":"New","operating_system":"","component":"NoFib benchmark suite","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"michalt"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"GHC seems to be missing a set of benchmarks focused on the compiler performance that would contain some realistic examples and make it easy to test even small changes in the compiler (by having a simple \"before and after\" comparison). The two main use cases would be:\r\n- Anyone hacking on GHC could quickly check even for small performance differences (running the benchmark with and without their change).\r\n- Tracking performance of GHC over time (potentially as part of perf.haskell.org)\r\n\r\nWe already have two collections of performance tests/benchmarks:\r\n- `tests/perf/compiler` which contains actual tests (part of `validate`) and seems to be focused on larger regressions (if the bounds are too tight, it can generate a fair amount of noise).\r\n- `nofib` which is mostly focused on benchmarking the code produced by GHC (the vast majority of the modules compile within 400ms).\r\n\r\nThe current idea is to extend `nofib` with some modules that are only checking the performance of GHC (e.g., might be a library module that doesn't contain `main`).\r\n\r\nPlease see: https://mail.haskell.org/pipermail/ghc-devs/2016-December/013323.html for an initial discussion about this.\r\n\r\nAlso related:\r\n- Ticket focused on improvements to `tests/perf/compiler` #12758\r\n- Proposal of having a similar tests but hosted in a separate repo on github: https://github.com/ghc-proposals/ghc-proposals/pull/26","type_of_failure":"OtherFailure","blocking":[]} -->Michal TerepetaMichal Terepetahttps://gitlab.haskell.org/ghc/ghc/-/issues/9572nofib target for just building should be part of validate2019-07-07T18:39:58ZEdward Z. Yangnofib target for just building should be part of validatenofib is never run during validates, which makes it easy to bitrot (c.f. AMP changes). It would be better if:
1. We had a build target for just building nofib tests, not running them, (maybe optionally with optimizations turned off, or ...nofib is never run during validates, which makes it easy to bitrot (c.f. AMP changes). It would be better if:
1. We had a build target for just building nofib tests, not running them, (maybe optionally with optimizations turned off, or just `-fno-code`) and
1. This build target was executed during validates
This should strike a balance between wanting to avoid having to spend a lot of time running the benchmarks on validate, while still exercising the nofib tests to some degree.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | NoFib benchmark suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"nofib target for just building should be part of validate","status":"New","operating_system":"","component":"NoFib benchmark suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"nofib is never run during validates, which makes it easy to bitrot (c.f. AMP changes). It would be better if:\r\n\r\n1. We had a build target for just building nofib tests, not running them, (maybe optionally with optimizations turned off, or just `-fno-code`) and\r\n2. This build target was executed during validates\r\n\r\nThis should strike a balance between wanting to avoid having to spend a lot of time running the benchmarks on validate, while still exercising the nofib tests to some degree.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9571nofib should use criterion-style bootstrapping/sampling2019-07-07T18:39:58ZEdward Z. Yangnofib should use criterion-style bootstrapping/samplingAs I discovered when investigating situations like #9570, in some cases, test-cases in nofib are giving nonsense, and it's hard to tell unless you run nofib several times and notice that percentage differences are fluctuating up and down...As I discovered when investigating situations like #9570, in some cases, test-cases in nofib are giving nonsense, and it's hard to tell unless you run nofib several times and notice that percentage differences are fluctuating up and down. The quality of the numbers we get for uninformed users would be better if we ran some statistical analysis to tell how many times to run the benchmark, and if there were lots of outliers (rather than just blindly summarizing all the runs using an average.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 7.9 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | NoFib benchmark suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"nofib should use criterion-style bootstrapping/sampling","status":"New","operating_system":"","component":"NoFib benchmark suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"As I discovered when investigating situations like #9570, in some cases, test-cases in nofib are giving nonsense, and it's hard to tell unless you run nofib several times and notice that percentage differences are fluctuating up and down. The quality of the numbers we get for uninformed users would be better if we ran some statistical analysis to tell how many times to run the benchmark, and if there were lots of outliers (rather than just blindly summarizing all the runs using an average.)","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9570cryptarithm1 (normal) has bimodal runtime2019-07-07T18:39:58ZEdward Z. Yangcryptarithm1 (normal) has bimodal runtimeI was investigating performance numbers for cryptarithm1 in #8199, I noticed that the numbers for this benchmark were curiously bimodal. Here are two representative samples from both sides of the distribution.
```
../../runstdtest/runst...I was investigating performance numbers for cryptarithm1 in #8199, I noticed that the numbers for this benchmark were curiously bimodal. Here are two representative samples from both sides of the distribution.
```
../../runstdtest/runstdtest ./cryptarithm1 -o1 cryptarithm1.stdout -o1 cryptarithm1.stdout -ghc-timing ; ../../runstdtest/runstdtest ./cryptarithm1 -o1 cryptarithm1.stdout -o1 cryptarithm1.stdout -ghc-timing ; ../../runstdtest/runstdtest ./cryptarithm1 -o1 cryptarithm1.stdout -o1 cryptarithm1.stdout -ghc-timing ; ../../runstdtest/runstdtest ./cryptarithm1 -o1 cryptarithm1.stdout -o1 cryptarithm1.stdout -ghc-timing ; ../../runstdtest/runstdtest ./cryptarithm1 -o1 cryptarithm1.stdout -o1 cryptarithm1.stdout -ghc-timing ;
real 0m0.676s
user 0m0.660s
sys 0m0.013s
<<ghc: 2051819320 bytes, 3929 GCs (3927 + 2), 0/0 avg/max bytes residency (0 samples), 5221368 bytes GC work, 1M in use, 0.000 INIT (0.000 elapsed), 0.643 MUT (0.643 elapsed), 0.026 GC (0.026 elapsed), 0.026 GC(0) (0.025 elapsed), 0.000 GC(1) (0.000 elapsed), 1 balance :ghc>>
real 0m0.610s
user 0m0.603s
sys 0m0.007s
<<ghc: 2051819320 bytes, 3929 GCs (3927 + 2), 0/0 avg/max bytes residency (0 samples), 5221368 bytes GC work, 1M in use, 0.000 INIT (0.000 elapsed), 0.582 MUT (0.582 elapsed), 0.023 GC (0.023 elapsed), 0.023 GC(0) (0.023 elapsed), 0.000 GC(1) (0.000 elapsed), 1 balance :ghc>>
```
I don't have any further resolution on the problem yet.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | NoFib benchmark suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"cryptarithm1 (normal) has bimodal runtime","status":"New","operating_system":"","component":"NoFib benchmark suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I was investigating performance numbers for cryptarithm1 in #8199, I noticed that the numbers for this benchmark were curiously bimodal. Here are two representative samples from both sides of the distribution.\r\n\r\n{{{\r\n../../runstdtest/runstdtest ./cryptarithm1 -o1 cryptarithm1.stdout -o1 cryptarithm1.stdout -ghc-timing ; ../../runstdtest/runstdtest ./cryptarithm1 -o1 cryptarithm1.stdout -o1 cryptarithm1.stdout -ghc-timing ; ../../runstdtest/runstdtest ./cryptarithm1 -o1 cryptarithm1.stdout -o1 cryptarithm1.stdout -ghc-timing ; ../../runstdtest/runstdtest ./cryptarithm1 -o1 cryptarithm1.stdout -o1 cryptarithm1.stdout -ghc-timing ; ../../runstdtest/runstdtest ./cryptarithm1 -o1 cryptarithm1.stdout -o1 cryptarithm1.stdout -ghc-timing ;\r\n\r\nreal 0m0.676s\r\nuser 0m0.660s\r\nsys 0m0.013s\r\n<<ghc: 2051819320 bytes, 3929 GCs (3927 + 2), 0/0 avg/max bytes residency (0 samples), 5221368 bytes GC work, 1M in use, 0.000 INIT (0.000 elapsed), 0.643 MUT (0.643 elapsed), 0.026 GC (0.026 elapsed), 0.026 GC(0) (0.025 elapsed), 0.000 GC(1) (0.000 elapsed), 1 balance :ghc>>\r\n\r\nreal 0m0.610s\r\nuser 0m0.603s\r\nsys 0m0.007s\r\n<<ghc: 2051819320 bytes, 3929 GCs (3927 + 2), 0/0 avg/max bytes residency (0 samples), 5221368 bytes GC work, 1M in use, 0.000 INIT (0.000 elapsed), 0.582 MUT (0.582 elapsed), 0.023 GC (0.023 elapsed), 0.023 GC(0) (0.023 elapsed), 0.000 GC(1) (0.000 elapsed), 1 balance :ghc>>\r\n}}}\r\n\r\nI don't have any further resolution on the problem yet.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9319nofib-analyze doesn’t provide per-benchmark compile time/alloc numbers2019-07-07T18:40:54ZJoachim Breitnermail@joachim-breitner.denofib-analyze doesn’t provide per-benchmark compile time/alloc numbersThe compile time and allocation numbers calculated by nofib are only available per module. While this is useful to find the cause of problems, it would be nice if these numbers were also accumulated for each benchmark, for easy of genera...The compile time and allocation numbers calculated by nofib are only available per module. While this is useful to find the cause of problems, it would be nice if these numbers were also accumulated for each benchmark, for easy of general analysis and uniformity, especially with automated monitoring of benchmark numbers.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 7.8.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | NoFib benchmark suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"nofib-analyze doesn’t provide per-benchmark compile time/alloc numbers","status":"New","operating_system":"","component":"NoFib benchmark suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"The compile time and allocation numbers calculated by nofib are only available per module. While this is useful to find the cause of problems, it would be nice if these numbers were also accumulated for each benchmark, for easy of general analysis and uniformity, especially with automated monitoring of benchmark numbers.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/8989nofib should record and report more fine-grained binary size information2019-07-07T18:42:24ZEdward Z. Yangnofib should record and report more fine-grained binary size informationProbably by section would be best; this way we can distinguish between increases in code size, as opposed to increases from other sources.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| -...Probably by section would be best; this way we can distinguish between increases in code size, as opposed to increases from other sources.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 7.9 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | NoFib benchmark suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"nofib should record and report more fine-grained binary size information","status":"New","operating_system":"","component":"NoFib benchmark suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Probably by section would be best; this way we can distinguish between increases in code size, as opposed to increases from other sources.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/8045Move I/O manager benchmarks into the GHC tree2021-06-19T20:21:11ZtibbeMove I/O manager benchmarks into the GHC treeWhen we developed the scalable I/O manager (i.e. the first version that used epoll) we wrote a bunch of benchmarks that were never moved to the GHC tree or integrated into the make system:
> https://github.com/tibbe/event/tree/master/b...When we developed the scalable I/O manager (i.e. the first version that used epoll) we wrote a bunch of benchmarks that were never moved to the GHC tree or integrated into the make system:
> https://github.com/tibbe/event/tree/master/benchmarks
It would be nice to move this into the GHC tree to catch future regressions and use them when trying to make improvements.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------- |
| Version | 7.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | NoFib benchmark suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | andreas.voellmy@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Move I/O manager benchmarks into the GHC tree","status":"New","operating_system":"","component":"NoFib benchmark suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["andreas.voellmy@gmail.com"],"type":"FeatureRequest","description":"When we developed the scalable I/O manager (i.e. the first version that used epoll) we wrote a bunch of benchmarks that were never moved to the GHC tree or integrated into the make system:\r\n\r\n https://github.com/tibbe/event/tree/master/benchmarks\r\n\r\nIt would be nice to move this into the GHC tree to catch future regressions and use them when trying to make improvements.","type_of_failure":"OtherFailure","blocking":[]} -->Alina BanerjeeAlina Banerjeehttps://gitlab.haskell.org/ghc/ghc/-/issues/7966'make distclean' does not work in nofib2019-07-07T18:47:15ZJan Stolarekjan.stolarek@ed.ac.uk'make distclean' does not work in nofibI noticed that `make distclean` and `make maintainer-clean` don't work for nofib because `distclean` and `maintainer-clean` targets are not defined in the `nofib-analyse/Makefile`. This seems easy to fix - it's enough to change `clean:` ...I noticed that `make distclean` and `make maintainer-clean` don't work for nofib because `distclean` and `maintainer-clean` targets are not defined in the `nofib-analyse/Makefile`. This seems easy to fix - it's enough to change `clean:` to `clean distclean maintainer-clean:` in the mentioned `Makefile`.
After this fix is applied it turns out that the cleaning commands leave some garbage in the nofib tree:
- output files from cachegrind are not removed. This can be fixed by adding `cachegrind.out*` on line 250 in `mk/ghc-paths.mk`
- these files are not deleted:
```
real/maillist/addresses.tex
shootout/fasta/fasta-c
shootout/fasta/fasta.stdout
shootout/k-nucleotide/fasta-c
shootout/k-nucleotide/knucleotide-input2500000.txt
shootout/reverse-complement/fasta-c
shootout/reverse-complement/revcomp-c
shootout/reverse-complement/revcomp-input2500000.txt
shootout/reverse-complement/reverse-complement.stdout
```
I'm not sure on the best way of fixing the second issue so I'm not attaching my own patch.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | NoFib benchmark suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"'make distclean' does not work in nofib","status":"New","operating_system":"","component":"NoFib benchmark suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I noticed that `make distclean` and `make maintainer-clean` don't work for nofib because `distclean` and `maintainer-clean` targets are not defined in the `nofib-analyse/Makefile`. This seems easy to fix - it's enough to change `clean:` to `clean distclean maintainer-clean:` in the mentioned `Makefile`.\r\n\r\nAfter this fix is applied it turns out that the cleaning commands leave some garbage in the nofib tree:\r\n\r\n - output files from cachegrind are not removed. This can be fixed by adding `cachegrind.out*` on line 250 in `mk/ghc-paths.mk`\r\n - these files are not deleted:\r\n\r\n{{{\r\nreal/maillist/addresses.tex\r\nshootout/fasta/fasta-c\r\nshootout/fasta/fasta.stdout\r\nshootout/k-nucleotide/fasta-c\r\nshootout/k-nucleotide/knucleotide-input2500000.txt\r\nshootout/reverse-complement/fasta-c\r\nshootout/reverse-complement/revcomp-c\r\nshootout/reverse-complement/revcomp-input2500000.txt\r\nshootout/reverse-complement/reverse-complement.stdout\r\n}}}\r\n\r\nI'm not sure on the best way of fixing the second issue so I'm not attaching my own patch.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5793make nofib awesome2019-07-07T18:53:34Zdtereimake nofib awesomeNofib is the standard tool GHC developers use to benchmark changes to the compiler. Its overall design is OK but it's had no love and care for many years and has bittrotted such that it isn't useful in a lot of situations.
This task is ...Nofib is the standard tool GHC developers use to benchmark changes to the compiler. Its overall design is OK but it's had no love and care for many years and has bittrotted such that it isn't useful in a lot of situations.
This task is about making nofib useful again.
The breakdown for this is something like:
1. Think and maybe fix nofib framework design. It has 'ways' which I think correspond to compilation method but more in the sense of 'dynamic' vs 'static', seems it may not suite being able to use ways for 'fasm' vs 'fllvm'. There is also the concept of 'modes' which corresponds to different benchmark input. So 'normal' and 'slow' for getting different run-times. At moment no easy way to select which benchmark groups to run, so may want to change that. I guess we should just decide, what knobs do we want to be able to easily tweak, and see how well the current design allows that.
**Note** there is a shake build system attached that does a lot of this (done by Neil Mitchell!). An explanation of it can be found here: http://neilmitchell.blogspot.com/2013/02/a-nofib-build-system-using-shake.html
The design discussion of it is mostly lost as it was done on private email sorry.
1. \~\~Fixup the runtimes for benchmarks to be significant. This might be best done by changing the way we run benchmarks and collect results to make sure they are meaningful (cf. #15357)\~\~ done in #15999.
E.g., Lots of great discussion and links to papers on this thread
http://www.haskell.org/pipermail/ghc-devs/2013-February/000307.html
1. \~\~Above task is to fix normal but we may want to fixup slow as well and perhaps add a 'fast' mode where benchmarks run in around 1 second.\~\~ Done, we determined that 0.1-0.2/1-2/5-10 for fast/norm/slow are the brackets to aim for.
1. Maybe add more benchmarks to the suite (text, bytestring, performance regressions from ghc testsuite, vector....)Michal TerepetaMichal Terepetahttps://gitlab.haskell.org/ghc/ghc/-/issues/9511Remove deprecated -fglasgow-exts from NoFib suite2019-07-07T18:40:13ZDavid FeuerRemove deprecated -fglasgow-exts from NoFib suiteSomeone on \#ghc noted that replacing -fglasgow-exts with only the necessary options in each case may change compile times, which may be undesirable. I think a reasonable workaround would be to just put all the options on the command lin...Someone on \#ghc noted that replacing -fglasgow-exts with only the necessary options in each case may change compile times, which may be undesirable. I think a reasonable workaround would be to just put all the options on the command line, whether necessary or not. This will increase the time needed to parse the command lines, but presumably by a trivial amount.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 7.8.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | NoFib benchmark suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Remove deprecated -fglasgow-exts from NoFib suite","status":"New","operating_system":"","component":"NoFib benchmark suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Someone on #ghc noted that replacing -fglasgow-exts with only the necessary options in each case may change compile times, which may be undesirable. I think a reasonable workaround would be to just put all the options on the command line, whether necessary or not. This will increase the time needed to parse the command lines, but presumably by a trivial amount.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/18827Hardian: make nofib rule more fine-grained2020-11-09T14:06:17ZAlex DHardian: make nofib rule more fine-grained## Motivation
The purpose of this ticket is to track work related to Hadrian's nofib rule improvements.
Currently, when we invoke nofib with hadrian, we essentially do
```
cd nofib; make clean; make boot; make 2>&1 | tee nofib-log
```...## Motivation
The purpose of this ticket is to track work related to Hadrian's nofib rule improvements.
Currently, when we invoke nofib with hadrian, we essentially do
```
cd nofib; make clean; make boot; make 2>&1 | tee nofib-log
```
It would be good to have more control and be able to provide other options. For example:
1. specifying time mode - `fast/norm/slow`
2. passing `EXTRA_RUNTEST_OPTS` (for example, when using `-cachegrind`)
3. Number of rounds - `NoFibRuns`
4. Specifying the name of the file where we redirect the output to
4. Exposing `nofib-analyse` as another rule
## Proposal
implement the proposed enhancements by updating current and introducing new rules.
## TODO
* [ ] Update https://gitlab.haskell.org/ghc/ghc/-/wikis/building/hadrian/quick-startAlex DAlex Dhttps://gitlab.haskell.org/ghc/ghc/-/issues/21859nofib fails to run in CI2022-07-25T13:43:26ZBryan Rbryan@haskell.foundationnofib fails to run in CIThe perf-nofib job has accumulated a variety of errors over the months or years. It was marked with `allow_failure: true` and thereafter various things piled up.The perf-nofib job has accumulated a variety of errors over the months or years. It was marked with `allow_failure: true` and thereafter various things piled up.https://gitlab.haskell.org/ghc/ghc/-/issues/16528Remove symlinks from nofib repository.2019-04-07T10:36:52ZAndreas KlebingerRemove symlinks from nofib repository.On windows setting up git to work with symlinks is tedious, but acceptable.
But even if set up correctly then all symlink files show up as having their type changed on my box.
```
$ git status
On branch master
Your branch is up to date...On windows setting up git to work with symlinks is tedious, but acceptable.
But even if set up correctly then all symlink files show up as having their type changed on my box.
```
$ git status
On branch master
Your branch is up to date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
typechange: imaginary/bernouilli/NofibUtils.hs
typechange: imaginary/digits-of-e1/NofibUtils.hs
typechange: imaginary/digits-of-e2/NofibUtils.hs
typechange: imaginary/gen_regexps/NofibUtils.hs
typechange: real/anna/NofibUtils.hs
typechange: real/bspt/NofibUtils.hs
typechange: real/compress/NofibUtils.hs
typechange: real/compress2/NofibUtils.hs
typechange: real/fem/NofibUtils.hs
typechange: real/fluid/NofibUtils.hs
typechange: real/fulsom/NofibUtils.hs
typechange: real/gamteb/NofibUtils.hs
typechange: real/gg/NofibUtils.hs
typechange: real/grep/NofibUtils.hs
typechange: real/hidden/NofibUtils.hs
typechange: real/hpg/NofibUtils.hs
typechange: real/infer/NofibUtils.hs
typechange: real/lift/NofibUtils.hs
typechange: real/linear/NofibUtils.hs
typechange: real/mkhprog/NofibUtils.hs
typechange: real/parser/NofibUtils.hs
typechange: real/pic/NofibUtils.hs
typechange: real/prolog/NofibUtils.hs
typechange: real/reptile/NofibUtils.hs
typechange: real/rsa/NofibUtils.hs
typechange: real/symalg/NofibUtils.hs
typechange: real/veritas/NofibUtils.hs
typechange: spectral/sorting/NofibUtils.hs
no changes added to commit (use "git add" and/or "git commit -a")
```
I do not know why this happens, and a quick search didn't lead to satisfying answers.
In order to keep the friction to running nofib low I suggest that for the time being we go back to ordinary files.
To avoid duplicating files which drift apart slowly I suggest we copy these during the boot process.
It's still not perfect. But better than the status quo.https://gitlab.haskell.org/ghc/ghc/-/issues/20872nofib fails to build in ben-raytrace: Word# vs. Word64##2022-01-03T17:17:57ZJoachim Breitnermail@joachim-breitner.denofib fails to build in ben-raytrace: Word# vs. Word64##I observe this in the `perf-nofib` job on master, e.g. in https://gitlab.haskell.org/ghc/ghc/-/jobs/894412:
```
Random/Wyhash64.hs:27:20: error:
• Couldn't match expected type ‘GHC.Prim.Word#’
with actual type ‘GHC...I observe this in the `perf-nofib` job on master, e.g. in https://gitlab.haskell.org/ghc/ghc/-/jobs/894412:
```
Random/Wyhash64.hs:27:20: error:
• Couldn't match expected type ‘GHC.Prim.Word#’
with actual type ‘GHC.Prim.Word64#’
• In the first argument of ‘timesWord2#’, namely ‘a’
In the expression: timesWord2# a b
In the expression:
case timesWord2# a b of (# x, y #) -> (W64# x, W64# y)
|
27 | case timesWord2# a b of (# x, y #) -> (W64# x, W64# y)
| ^
Random/Wyhash64.hs:27:22: error:
• Couldn't match expected type ‘GHC.Prim.Word#’
with actual type ‘GHC.Prim.Word64#’
• In the second argument of ‘timesWord2#’, namely ‘b’
In the expression: timesWord2# a b
In the expression:
case timesWord2# a b of (# x, y #) -> (W64# x, W64# y)
|
27 | case timesWord2# a b of (# x, y #) -> (W64# x, W64# y)
| ^
Random/Wyhash64.hs:27:47: error:
• Couldn't match expected type ‘GHC.Prim.Word64#’
with actual type ‘GHC.Prim.Word#’
• In the first argument of ‘W64#’, namely ‘x’
In the expression: W64# x
In the expression: (W64# x, W64# y)
|
27 | case timesWord2# a b of (# x, y #) -> (W64# x, W64# y)
| ^
Random/Wyhash64.hs:27:55: error:
• Couldn't match expected type ‘GHC.Prim.Word64#’
with actual type ‘GHC.Prim.Word#’
• In the first argument of ‘W64#’, namely ‘y’
In the expression: W64# y
In the expression: (W64# x, W64# y)
|
27 | case timesWord2# a b of (# x, y #) -> (W64# x, W64# y)
| ^
```
I didn’t find an existing issue; sorry if I didn't search enough.