Libraries
Threads by month
- ----- 2025 -----
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2003 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2002 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2001 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
June 2021
- 26 participants
- 15 discussions
07 Jul '21
I'm proposing to add HasCallStack constraint for partial functions
in base package for functions in Data.List and Data.List.NonEmpty:
- head, tail, init, last, ...
- foldr1, foldl1, maximum, minimum, ...
- (!!)
---
The previous discussions started by Luo Chen can be found at
https://gitlab.haskell.org/ghc/ghc/-/issues/17040 (from August 2019)
and libraries list from June 2019
https://mail.haskell.org/pipermail/libraries/2019-June/029652.html
---
My motivation comes from seeing GHCJS failing with
"Prelude.!! negative index" exception and
cabal-install with head of empty list.
---
In #17040 issue Ben Gamari comments [1]
> In general, adding HasCallStack constraints on things like simple
> non-recursive functions like fromJust and head seems like a reasonable
> trade-off; these functions will essentially always inline and
> consequently the cost of the constraint will vanish.
Such patch is now available at
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5833
After accepting few changed test outputs, no further changes were needed.
---
Ben continues:
> Adding HasCallStack constraints on typeclass-overloaded methods isn't
> as clear. After all, it's quite likely that these functions will be
> reached by dynamic dispatch which will become more expensive with the
> additional callstack argument.
I agree. Foldable.foldr1 may not be partial, e.g. it isn't for NonEmpty.
More correct approach would be to add Foldable1 [2] class to base, and
in some distant future remove potentially partial members from Foldable.
Therefore my patch _does not change_ Foldable.
> nofib may not be a very good test for this patch as it doesn't contain
> many uses of the affected functions
Indeed. These functions are hardly ever in tight performance critical
code, thus I'm skeptical about they affecting a code written by
performance aware people. Re-implementing `head` in a loop where it
causes performance regression is trivial.
I have run `nofib` anyway. Results are at the end.
> I think it would be a good idea to start with a minimal patch adding
> constraints to the simple cases. We should then verify that the patch
> doesn't affect the Core produced by typical use-cases (perhaps even
> adding tests such that these don't regress). Once we know that the
> simple cases are safe we can move on to the harder cases.
Such patch is now available at
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5833
---
Let me go through other comments in previous discussions, to have fuller
overview.
---
Some people are in favour, e.g.
- Simon Jakobi,
https://mail.haskell.org/pipermail/libraries/2019-June/029655.html
- Hécate, https://gitlab.haskell.org/ghc/ghc/-/issues/17040#note_355561
---
Richard [3] thinks that e.g. a year prior addition of HasCallStack to
fromJust
[4] is not a right thing.
> I don't have any particular insight to how to do call stacks better --
> and I am swayed by the argument that we need call stacks even in
> production -- but I don't think HasCallStack is the way. That was
> always meant as just a small hack!
This patch is indeed more pragmatic than elegant, but takes us from
takes us from spending potentially many hours finding the source of a
crash to being pointed at the very line where it happens directly, which
is invaluable for production systems. I.e. let not (unknown) perfect be
an enemy of good solution.
---
In fromJust issue discussion [4] Ben comments
> However, I should emphasize to that we don't want to simply scatter
> HasCallStacks on every partial function. We should be thoughtful and
> deliberate (and probably consult with the CLC) when making changes
> like this.
This email is indeed a request for CLC to comment.
---
Edward Kmett comments was in favour [5]
> I’m starting to warm to the idea of putting HasCallStack constraints
> on the obviously partial combinators in base if we can demonstrate
> that the performance impact isn't bad in practice, and even really, to
> some extent if there is a somewhat middling impact on the performance
> of code that leans on these hard to debug combinators, so long as the
> performance of their more total siblings remains unaffected. The
> impact on the perceived debuggability of Haskell seems _likely_ to
> significantly outweigh the performance concerns.
The results (to follow) shows that impact isn't bad.
> Heck, off of the HEAD of cabal, which we’re encouraging folks to build
> to play with the ghc 8.8.1 alpha, just today we ran into an issue
> where the very build system we are using spat out an oh so informative
> “Prelude.foldr1: Empty list” when using a pkgconfig-depends stanza
> that didnt include any explicit bounds.
---
David Feuer is worried about performance of recursive functions [6]
> As I recall, the main things to watch out for, performance-wise, are
> recursive definitions. When we throw an error from a library function,
> we *typically* mean that the caller made a mistake. We don't want to
> build up the call stacks we'd need to debug the library function
> itself, unless we're actually doing so (in which case we can edit it
> in, of course).
In current base implementation all recursive functions (like foldr1, or
!!) have internal workers, so the callstack is not building-up.
Eric Seidel comments later [8]
> What I remember finding back then was that there was a small overhead
> for non-recursive functions like `head` but a substantial overhead for
> recursive functions.
> I'd suggest extra care around recursive functions ((!!) comes to
> mind). Perhaps rewrite them to use an inner recursive loop that does
> not extend the CallStack (this might produce nicer stacktraces
> anyway).
That is how (!!) is currently written in base. It has an inner worker.
(His benchmark link is not valid anymore, so I cannot tell what !!
variant he benchmarked).
---
Matthew Pickering comments [7] about -xc RTS flag.
> I find this thread a bit concerning. In my opinion the current best
> way to get call stacks on exceptions is with `-xc`. Adding runtime
> overhead to every user program is not acceptable.
-xc requires recompiling the program for profiling.
He continues with
> There is an argument that it would be good to disentangle `-xc` from
> `prof` but you would still have to compile `base` in this way which
> instruments these partial functions (as a user can not do it herself).
> I'm not too sure on the details but I don't think -xc uses any
> information from the profiling header so the fact it's connected with
> -prof seems more like convenience than necessity.
If that work is done, we can drop HasCallStack from partial functions,
until then again let not perfect be the enemy of good.
For example, me seeing GHCJS throwing on !!, of Edward cabal-install on
foldr1 doesn't help. Rebuilding cabal-install with profiling is viable
(but not for an average person who downloads it with ghcup),
rebuilding GHCJS for profiling is a skill few people have.
Already in his original proposal Luo Chen says:
> When we run a long running program, such as a web service, it is not
> easy to reproduce the issue, most of the time, you have no chance to
> recompile or restart your program to debug, all you can rely on is the
> printed logs, this makes -xc not as useful as HasCallStack.
---
People are worried about performance.
GHC itself uses some of the a affected functions.
There are 30 foldr1, some head and tail calls, and also !! in `compiler/`
The performance metrics in MR do not regress.
GHC is not slowed down.
I also run `nofib` using `--cachegrind -s Norm -j 16`, geometric means:
- allocations: -0.12%
- instructions: +0.05%
- LLC cache misses: +0.58%
- L1 cache misses: +0.03%
And also using `--perf` (without `-j`):
- perf instructions: +0.02%
- perf cycles: -0.80%
I don't know if this in bounds of "small changes to GHC".
For me this looks acceptable.
---
There is also off-thread blog post from 2018.
https://neilmitchell.blogspot.com/2018/03/safe-library-with-better-stack-tr…
referencing e.g.
https://hackage.haskell.org/package/extra-1.7.9/docs/Data-List-Extra.html#v…
and https://hackage.haskell.org/package/safe
safe library has plenty of reverse dependencies:
https://packdeps.haskellers.com/reverse/safe, and extra is used by shake.
---
In summary:
- fromJust has HasCallStack, head doesn't. Let us fix this.
- Ben asked for patch so we can test performance, now such patch exists,
and it passes GHC CI.
- GHC itself uses partial functions, its performance metrics don't
regress
- -prof and +RTS -xc is an option, but it needs special build of an
executable.
- This is ultimately for CLC to decide, so chessai, emilypi please tell
your opinion.
Discussion period one month, until 2021-06-30 (end of June this year).
Oleg
[1]: https://gitlab.haskell.org/ghc/ghc/-/issues/17040#note_231634
[2]: https://mail.haskell.org/pipermail/libraries/2019-November/030059.html
https://gitlab.haskell.org/ghc/ghc/-/issues/13573
[3]: https://gitlab.haskell.org/ghc/ghc/-/issues/17040#note_218035
[4]: https://gitlab.haskell.org/ghc/ghc/-/issues/15559
[5]: https://mail.haskell.org/pipermail/libraries/2019-June/029665.html
[6]: https://mail.haskell.org/pipermail/libraries/2019-June/029666.html
[7]: https://mail.haskell.org/pipermail/libraries/2019-June/029672.html
[8]: https://mail.haskell.org/pipermail/libraries/2019-June/029667.html
---
# bytes allocated
+-------------------------------++--+-------------+------------------+
| || | master/ | callstack/ (rel) |
+===============================++==+=============+==================+
| imaginary/bernouilli || | 2.823e9 | 0.00% |
| imaginary/digits-of-e1 || | 1.069e9 | 0.00% |
| imaginary/digits-of-e2 || | 2.152e9 | 0.00% |
| imaginary/exp3_8 || | 5.888e9 | 0.00% |
| imaginary/gen_regexps || | 9.104e8 | 0.00% |
| imaginary/integrate || | 3.768e9 | 0.00% |
| imaginary/kahan || | 49088.000 | 0.00% |
| imaginary/paraffins || | 3.829e9 | 0.00% |
| imaginary/primes || | 2.928e9 | 0.00% |
| imaginary/queens || | 6.709e8 | 0.00% |
| imaginary/rfib || | 139952.000 | 0.00% |
| imaginary/tak || | 97344.000 | 0.00% |
| imaginary/wheel-sieve1 || | 1.344e8 | 0.00% |
| imaginary/wheel-sieve2 || | 2.430e9 | 0.00% |
| imaginary/x2n1 || | 2.561e8 | 0.00% |
| parallel/blackscholes || | 1.980e9 | 0.00% |
| parallel/coins || | 5.252e9 | 0.00% |
| parallel/gray || | 2.010e9 | +0.00% |
| parallel/mandel || | 8.524e9 | 0.00% |
| parallel/matmult || | 8.974e7 | 0.00% |
| parallel/minimax || | 2.212e10 | 0.00% |
| parallel/nbody || | 1498304.000 | 0.00% |
| parallel/parfib || | 3.651e8 | 0.00% |
| parallel/partree || | 3.290e9 | 0.00% |
| parallel/prsa || | 2.097e9 | 0.00% |
| parallel/queens || | 6.846e8 | 0.00% |
| parallel/ray || | 1.357e10 | 0.00% |
| parallel/sumeuler || | 1785016.000 | 0.00% |
| parallel/transclos || | 8.976e9 | 0.00% |
| real/anna || | 2.022e9 | +0.01% |
| real/ben-raytrace || | 3.418e10 | 0.00% |
| real/bspt || | 3.747e9 | 0.00% |
| real/cacheprof || | 2.689e9 | 0.00% |
| real/compress || | 2.807e9 | 0.00% |
| real/compress2 || | 3.436e9 | 0.00% |
| real/eff/CS || | 1.601e8 | 0.00% |
| real/eff/CSD || | 1.600e9 | 0.00% |
| real/eff/FS || | 1.760e9 | 0.00% |
| real/eff/S || | 2.401e8 | 0.00% |
| real/eff/VS || | 4.831e8 | 0.00% |
| real/eff/VSD || | 50736.000 | 0.00% |
| real/eff/VSM || | 4.001e8 | 0.00% |
| real/fem || | 4.947e9 | -2.81% |
| real/fluid || | 2.169e9 | -0.00% |
| real/fulsom || | 1.961e9 | 0.00% |
| real/gamteb || | 4.447e9 | 0.00% |
| real/gg || | 2.654e9 | 0.00% |
| real/grep || | 4.623e9 | 0.00% |
| real/hidden || | 5.100e9 | 0.00% |
| real/hpg || | 3.160e9 | -0.10% |
| real/infer || | 1.731e9 | 0.00% |
| real/lift || | 2.761e9 | 0.00% |
| real/linear || | 5.412e9 | -0.07% |
| real/maillist || | 3.331e9 | 0.00% |
| real/mkhprog || | 9748392.000 | 0.00% |
| real/parser || | 2.666e9 | 0.00% |
| real/pic || | 1.469e9 | 0.00% |
| real/prolog || | 2.922e9 | -0.02% |
| real/reptile || | 5.121e9 | 0.00% |
| real/rsa || | 8.414e8 | 0.00% |
| real/scs || | 4.044e9 | 0.00% |
| real/smallpt || | 2.874e9 | 0.00% |
| real/symalg || | 3.195e8 | 0.00% |
| real/veritas || | 4.172e9 | 0.00% |
| shootout/binary-trees || | 4.300e9 | 0.00% |
| shootout/fannkuch-redux || | 69144.000 | -0.03% |
| shootout/fasta || | 1.718e9 | +0.00% |
| shootout/k-nucleotide || | 7.081e7 | +0.00% |
| shootout/n-body || | 130608.000 | 0.00% |
| shootout/pidigits || | 1.027e10 | 0.00% |
| shootout/reverse-complement || | 59768.000 | 0.00% |
| shootout/spectral-norm || | 178112.000 | 0.00% |
| smp/callback001 || | 1.114e9 | 0.00% |
| smp/callback002 || | 3.264e9 | 0.00% |
| smp/chan || | 1.240e9 | 0.00% |
| smp/sieve || | 1.410e9 | 0.00% |
| smp/threads001 || | 1.072e10 | 0.00% |
| smp/threads003 || | 3.051e8 | -0.01% |
| smp/threads006 || | 2.242e8 | 0.00% |
| smp/threads007 || | 1.778e9 | -0.00% |
| spectral/ansi || | 6.713e9 | 0.00% |
| spectral/atom || | 3.580e9 | 0.00% |
| spectral/awards || | 4.759e9 | 0.00% |
| spectral/banner || | 6.156e9 | 0.00% |
| spectral/boyer || | 4.665e9 | 0.00% |
| spectral/boyer2 || | 1.153e9 | 0.00% |
| spectral/calendar || | 7.102e9 | 0.00% |
| spectral/cichelli || | 1.969e9 | 0.00% |
| spectral/circsim || | 4.850e9 | 0.00% |
| spectral/clausify || | 2.095e9 | 0.00% |
| spectral/constraints || | 4.872e9 | 0.00% |
| spectral/cryptarithm1 || | 5.981e9 | 0.00% |
| spectral/cryptarithm2 || | 3.663e9 | 0.00% |
| spectral/cse || | 3.802e9 | 0.00% |
| spectral/dom-lt || | 3.890e9 | 0.00% |
| spectral/eliza || | 4.102e9 | +0.00% |
| spectral/exact-reals || | 9.584e8 | -0.00% |
| spectral/expert || | 2.090e9 | 0.00% |
| spectral/fft2 || | 1.431e9 | -0.22% |
| spectral/fibheaps || | 4.737e9 | 0.00% |
| spectral/fish || | 6.193e9 | 0.00% |
| spectral/gcd || | 2.069e9 | 0.00% |
| spectral/hartel/comp_lab_zift || | 4.740e9 | 0.00% |
| spectral/hartel/event || | 3.635e9 | -12.13% |
| spectral/hartel/fft || | 1.611e9 | 0.00% |
| spectral/hartel/genfft || | 8.020e9 | 0.00% |
| spectral/hartel/ida || | 3.515e9 | 0.00% |
| spectral/hartel/listcompr || | 6.157e9 | 0.00% |
| spectral/hartel/listcopy || | 6.758e9 | 0.00% |
| spectral/hartel/nucleic2 || | 2.965e9 | 0.00% |
| spectral/hartel/parstof || | 1.368e9 | 0.00% |
| spectral/hartel/sched || | 3.675e9 | 0.00% |
| spectral/hartel/solid || | 3.509e9 | 0.00% |
| spectral/hartel/transform || | 3.959e9 | 0.00% |
| spectral/hartel/typecheck || | 2.570e9 | 0.00% |
| spectral/hartel/wang || | 4.735e9 | 0.00% |
| spectral/hartel/wave4main || | 1.147e9 | 0.00% |
| spectral/integer || | 3.260e9 | 0.00% |
| spectral/knights || | 1.094e9 | 0.00% |
| spectral/lambda || | 2.950e9 | 0.00% |
| spectral/last-piece || | 6.852e8 | 0.00% |
| spectral/lcss || | 6.565e9 | 0.00% |
| spectral/life || | 6.799e9 | 0.00% |
| spectral/mandel || | 1.972e9 | 0.00% |
| spectral/mandel2 || | 5.231e8 | 0.00% |
| spectral/mate || | 4.598e9 | 0.00% |
| spectral/minimax || | 2.683e9 | 0.00% |
| spectral/multiplier || | 2.850e9 | 0.00% |
| spectral/para || | 4.056e9 | 0.00% |
| spectral/power || | 1.428e9 | 0.00% |
| spectral/pretty || | 136880.000 | -0.11% |
| spectral/primetest || | 8.455e8 | 0.00% |
| spectral/puzzle || | 1.809e9 | 0.00% |
| spectral/rewrite || | 1.694e9 | 0.00% |
| spectral/scc || | 58280.000 | 0.00% |
| spectral/simple || | 2.316e9 | 0.00% |
| spectral/sorting || | 3.078e9 | 0.00% |
| spectral/sphere || | 2.298e9 | 0.00% |
| spectral/treejoin || | 2.796e9 | 0.00% |
+===============================++==+=============+==================+
| geom mean || | -0.12% | |
+-------------------------------++--+-------------+------------------+
# instructions
+-------------------------------++--+------------+------------------+
| || | master/ | callstack/ (rel) |
+===============================++==+============+==================+
| imaginary/bernouilli || | 7.057e9 | +0.00% |
| imaginary/digits-of-e1 || | 5.549e9 | -0.00% |
| imaginary/digits-of-e2 || | 5.555e9 | -0.01% |
| imaginary/exp3_8 || | 8.779e9 | +0.03% |
| imaginary/gen_regexps || | 8.650e9 | -0.00% |
| imaginary/integrate || | 6.276e9 | +0.00% |
| imaginary/kahan || | 6.707e9 | +0.00% |
| imaginary/paraffins || | 8.089e9 | -0.00% |
| imaginary/primes || | 8.278e9 | +0.01% |
| imaginary/queens || | 1.010e10 | -0.00% |
| imaginary/rfib || | 5.299e9 | +0.00% |
| imaginary/tak || | 5.867e9 | +0.00% |
| imaginary/wheel-sieve1 || | 6.615e9 | +0.04% |
| imaginary/wheel-sieve2 || | 6.286e9 | +0.02% |
| imaginary/x2n1 || | 7.452e9 | +0.00% |
| parallel/blackscholes || | 8.022e9 | +0.00% |
| parallel/coins || | 1.149e10 | +0.00% |
| parallel/gray || | 6.141e9 | +0.14% |
| parallel/mandel || | 3.288e10 | -0.01% |
| parallel/matmult || | 1.115e10 | -0.00% |
| parallel/minimax || | 3.863e10 | -0.08% |
| parallel/nbody || | 7.939e8 | +0.00% |
| parallel/parfib || | 2.231e10 | +0.00% |
| parallel/partree || | 7.347e9 | +0.01% |
| parallel/prsa || | 1.811e10 | -0.00% |
| parallel/queens || | 1.037e10 | +0.00% |
| parallel/ray || | 1.299e10 | +0.00% |
| parallel/sumeuler || | 3.483e9 | +0.00% |
| parallel/transclos || | 1.982e10 | +0.00% |
| real/anna || | 5.343e9 | +0.05% |
| real/ben-raytrace || | 1.215e11 | +0.00% |
| real/bspt || | 9.226e9 | -0.00% |
| real/cacheprof || | 6.763e9 | +0.02% |
| real/compress || | 5.820e9 | -0.00% |
| real/compress2 || | 4.569e9 | +0.00% |
| real/eff/CS || | 7.758e8 | +0.00% |
| real/eff/CSD || | 3.745e9 | +0.00% |
| real/eff/FS || | 2.799e9 | +0.00% |
| real/eff/S || | 4.334e9 | +0.00% |
| real/eff/VS || | 2.221e9 | +0.01% |
| real/eff/VSD || | 8.075e7 | +0.00% |
| real/eff/VSM || | 9.635e8 | +0.00% |
| real/fem || | 6.649e9 | -0.64% |
| real/fluid || | 3.904e9 | -0.00% |
| real/fulsom || | 2.490e9 | +0.00% |
| real/gamteb || | 1.013e10 | +0.01% |
| real/gg || | 7.253e9 | +0.01% |
| real/grep || | 7.546e9 | +0.00% |
| real/hidden || | 7.198e9 | +1.64% |
| real/hpg || | 4.966e9 | +0.88% |
| real/infer || | 8.318e9 | +0.00% |
| real/lift || | 4.430e9 | -0.00% |
| real/linear || | 8.436e9 | +1.97% |
| real/maillist || | 1.974e9 | +0.05% |
| real/mkhprog || | 2.249e7 | +0.00% |
| real/parser || | 5.178e9 | -0.00% |
| real/pic || | 3.268e9 | -0.00% |
| real/prolog || | 5.742e9 | +0.01% |
| real/reptile || | 6.046e9 | +0.00% |
| real/rsa || | 7.191e9 | +0.00% |
| real/scs || | 6.174e9 | +0.00% |
| real/smallpt || | 1.128e10 | +0.00% |
| real/symalg || | 8.230e9 | +0.00% |
| real/veritas || | 4.832e9 | -0.01% |
| shootout/binary-trees || | 1.073e10 | +0.01% |
| shootout/fannkuch-redux || | 1.909e10 | -0.00% |
| shootout/fasta || | 4.189e9 | +0.00% |
| shootout/k-nucleotide || | 4.219e9 | +0.01% |
| shootout/n-body || | 3.721e9 | +0.00% |
| shootout/pidigits || | 8.084e9 | +0.00% |
| shootout/reverse-complement || | 781364.000 | +0.51% |
| shootout/spectral-norm || | 4.252e9 | +0.00% |
| smp/callback001 || | 1.573e9 | +0.01% |
| smp/callback002 || | 2.621e9 | +0.00% |
| smp/chan || | 8.718e9 | +2.56% |
| smp/sieve || | 5.538e9 | -0.87% |
| smp/threads001 || | 5.139e9 | -0.00% |
| smp/threads003 || | 2.903e9 | -0.05% |
| smp/threads006 || | 7.402e8 | +0.01% |
| smp/threads007 || | 4.090e9 | -0.00% |
| spectral/ansi || | 5.961e9 | -0.00% |
| spectral/atom || | 5.861e9 | +0.01% |
| spectral/awards || | 8.744e9 | +0.00% |
| spectral/banner || | 8.824e9 | +0.23% |
| spectral/boyer || | 7.657e9 | -0.00% |
| spectral/boyer2 || | 8.881e9 | -0.00% |
| spectral/calendar || | 7.546e9 | -0.00% |
| spectral/cichelli || | 8.625e9 | +0.01% |
| spectral/circsim || | 6.850e9 | +0.00% |
| spectral/clausify || | 6.223e9 | -0.00% |
| spectral/constraints || | 8.314e9 | +0.14% |
| spectral/cryptarithm1 || | 7.787e9 | -0.00% |
| spectral/cryptarithm2 || | 6.761e9 | +0.00% |
| spectral/cse || | 6.358e9 | -0.00% |
| spectral/dom-lt || | 7.774e9 | -0.00% |
| spectral/eliza || | 8.273e9 | +0.00% |
| spectral/exact-reals || | 5.597e9 | +0.01% |
| spectral/expert || | 5.087e9 | +0.04% |
| spectral/fft2 || | 8.831e9 | +0.31% |
| spectral/fibheaps || | 8.011e9 | -0.00% |
| spectral/fish || | 7.314e9 | -0.00% |
| spectral/gcd || | 6.386e9 | -0.00% |
| spectral/hartel/comp_lab_zift || | 8.717e9 | -0.00% |
| spectral/hartel/event || | 9.071e9 | -2.06% |
| spectral/hartel/fft || | 3.239e9 | +0.00% |
| spectral/hartel/genfft || | 1.020e10 | +0.00% |
| spectral/hartel/ida || | 5.413e9 | -0.30% |
| spectral/hartel/listcompr || | 6.142e9 | +0.02% |
| spectral/hartel/listcopy || | 6.757e9 | +0.02% |
| spectral/hartel/nucleic2 || | 4.402e9 | +0.00% |
| spectral/hartel/parstof || | 5.555e9 | -0.00% |
| spectral/hartel/sched || | 5.800e9 | +0.00% |
| spectral/hartel/solid || | 5.845e9 | +0.24% |
| spectral/hartel/transform || | 5.709e9 | -0.00% |
| spectral/hartel/typecheck || | 5.841e9 | +0.00% |
| spectral/hartel/wang || | 8.731e9 | +0.12% |
| spectral/hartel/wave4main || | 6.024e9 | -0.00% |
| spectral/integer || | 7.068e9 | -0.00% |
| spectral/knights || | 8.294e9 | -0.00% |
| spectral/lambda || | 8.081e9 | +0.00% |
| spectral/last-piece || | 1.878e9 | +0.00% |
| spectral/lcss || | 8.761e9 | -0.00% |
| spectral/life || | 9.136e9 | -0.00% |
| spectral/mandel || | 7.037e9 | +0.00% |
| spectral/mandel2 || | 3.957e9 | +0.00% |
| spectral/mate || | 7.565e9 | +0.01% |
| spectral/minimax || | 8.649e9 | -0.00% |
| spectral/multiplier || | 6.096e9 | +0.00% |
| spectral/para || | 6.561e9 | +0.00% |
| spectral/power || | 6.749e9 | -0.00% |
| spectral/pretty || | 851224.000 | +0.17% |
| spectral/primetest || | 7.391e9 | -0.00% |
| spectral/puzzle || | 6.401e9 | +0.00% |
| spectral/rewrite || | 5.553e9 | +0.67% |
| spectral/scc || | 774059.000 | +0.49% |
| spectral/simple || | 1.214e10 | +0.01% |
| spectral/sorting || | 9.074e9 | -0.00% |
| spectral/sphere || | 5.371e9 | -0.00% |
| spectral/treejoin || | 9.768e9 | +0.00% |
+===============================++==+============+==================+
| geom mean || | +0.05% | |
+-------------------------------++--+------------+------------------+
# LLC cache misses
+-------------------------------++--+-------------+------------------+
| || | master/ | callstack/ (rel) |
+===============================++==+=============+==================+
| imaginary/bernouilli || | 4964.000 | +1.37% |
| imaginary/digits-of-e1 || | 4863.000 | -0.35% |
| imaginary/digits-of-e2 || | 4958.000 | +1.63% |
| imaginary/exp3_8 || | 4513.000 | +0.42% |
| imaginary/gen_regexps || | 4535.000 | +0.09% |
| imaginary/integrate || | 4733.000 | +1.08% |
| imaginary/kahan || | 4447.000 | -0.13% |
| imaginary/paraffins || | 4826.000 | -0.08% |
| imaginary/primes || | 4876.000 | +0.94% |
| imaginary/queens || | 4541.000 | -0.07% |
| imaginary/rfib || | 4485.000 | -0.13% |
| imaginary/tak || | 4461.000 | +0.25% |
| imaginary/wheel-sieve1 || | 4865.000 | +1.29% |
| imaginary/wheel-sieve2 || | 4893.000 | +1.25% |
| imaginary/x2n1 || | 4630.000 | +0.22% |
| parallel/blackscholes || | 12862.000 | +0.30% |
| parallel/coins || | 6455583.000 | +0.00% |
| parallel/gray || | 6372.000 | +1.77% |
| parallel/mandel || | 852468.000 | -0.02% |
| parallel/matmult || | 4615.000 | -0.30% |
| parallel/minimax || | 4617.000 | +0.84% |
| parallel/nbody || | 4455.000 | -0.04% |
| parallel/parfib || | 4528.000 | +0.22% |
| parallel/partree || | 4627.000 | +0.43% |
| parallel/prsa || | 4619.000 | +0.54% |
| parallel/queens || | 4528.000 | +1.37% |
| parallel/ray || | 4626.000 | +0.35% |
| parallel/sumeuler || | 4446.000 | +0.13% |
| parallel/transclos || | 4741.000 | -0.17% |
| real/anna || | 6443.000 | +5.34% |
| real/ben-raytrace || | 6819.000 | -0.13% |
| real/bspt || | 5195.000 | -0.21% |
| real/cacheprof || | 6734.000 | +1.62% |
| real/compress || | 4914.000 | +0.53% |
| real/compress2 || | 4783.000 | -0.25% |
| real/eff/CS || | 4439.000 | +0.38% |
| real/eff/CSD || | 4446.000 | 0.00% |
| real/eff/FS || | 4451.000 | -0.04% |
| real/eff/S || | 5619842.000 | -0.00% |
| real/eff/VS || | 1254362.000 | +0.00% |
| real/eff/VSD || | 4403.000 | -0.43% |
| real/eff/VSM || | 4445.000 | -0.11% |
| real/fem || | 4967.000 | +2.07% |
| real/fluid || | 6117.000 | +0.85% |
| real/fulsom || | 5060.000 | -0.10% |
| real/gamteb || | 5615.000 | +0.64% |
| real/gg || | 5242.000 | +0.88% |
| real/grep || | 4866.000 | +0.62% |
| real/hidden || | 5576.000 | +2.06% |
| real/hpg || | 5614.000 | +2.92% |
| real/infer || | 4833.000 | -0.14% |
| real/lift || | 4809.000 | +1.48% |
| real/linear || | 5368.000 | +4.53% |
| real/maillist || | 12942.000 | +0.32% |
| real/mkhprog || | 4483.000 | +0.20% |
| real/parser || | 5309.000 | +1.64% |
| real/pic || | 4937.000 | +0.81% |
| real/prolog || | 4843.000 | +1.03% |
| real/reptile || | 5548.000 | -0.43% |
| real/rsa || | 4667.000 | +0.26% |
| real/scs || | 5667.000 | +1.48% |
| real/smallpt || | 5836.000 | +1.29% |
| real/symalg || | 5422.000 | +0.30% |
| real/veritas || | 6984.000 | +2.61% |
| shootout/binary-trees || | 5079.000 | +0.73% |
| shootout/fannkuch-redux || | 4478.000 | -0.51% |
| shootout/fasta || | 4625.000 | -0.13% |
| shootout/k-nucleotide || | 1161663.000 | -2.58% |
| shootout/n-body || | 4512.000 | +0.04% |
| shootout/pidigits || | 4651.000 | -0.39% |
| shootout/reverse-complement || | 4416.000 | 0.00% |
| shootout/spectral-norm || | 4477.000 | +0.25% |
| smp/callback001 || | 488453.000 | -0.01% |
| smp/callback002 || | 4513.000 | -0.11% |
| smp/chan || | 1.110e7 | +7.03% |
| smp/sieve || | 4555.000 | +0.72% |
| smp/threads001 || | 4481.000 | +0.49% |
| smp/threads003 || | 83898.000 | -1.63% |
| smp/threads006 || | 1804659.000 | +0.49% |
| smp/threads007 || | 2427701.000 | -0.24% |
| spectral/ansi || | 4759.000 | +0.27% |
| spectral/atom || | 4691.000 | +0.62% |
| spectral/awards || | 4717.000 | +1.14% |
| spectral/banner || | 5056.000 | +1.21% |
| spectral/boyer || | 5045.000 | +0.06% |
| spectral/boyer2 || | 4832.000 | -0.04% |
| spectral/calendar || | 4622.000 | +0.74% |
| spectral/cichelli || | 4728.000 | +1.67% |
| spectral/circsim || | 40269.000 | -1.55% |
| spectral/clausify || | 4835.000 | -0.17% |
| spectral/constraints || | 4871.000 | +1.44% |
| spectral/cryptarithm1 || | 4562.000 | +0.18% |
| spectral/cryptarithm2 || | 4600.000 | +0.07% |
| spectral/cse || | 4534.000 | +0.33% |
| spectral/dom-lt || | 5179.000 | +0.10% |
| spectral/eliza || | 4968.000 | +0.34% |
| spectral/exact-reals || | 4840.000 | +1.34% |
| spectral/expert || | 4770.000 | +2.81% |
| spectral/fft2 || | 5296.000 | +1.91% |
| spectral/fibheaps || | 4858.000 | +0.02% |
| spectral/fish || | 4687.000 | +0.04% |
| spectral/gcd || | 4575.000 | +0.22% |
| spectral/hartel/comp_lab_zift || | 4960.000 | +0.58% |
| spectral/hartel/event || | 4875.000 | +0.96% |
| spectral/hartel/fft || | 5121.000 | +0.70% |
| spectral/hartel/genfft || | 4875.000 | +0.04% |
| spectral/hartel/ida || | 4877.000 | +0.84% |
| spectral/hartel/listcompr || | 4651.000 | +1.76% |
| spectral/hartel/listcopy || | 4649.000 | +1.96% |
| spectral/hartel/nucleic2 || | 5998.000 | +0.68% |
| spectral/hartel/parstof || | 5583.000 | -0.05% |
| spectral/hartel/sched || | 4856.000 | -0.23% |
| spectral/hartel/solid || | 5282.000 | +1.21% |
| spectral/hartel/transform || | 4875.000 | +1.56% |
| spectral/hartel/typecheck || | 4724.000 | +0.95% |
| spectral/hartel/wang || | 4993.000 | +2.38% |
| spectral/hartel/wave4main || | 4877.000 | -0.04% |
| spectral/integer || | 4619.000 | -0.13% |
| spectral/knights || | 4694.000 | +0.58% |
| spectral/lambda || | 4984.000 | +0.66% |
| spectral/last-piece || | 4869.000 | -0.21% |
| spectral/lcss || | 4876.000 | +0.04% |
| spectral/life || | 4884.000 | +1.29% |
| spectral/mandel || | 4900.000 | +0.16% |
| spectral/mandel2 || | 4479.000 | -0.13% |
| spectral/mate || | 5086.000 | +1.83% |
| spectral/minimax || | 4605.000 | -0.04% |
| spectral/multiplier || | 4672.000 | +0.98% |
| spectral/para || | 4935.000 | +0.83% |
| spectral/power || | 4918.000 | +0.18% |
| spectral/pretty || | 4432.000 | +0.14% |
| spectral/primetest || | 5021.000 | -0.04% |
| spectral/puzzle || | 4603.000 | +0.04% |
| spectral/rewrite || | 4618.000 | +0.97% |
| spectral/scc || | 4415.000 | +0.34% |
| spectral/simple || | 2413361.000 | -1.18% |
| spectral/sorting || | 5357.000 | -1.55% |
| spectral/sphere || | 5717.000 | +0.84% |
| spectral/treejoin || | 5130.000 | +0.02% |
+===============================++==+=============+==================+
| geom mean || | +0.58% | |
+-------------------------------++--+-------------+------------------+
# L1 cache misses
+-------------------------------++--+-------------+------------------+
| || | master/ | callstack/ (rel) |
+===============================++==+=============+==================+
| imaginary/bernouilli || | 4.235e7 | +0.13% |
| imaginary/digits-of-e1 || | 3708507.000 | -0.06% |
| imaginary/digits-of-e2 || | 2.913e7 | -0.16% |
| imaginary/exp3_8 || | 1.881e8 | -0.07% |
| imaginary/gen_regexps || | 2.915e7 | -0.05% |
| imaginary/integrate || | 1341520.000 | -4.99% |
| imaginary/kahan || | 7577.000 | +0.15% |
| imaginary/paraffins || | 5.994e7 | -0.02% |
| imaginary/primes || | 1.165e8 | -0.01% |
| imaginary/queens || | 315321.000 | -0.94% |
| imaginary/rfib || | 7833.000 | -0.46% |
| imaginary/tak || | 7688.000 | +0.03% |
| imaginary/wheel-sieve1 || | 7508229.000 | +0.51% |
| imaginary/wheel-sieve2 || | 4.338e7 | -0.02% |
| imaginary/x2n1 || | 129793.000 | +0.50% |
| parallel/blackscholes || | 1.550e7 | -0.16% |
| parallel/coins || | 3.952e7 | +0.26% |
| parallel/gray || | 1.736e7 | +1.38% |
| parallel/mandel || | 1.356e7 | +0.20% |
| parallel/matmult || | 5.267e8 | -0.01% |
| parallel/minimax || | 1.140e8 | -0.14% |
| parallel/nbody || | 1.248e7 | -0.02% |
| parallel/parfib || | 252463.000 | +6.49% |
| parallel/partree || | 5.642e7 | +0.08% |
| parallel/prsa || | 5700667.000 | +0.27% |
| parallel/queens || | 3129546.000 | +0.19% |
| parallel/ray || | 1.260e7 | +4.27% |
| parallel/sumeuler || | 35221.000 | -0.07% |
| parallel/transclos || | 1.863e7 | +0.17% |
| real/anna || | 3.737e7 | +0.10% |
| real/ben-raytrace || | 6.695e7 | +0.59% |
| real/bspt || | 1.492e8 | +0.01% |
| real/cacheprof || | 5.661e7 | -0.24% |
| real/compress || | 3.247e7 | -2.71% |
| real/compress2 || | 2.717e7 | +0.13% |
| real/eff/CS || | 54141.000 | -0.28% |
| real/eff/CSD || | 532877.000 | -0.07% |
| real/eff/FS || | 512883.000 | +0.18% |
| real/eff/S || | 1.412e7 | -0.07% |
| real/eff/VS || | 6730192.000 | -0.42% |
| real/eff/VSD || | 7449.000 | -0.30% |
| real/eff/VSM || | 121912.000 | -0.22% |
| real/fem || | 3.841e7 | +6.86% |
| real/fluid || | 1.579e7 | +0.91% |
| real/fulsom || | 1.036e7 | +0.03% |
| real/gamteb || | 3.473e7 | -0.02% |
| real/gg || | 7.439e7 | +0.09% |
| real/grep || | 7.940e7 | +0.08% |
| real/hidden || | 1.074e7 | +0.20% |
| real/hpg || | 1.757e7 | +0.32% |
| real/infer || | 2.006e8 | -0.02% |
| real/lift || | 2.741e7 | +0.20% |
| real/linear || | 8.899e7 | +1.27% |
| real/maillist || | 9646364.000 | -0.06% |
| real/mkhprog || | 11950.000 | +3.72% |
| real/parser || | 1.269e7 | +0.92% |
| real/pic || | 4.450e7 | -0.24% |
| real/prolog || | 2.973e7 | -0.34% |
| real/reptile || | 1.945e7 | -0.07% |
| real/rsa || | 1310283.000 | -0.18% |
| real/scs || | 1.916e7 | +0.06% |
| real/smallpt || | 7088127.000 | +0.47% |
| real/symalg || | 5981494.000 | -0.11% |
| real/veritas || | 1.860e7 | -1.22% |
| shootout/binary-trees || | 3.661e7 | +0.01% |
| shootout/fannkuch-redux || | 7741.000 | -0.62% |
| shootout/fasta || | 5.215e7 | +0.01% |
| shootout/k-nucleotide || | 1.247e7 | +0.01% |
| shootout/n-body || | 8025.000 | +0.04% |
| shootout/pidigits || | 2.316e8 | +0.02% |
| shootout/reverse-complement || | 7627.000 | -0.20% |
| shootout/spectral-norm || | 21764.000 | +0.23% |
| smp/callback001 || | 5824201.000 | +0.07% |
| smp/callback002 || | 8288204.000 | -0.09% |
| smp/chan || | 2.846e7 | +2.62% |
| smp/sieve || | 5.400e7 | -1.10% |
| smp/threads001 || | 2.312e7 | +0.45% |
| smp/threads003 || | 4.773e7 | -0.22% |
| smp/threads006 || | 9331792.000 | +0.02% |
| smp/threads007 || | 2.721e7 | +0.36% |
| spectral/ansi || | 6.940e7 | -0.01% |
| spectral/atom || | 1.248e8 | +0.01% |
| spectral/awards || | 7810137.000 | -1.82% |
| spectral/banner || | 3.727e7 | +2.57% |
| spectral/boyer || | 2.284e7 | -0.19% |
| spectral/boyer2 || | 3.926e7 | -0.63% |
| spectral/calendar || | 7366268.000 | -0.91% |
| spectral/cichelli || | 1.797e7 | +0.02% |
| spectral/circsim || | 9.138e7 | +0.07% |
| spectral/clausify || | 6134801.000 | -0.11% |
| spectral/constraints || | 2.950e7 | +0.38% |
| spectral/cryptarithm1 || | 3139494.000 | +0.08% |
| spectral/cryptarithm2 || | 3481535.000 | +0.35% |
| spectral/cse || | 4798864.000 | -7.01% |
| spectral/dom-lt || | 2.556e7 | -0.11% |
| spectral/eliza || | 1.921e7 | +1.14% |
| spectral/exact-reals || | 2391927.000 | +1.24% |
| spectral/expert || | 2.311e7 | -0.08% |
| spectral/fft2 || | 1.917e8 | +0.81% |
| spectral/fibheaps || | 5.236e7 | -0.06% |
| spectral/fish || | 8017906.000 | +0.13% |
| spectral/gcd || | 1652038.000 | +0.07% |
| spectral/hartel/comp_lab_zift || | 6.167e7 | -0.11% |
| spectral/hartel/event || | 4.857e7 | -2.47% |
| spectral/hartel/fft || | 3.723e7 | -0.04% |
| spectral/hartel/genfft || | 2.201e7 | +1.31% |
| spectral/hartel/ida || | 1.316e7 | +0.16% |
| spectral/hartel/listcompr || | 9143834.000 | +1.54% |
| spectral/hartel/listcopy || | 1.018e7 | +2.27% |
| spectral/hartel/nucleic2 || | 1.035e7 | -2.83% |
| spectral/hartel/parstof || | 2.290e7 | -2.36% |
| spectral/hartel/sched || | 6090930.000 | -0.15% |
| spectral/hartel/solid || | 3.408e7 | +0.00% |
| spectral/hartel/transform || | 2.255e7 | +0.25% |
| spectral/hartel/typecheck || | 1.447e7 | -1.37% |
| spectral/hartel/wang || | 1.089e8 | +0.19% |
| spectral/hartel/wave4main || | 8.229e7 | +0.29% |
| spectral/integer || | 1101168.000 | -0.06% |
| spectral/knights || | 3.424e7 | +0.92% |
| spectral/lambda || | 6.667e7 | +0.14% |
| spectral/last-piece || | 3620219.000 | -0.43% |
| spectral/lcss || | 7.252e7 | -0.26% |
| spectral/life || | 1.231e8 | -0.11% |
| spectral/mandel || | 741678.000 | +0.09% |
| spectral/mandel2 || | 311375.000 | +0.79% |
| spectral/mate || | 4858523.000 | -1.23% |
| spectral/minimax || | 1172869.000 | +0.51% |
| spectral/multiplier || | 1.060e8 | +0.03% |
| spectral/para || | 5.089e7 | +0.15% |
| spectral/power || | 4.488e7 | -0.00% |
| spectral/pretty || | 7649.000 | +0.38% |
| spectral/primetest || | 500918.000 | +1.32% |
| spectral/puzzle || | 3210919.000 | -0.09% |
| spectral/rewrite || | 825290.000 | -7.73% |
| spectral/scc || | 7483.000 | +0.16% |
| spectral/simple || | 8.786e7 | +0.01% |
| spectral/sorting || | 1.261e8 | -0.02% |
| spectral/sphere || | 4854033.000 | +0.43% |
| spectral/treejoin || | 8.455e7 | +0.03% |
+===============================++==+=============+==================+
| geom mean || | +0.03% | |
+-------------------------------++--+-------------+------------------+
# perf instructions
+-------------------------------++--+-------------+------------------+
| || | master/ | callstack/ (rel) |
+===============================++==+=============+==================+
| imaginary/bernouilli || | 7.085e9 | -0.22% |
| imaginary/digits-of-e1 || | 5.547e9 | -0.03% |
| imaginary/digits-of-e2 || | 5.549e9 | -0.06% |
| imaginary/exp3_8 || | 8.785e9 | -0.06% |
| imaginary/gen_regexps || | 8.650e9 | -0.04% |
| imaginary/integrate || | 6.260e9 | +0.20% |
| imaginary/kahan || | 6.699e9 | +0.16% |
| imaginary/paraffins || | 8.112e9 | -0.24% |
| imaginary/primes || | 8.244e9 | -0.24% |
| imaginary/queens || | 1.009e10 | +0.04% |
| imaginary/rfib || | 5.298e9 | +0.14% |
| imaginary/tak || | 5.861e9 | +0.10% |
| imaginary/wheel-sieve1 || | 6.662e9 | -0.76% |
| imaginary/wheel-sieve2 || | 6.278e9 | +0.38% |
| imaginary/x2n1 || | 7.453e9 | -0.12% |
| parallel/blackscholes || | 8.096e9 | -0.18% |
| parallel/coins || | 1.194e10 | -0.03% |
| parallel/gray || | 6.154e9 | -0.07% |
| parallel/mandel || | 3.293e10 | +0.12% |
| parallel/matmult || | 1.118e10 | +0.06% |
| parallel/minimax || | 3.867e10 | -0.11% |
| parallel/nbody || | 7.934e8 | +0.05% |
| parallel/parfib || | 2.232e10 | -0.01% |
| parallel/partree || | 7.358e9 | +0.02% |
| parallel/prsa || | 1.808e10 | +0.14% |
| parallel/queens || | 1.037e10 | -0.03% |
| parallel/ray || | 1.301e10 | +0.01% |
| parallel/sumeuler || | 3.487e9 | -0.01% |
| parallel/transclos || | 1.983e10 | -0.02% |
| real/anna || | 5.334e9 | +0.27% |
| real/ben-raytrace || | 1.216e11 | -0.02% |
| real/bspt || | 9.224e9 | -0.05% |
| real/cacheprof || | 6.735e9 | -0.46% |
| real/compress || | 5.810e9 | +0.07% |
| real/compress2 || | 4.580e9 | -0.21% |
| real/eff/CS || | 7.582e8 | +1.19% |
| real/eff/CSD || | 3.758e9 | -0.56% |
| real/eff/FS || | 2.792e9 | +0.02% |
| real/eff/S || | 4.760e9 | -0.60% |
| real/eff/VS || | 2.285e9 | +0.20% |
| real/eff/VSD || | 8.315e7 | +0.02% |
| real/eff/VSM || | 9.480e8 | +1.48% |
| real/fem || | 6.641e9 | -0.53% |
| real/fluid || | 3.914e9 | +0.00% |
| real/fulsom || | 2.497e9 | -0.22% |
| real/gamteb || | 1.013e10 | -0.01% |
| real/gg || | 7.243e9 | +0.12% |
| real/grep || | 7.563e9 | -0.10% |
| real/hidden || | 7.209e9 | +1.57% |
| real/hpg || | 4.982e9 | +0.91% |
| real/infer || | 8.312e9 | +0.11% |
| real/lift || | 4.441e9 | -0.18% |
| real/linear || | 8.438e9 | +1.90% |
| real/maillist || | 4.297e9 | -0.94% |
| real/mkhprog || | 2.874e7 | -0.06% |
| real/parser || | 5.177e9 | +0.14% |
| real/pic || | 3.265e9 | +0.10% |
| real/prolog || | 5.755e9 | -0.18% |
| real/reptile || | 6.050e9 | +0.07% |
| real/rsa || | 7.177e9 | +0.03% |
| real/scs || | 6.184e9 | -0.23% |
| real/smallpt || | 1.129e10 | -0.16% |
| real/symalg || | 8.247e9 | -0.14% |
| real/veritas || | 4.833e9 | -0.01% |
| shootout/binary-trees || | 1.071e10 | +0.12% |
| shootout/fannkuch-redux || | 1.912e10 | +0.12% |
| shootout/fasta || | 4.273e9 | -0.50% |
| shootout/k-nucleotide || | 4.227e9 | -1.34% |
| shootout/n-body || | 3.725e9 | -0.23% |
| shootout/pidigits || | 8.095e9 | -0.04% |
| shootout/reverse-complement || | 3245583.000 | -2.41% |
| shootout/spectral-norm || | 4.238e9 | -0.15% |
| smp/callback001 || | 1.601e9 | +0.55% |
| smp/callback002 || | 2.619e9 | +0.19% |
| smp/chan || | 7.817e9 | -0.01% |
| smp/sieve || | 2.361e9 | +0.85% |
| smp/threads001 || | 5.145e9 | +0.17% |
| smp/threads003 || | 2.922e9 | -0.06% |
| smp/threads006 || | 1.081e9 | +4.82% |
| smp/threads007 || | 4.328e9 | +0.63% |
| spectral/ansi || | 5.961e9 | +0.21% |
| spectral/atom || | 5.864e9 | -0.10% |
| spectral/awards || | 8.749e9 | -0.02% |
| spectral/banner || | 8.862e9 | +0.12% |
| spectral/boyer || | 7.669e9 | -0.09% |
| spectral/boyer2 || | 8.888e9 | +0.04% |
| spectral/calendar || | 7.541e9 | +0.13% |
| spectral/cichelli || | 8.675e9 | -0.17% |
| spectral/circsim || | 6.901e9 | +0.12% |
| spectral/clausify || | 6.227e9 | -0.09% |
| spectral/constraints || | 8.308e9 | +0.36% |
| spectral/cryptarithm1 || | 7.804e9 | -0.23% |
| spectral/cryptarithm2 || | 6.757e9 | +0.11% |
| spectral/cse || | 6.357e9 | +0.01% |
| spectral/dom-lt || | 7.774e9 | +0.17% |
| spectral/eliza || | 8.279e9 | -0.12% |
| spectral/exact-reals || | 5.599e9 | -0.07% |
| spectral/expert || | 5.096e9 | -0.09% |
| spectral/fft2 || | 8.818e9 | +0.48% |
| spectral/fibheaps || | 8.019e9 | -0.12% |
| spectral/fish || | 7.319e9 | -0.03% |
| spectral/gcd || | 6.381e9 | +0.26% |
| spectral/hartel/comp_lab_zift || | 8.747e9 | -0.45% |
| spectral/hartel/event || | 9.153e9 | -1.50% |
| spectral/hartel/fft || | 3.237e9 | -0.02% |
| spectral/hartel/genfft || | 1.020e10 | +0.14% |
| spectral/hartel/ida || | 5.420e9 | -0.32% |
| spectral/hartel/listcompr || | 6.143e9 | +0.12% |
| spectral/hartel/listcopy || | 6.759e9 | +0.01% |
| spectral/hartel/nucleic2 || | 4.413e9 | -0.67% |
| spectral/hartel/parstof || | 5.552e9 | +0.04% |
| spectral/hartel/sched || | 5.807e9 | -0.02% |
| spectral/hartel/solid || | 5.850e9 | +0.22% |
| spectral/hartel/transform || | 5.713e9 | -0.01% |
| spectral/hartel/typecheck || | 5.844e9 | -0.04% |
| spectral/hartel/wang || | 8.727e9 | +0.29% |
| spectral/hartel/wave4main || | 6.034e9 | -0.20% |
| spectral/integer || | 7.048e9 | +0.64% |
| spectral/knights || | 8.310e9 | -0.08% |
| spectral/lambda || | 8.091e9 | -0.12% |
| spectral/last-piece || | 1.877e9 | +0.11% |
| spectral/lcss || | 8.776e9 | -0.10% |
| spectral/life || | 9.143e9 | -0.05% |
| spectral/mandel || | 7.015e9 | +0.24% |
| spectral/mandel2 || | 3.957e9 | +0.03% |
| spectral/mate || | 7.573e9 | +0.11% |
| spectral/minimax || | 8.645e9 | +0.10% |
| spectral/multiplier || | 6.097e9 | +0.06% |
| spectral/para || | 6.562e9 | +0.03% |
| spectral/power || | 6.758e9 | -0.23% |
| spectral/pretty || | 3371581.000 | -0.75% |
| spectral/primetest || | 7.409e9 | -0.04% |
| spectral/puzzle || | 6.405e9 | -0.19% |
| spectral/rewrite || | 5.558e9 | +0.62% |
| spectral/scc || | 3244220.000 | -1.55% |
| spectral/simple || | 1.220e10 | +0.25% |
| spectral/sorting || | 9.082e9 | -0.05% |
| spectral/sphere || | 5.371e9 | -0.18% |
| spectral/treejoin || | 9.881e9 | -0.07% |
+===============================++==+=============+==================+
| geom mean || | +0.02% | |
+-------------------------------++--+-------------+------------------+
# perf cycles
+-------------------------------++--+-------------+------------------+
| || | master/ | callstack/ (rel) |
+===============================++==+=============+==================+
| imaginary/bernouilli || | 3.726e9 | +0.96% |
| imaginary/digits-of-e1 || | 2.561e9 | +3.96% |
| imaginary/digits-of-e2 || | 2.828e9 | -1.96% |
| imaginary/exp3_8 || | 3.231e9 | +2.40% |
| imaginary/gen_regexps || | 4.250e9 | +0.26% |
| imaginary/integrate || | 2.968e9 | -9.55% |
| imaginary/kahan || | 3.062e9 | -0.40% |
| imaginary/paraffins || | 3.083e9 | -1.94% |
| imaginary/primes || | 2.593e9 | +1.49% |
| imaginary/queens || | 4.713e9 | -0.75% |
| imaginary/rfib || | 3.942e9 | -0.09% |
| imaginary/tak || | 4.385e9 | -0.60% |
| imaginary/wheel-sieve1 || | 4.582e9 | -43.27% |
| imaginary/wheel-sieve2 || | 2.563e9 | -2.37% |
| imaginary/x2n1 || | 2.867e9 | +0.10% |
| parallel/blackscholes || | 4.854e9 | -1.40% |
| parallel/coins || | 4.809e9 | -0.08% |
| parallel/gray || | 3.600e9 | +2.96% |
| parallel/mandel || | 1.481e10 | -1.08% |
| parallel/matmult || | 1.570e10 | -2.83% |
| parallel/minimax || | 2.420e10 | +7.85% |
| parallel/nbody || | 4.377e8 | +1.37% |
| parallel/parfib || | 1.752e10 | +0.16% |
| parallel/partree || | 3.345e9 | +2.19% |
| parallel/prsa || | 7.052e9 | +6.03% |
| parallel/queens || | 4.686e9 | +0.06% |
| parallel/ray || | 9.246e9 | -2.73% |
| parallel/sumeuler || | 4.166e9 | -1.20% |
| parallel/transclos || | 1.095e10 | +1.05% |
| real/anna || | 5.456e9 | -0.28% |
| real/ben-raytrace || | 6.268e10 | +2.87% |
| real/bspt || | 3.695e9 | -0.12% |
| real/cacheprof || | 3.822e9 | +5.28% |
| real/compress || | 2.389e9 | -0.41% |
| real/compress2 || | 3.284e9 | -4.00% |
| real/eff/CS || | 1.825e8 | +0.07% |
| real/eff/CSD || | 1.185e9 | -0.92% |
| real/eff/FS || | 9.959e8 | +8.14% |
| real/eff/S || | 2.161e9 | +3.14% |
| real/eff/VS || | 9.353e8 | -4.17% |
| real/eff/VSD || | 2.326e7 | +3.42% |
| real/eff/VSM || | 3.006e8 | -15.15% |
| real/fem || | 3.274e9 | -5.66% |
| real/fluid || | 3.224e9 | -2.00% |
| real/fulsom || | 1.922e9 | -1.85% |
| real/gamteb || | 5.555e9 | -0.95% |
| real/gg || | 3.717e9 | +6.49% |
| real/grep || | 3.266e9 | -4.20% |
| real/hidden || | 5.666e9 | -6.63% |
| real/hpg || | 3.082e9 | +8.56% |
| real/infer || | 4.526e9 | +4.02% |
| real/lift || | 3.450e9 | -0.91% |
| real/linear || | 6.195e9 | -3.28% |
| real/maillist || | 3.815e9 | -3.44% |
| real/mkhprog || | 1.859e7 | -4.29% |
| real/parser || | 3.315e9 | +1.96% |
| real/pic || | 2.259e9 | -2.02% |
| real/prolog || | 4.197e9 | +0.39% |
| real/reptile || | 3.234e9 | -1.87% |
| real/rsa || | 2.852e9 | -1.52% |
| real/scs || | 2.870e9 | -2.91% |
| real/smallpt || | 7.328e9 | +0.78% |
| real/symalg || | 3.427e9 | +0.10% |
| real/veritas || | 2.909e9 | +0.50% |
| shootout/binary-trees || | 5.018e9 | -0.06% |
| shootout/fannkuch-redux || | 1.014e10 | -2.68% |
| shootout/fasta || | 2.439e9 | +1.45% |
| shootout/k-nucleotide || | 3.488e9 | +4.66% |
| shootout/n-body || | 2.098e9 | -0.03% |
| shootout/pidigits || | 3.265e9 | -0.18% |
| shootout/reverse-complement || | 3311908.000 | -6.15% |
| shootout/spectral-norm || | 1.525e9 | +0.62% |
| smp/callback001 || | 8.318e8 | +9.35% |
| smp/callback002 || | 1.337e9 | +5.34% |
| smp/chan || | 3.236e9 | -0.99% |
| smp/sieve || | 7.368e8 | -0.27% |
| smp/threads001 || | 2.874e9 | -0.77% |
| smp/threads003 || | 1.841e9 | -0.36% |
| smp/threads006 || | 1.144e9 | +2.09% |
| smp/threads007 || | 3.534e9 | +3.85% |
| spectral/ansi || | 1.973e9 | -2.41% |
| spectral/atom || | 2.944e9 | -0.80% |
| spectral/awards || | 5.452e9 | -11.68% |
| spectral/banner || | 4.185e9 | -0.68% |
| spectral/boyer || | 4.195e9 | -1.23% |
| spectral/boyer2 || | 4.586e9 | -1.21% |
| spectral/calendar || | 3.726e9 | -1.97% |
| spectral/cichelli || | 4.325e9 | -0.26% |
| spectral/circsim || | 5.746e9 | -0.23% |
| spectral/clausify || | 3.735e9 | +0.10% |
| spectral/constraints || | 5.202e9 | +2.10% |
| spectral/cryptarithm1 || | 3.909e9 | -4.03% |
| spectral/cryptarithm2 || | 3.759e9 | -1.27% |
| spectral/cse || | 4.564e9 | -2.83% |
| spectral/dom-lt || | 4.830e9 | -0.05% |
| spectral/eliza || | 4.631e9 | -6.18% |
| spectral/exact-reals || | 3.471e9 | -0.08% |
| spectral/expert || | 4.020e9 | -1.27% |
| spectral/fft2 || | 4.706e9 | -1.71% |
| spectral/fibheaps || | 4.492e9 | +0.55% |
| spectral/fish || | 4.004e9 | +3.76% |
| spectral/gcd || | 3.413e9 | -2.86% |
| spectral/hartel/comp_lab_zift || | 5.377e9 | +4.10% |
| spectral/hartel/event || | 5.456e9 | -1.84% |
| spectral/hartel/fft || | 1.732e9 | +0.20% |
| spectral/hartel/genfft || | 5.124e9 | +2.82% |
| spectral/hartel/ida || | 4.414e9 | +2.00% |
| spectral/hartel/listcompr || | 3.458e9 | +3.84% |
| spectral/hartel/listcopy || | 3.776e9 | -4.30% |
| spectral/hartel/nucleic2 || | 4.137e9 | +4.49% |
| spectral/hartel/parstof || | 4.609e9 | -0.54% |
| spectral/hartel/sched || | 4.245e9 | -0.19% |
| spectral/hartel/solid || | 3.587e9 | +1.04% |
| spectral/hartel/transform || | 3.793e9 | +4.13% |
| spectral/hartel/typecheck || | 4.627e9 | -1.51% |
| spectral/hartel/wang || | 4.369e9 | -1.01% |
| spectral/hartel/wave4main || | 4.844e9 | -5.68% |
| spectral/integer || | 3.150e9 | -5.21% |
| spectral/knights || | 4.198e9 | +21.03% |
| spectral/lambda || | 3.534e9 | +1.90% |
| spectral/last-piece || | 1.134e9 | +0.65% |
| spectral/lcss || | 3.905e9 | -0.64% |
| spectral/life || | 5.646e9 | -6.52% |
| spectral/mandel || | 3.529e9 | -6.31% |
| spectral/mandel2 || | 2.570e9 | -0.24% |
| spectral/mate || | 5.761e9 | +4.42% |
| spectral/minimax || | 4.569e9 | -1.24% |
| spectral/multiplier || | 3.060e9 | +6.04% |
| spectral/para || | 4.232e9 | +1.90% |
| spectral/power || | 3.808e9 | -1.38% |
| spectral/pretty || | 3403388.000 | -22.39% |
| spectral/primetest || | 3.203e9 | -4.45% |
| spectral/puzzle || | 4.362e9 | -0.34% |
| spectral/rewrite || | 3.840e9 | +4.16% |
| spectral/scc || | 3133857.000 | +1.57% |
| spectral/simple || | 7.219e9 | -1.59% |
| spectral/sorting || | 4.285e9 | -0.29% |
| spectral/sphere || | 3.674e9 | -3.88% |
| spectral/treejoin || | 4.910e9 | +0.19% |
+===============================++==+=============+==================+
| geom mean || | -0.80% | |
+-------------------------------++--+-------------+------------------+
17
28
Are you sure about this approach? I think you need to start with an open
discussion , And have a open ended thread about ideas for how to improve
how we do things.
A proposals process / formal process isn’t always a win. This sortah
approach demands a lot more dedicated human power and support admin than I
think is tenable for the libraries ecosystem today.
Merry Friday and be well
-Carter
---------- Forwarded message ---------
From: chessai <chessai1996(a)gmail.com>
Date: Fri, Sep 11, 2020 at 10:02 PM
Subject: Re: New Libraries Proposal process
To: Carter Schonwald <carter.schonwald(a)gmail.com>
This has been discussed on and off for a few months now, amongst CLC,
between members of CLC and GHC Steering/Haskell.org, Tweag, Target, IOHK,
Serokell, etc. My only regret is that a lot of the conversation happened
privately.
> All libraries process needs to start on the libraries mailing list
Not anymore.
The libraries mailing list has proven to be ineffective when it comes to
getting stuff done. Mailing lists are not the right format for this.
Furthermore, I don't see how emails are more conducive to deep discussion
than github comments. There are many GitHub issue trackers and PRs which
show otherwise.
This new process will never be perfect and of course will need some
tweaking, but the current process is very poor and gets little done. Most
proposals I ever see end up with no resolution.
Since the GHC Proposals process has proven to be a net positive, much of
the structure was taken from there and adapted to core libraries.
On Fri, Sep 11, 2020, 19:52 Carter Schonwald <carter.schonwald(a)gmail.com>
wrote:
> Where was this discussed or proposed? All libraries process needs to start
> on the libraries mailing list. And soemtimes Perhaps moving to clc list for
> resolving tie breaking on controversial choices.
>
> The libraries archive goes back pretty far and email threading seems to
> scale far better for participating in complex discussions than does githubs
> comment collapsing on large discussions.
>
> On Fri, Sep 11, 2020 at 3:20 PM chessai <chessai1996(a)gmail.com> wrote:
>
>> All,
>>
>>
>> There is a new Libraries Proposal process, inspired by the GHC Proposals
>> process.
>>
>> Core Library APIs are critical. It's easy for a sensible proposal to
>> languish or simply get dropped on the floor; and (in the other direction) a
>> bit too easy for a proposal to make it into the core libraries without
>> receiving the scrutiny it deserves. Most of the proposals that have been
>> made on this mailing list, become lost to the archives. It's not easy for
>> anyone to answer the question "what decisions has the CLC made recently?"
>> without trawling a huge email archive.
>>
>> Of course, this is mostly for breaking changes or "big" introductions; we
>> don't need a full proposal over something tiny, e.g. "a module from vector
>> is missing a fold". That would be more appropriate on vector's issue
>> tracker, and left to the maintainers to deal with.
>>
>> I encourage anyone interested to get started by reading the README at
>> https://github.com/haskell-core/core-libraries-proposals.
>>
>>
>>
>> _______________________________________________
>>
>> Libraries mailing list
>>
>> Libraries(a)haskell.org
>>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
>
>
10
13
All,
There is a new Libraries Proposal process, inspired by the GHC Proposals
process.
Core Library APIs are critical. It's easy for a sensible proposal to
languish or simply get dropped on the floor; and (in the other direction) a
bit too easy for a proposal to make it into the core libraries without
receiving the scrutiny it deserves. Most of the proposals that have been
made on this mailing list, become lost to the archives. It's not easy for
anyone to answer the question "what decisions has the CLC made recently?"
without trawling a huge email archive.
Of course, this is mostly for breaking changes or "big" introductions; we
don't need a full proposal over something tiny, e.g. "a module from vector
is missing a fold". That would be more appropriate on vector's issue
tracker, and left to the maintainers to deal with.
I encourage anyone interested to get started by reading the README at
https://github.com/haskell-core/core-libraries-proposals.
5
7
Hello.
I notice that in `"base" Data.Foldable` there are strict left and
right folds, but no corresponding folds without base case, that is,
`foldl1'` and `foldr1'`. Can this omission be ameliorated? The
implementation is trivial.
5
8
29 Jun '21
I know applications for `intercalate :: Text -> [Text] -> Text`: `unwords`, `unlines`, etc. But what is `intersperse :: Char -> Text -> Text` good for? Am I correct assuming that its sole merit is to mimic `Data.List` API? Note that `Data.List.intersperse` is polymorphic and is exceedingly rarely used for `Char -> String -> String`.
Best regards,
Andrew
6
6
27 Jun '21
>>> `intersperse :: Char -> Text -> Text`
>>
>> Yeah, that looks silly indeed. Should be pruned or marked as spam.
>>
>
> "Spam" is a bit harsh. And it does indeed have some use (albeit primarily
> with test suites and quite possibly more efficient ways to do the required
> task anyway):
> https://github.com/search?l=Haskell&q=Text.intersperse&type=Code
To be honest, I cannot find a single useful application of `intersperse` there, and most of results are not about `Data.Text.intersperse` at all.
Best regards,
Andrew
1
0
18 Jun '21
-1 for the reasons Henrik has listed
Dominic Steinitz
dominic(a)steinitz.org
http://idontgetoutmuch.org
Twitter: @idontgetoutmuch
> On 5 Jun 2021, at 11:10, libraries-request(a)haskell.org wrote:
>
> Re: RFC: Add HasCallStack constraint to partial Data.List
> functions.
12
18
14 Jun '21
There has been little response to the issues and PRs lately[0] so I request
for an additional maintainership. I'm willing to do it unless anyone else
steps forward.
Apparently @ali-abrar is the current maintainer so I CC'd him.
[0] https://github.com/bgamari/monoidal-containers
2
3
11 Jun '21
As far as I'm concerned, nonreflexive instances are not supported by
`containers` at all. If your == isn't reflexive, you just need to assume
that anything with an Eq constraint might behave arbitrarily badly.
On Fri, Jun 11, 2021, 10:27 AM Simon Jakobi via Haskell-Cafe <
haskell-cafe(a)haskell.org> wrote:
> Thanks for the feedback everyone! :)
>
> The gist I get is that using pointer equality is not free, but it can
> make sense when
>
> 1. two objects are particularly likely to be the same;
> 2. establishing equality by other means (e.g. structural equality) is
> particularly expensive
>
> The usecases I now have in mind are:
>
> * Lookups in unordered-containers: Since keys are only ==-d when their
> hashes are equal, it seems that the likelihood that they are in fact
> the same object should be fairly good. I think we can ignore the issue
> of irreflexive instances here, because the lookup logic already
> requires reflexivity.
>
> * The Eq instances of containers' Set and IntSet types and of HashSet
> from unordered-containers. These instances seem particularly
> expensive, and Set and HashSet already require reflexivity. I don't
> think we can apply the same optimizations to the Eq instances of the
> various Map types, because we might run into irreflexive values there.
>
> * Eq for lazy ByteStrings – another expensive instance. The instance
> for strict ByteStrings already makes use of pointer equality.
>
> Cheers,
> Simon
>
>
>
>
>
>
>
>
> Am Di., 8. Juni 2021 um 18:51 Uhr schrieb Sebastiaan Joosten
> <sjcjoosten+haskell(a)gmail.com>:
> >
> > The containers library uses this trick:
> >
> https://github.com/haskell/containers/blob/30ccbaa201043109bf1ee905c66ccd0d…
> > It mentions the useful hint to evaluate the arguments to WHNF before
> calling PtrEquality.
> > The function ptrEq is used here (for instance):
> >
> https://github.com/haskell/containers/blob/30ccbaa201043109bf1ee905c66ccd0d…
> > The places where ptrEq is used in that file, its purpose seems to be to
> reduce memory by reusing existing data-structures, which I suppose also
> helps with performance.
> > Surprisingly enough (at least to me) ptrEq is not used in the Eq
> instance there:
> >
> https://github.com/haskell/containers/blob/30ccbaa201043109bf1ee905c66ccd0d…
> >
> > Outside of GHC, there are some (pure) languages that extensively make
> use of this principle and it's too cool not to mention:
> > The programming language Elm does this in its generated code (at least
> when generating JavaScript): https://github.com/elm/compiler/
> > The theorem proving environment ACL2 uses this principle for memoizing
> functions, fast 'Map's ('dictionaries' in python lingo, 'alist' or
> association-list in ACL2 lingo), as well as fast equality. As a LISP
> dialect, all data-structures are pairs (called CONS). In ACL2, the function
> 'HONS' (hashed CONS) will construct a pair if it does not already exist,
> and otherwise it returns a pointer to the already existing object. The
> point of using HONS in ACL2 is to only perform pointer comparison, without
> needing to do any other equality check.
> > General background information:
> https://www.cs.utexas.edu/~ragerdl/acl2-manual/index.html?topic=ACL2____HON…
> > The equality test:
> https://www.cs.utexas.edu/users/moore/acl2/manuals/current/manual/index-seo…
> > And there is of course a function to create a 'normed object':
> https://www.cs.utexas.edu/users/moore/acl2/manuals/current/manual/index-seo…
> > Note that the ACL2 approach only works because it is supported by the
> run time system (the implementation needs to access 'all data in memory')
> so it won't work in Haskell (assuming you're not writing your own RTS).
> >
> > Hope this helps.
> >
> > On Tue, Jun 8, 2021 at 10:47 AM Joachim Durchholz <jo(a)durchholz.org>
> wrote:
> >>
> >> Am 08.06.21 um 16:25 schrieb Simon Jakobi via Haskell-Cafe:
> >> > Hi everyone!
> >> >
> >> > In
> https://github.com/haskell-unordered-containers/unordered-containers/issues…
> >> > we're wondering whether certain Eq instances, for example record types
> >> > or strings, could be optimized by including a pointer equality check
> >> > that detects when an object is compared with itself.
> >>
> >> You have to be aware that the pointer comparison itself does not come
> >> for free. Execution prediction means that the "happy path" may be so
> >> rare it's not loaded into the CPU cache and you might end with a slower
> >> system - the case is somewhat pathological but not so rare that you can
> >> just assume that it will not happen to you.
> >> A lot also depends on whether the data to be compared needs to be loaded
> >> anyway. If yes, the pointer comparison won't give you any gains, it will
> >> be just one instruction more to execute, creating more execution unit
> >> contention inside the CPU. If no, then obviously the pointer comparison
> >> will help.
> >>
> >> In the end, you need to benchmark to see if it helps you.
> >> And you cannot usefully benchmark unless you have also nailed down all
> >> performance-relevant compiler and runtime options, which you do only if
> >> you have exhausted all other optimization possibilities.
> >>
> >> IOW if it complicates your code, don't do it - unless you are already
> >> long past the point where code reusability has taken a back seat to raw
> >> optimization.
> >>
> >> Regards,
> >> Jo
> >> _______________________________________________
> >> Haskell-Cafe mailing list
> >> To (un)subscribe, modify options or view archives go to:
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >> Only members subscribed via the mailman list are allowed to post.
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
2
1
11 Jun '21
(CC'ing the libraries list again)
Am Fr., 11. Juni 2021 um 16:26 Uhr schrieb Simon Jakobi
<simon.jakobi(a)googlemail.com>:
>
> Thanks for the feedback everyone! :)
>
> The gist I get is that using pointer equality is not free, but it can
> make sense when
>
> 1. two objects are particularly likely to be the same;
> 2. establishing equality by other means (e.g. structural equality) is
> particularly expensive
>
> The usecases I now have in mind are:
>
> * Lookups in unordered-containers: Since keys are only ==-d when their
> hashes are equal, it seems that the likelihood that they are in fact
> the same object should be fairly good. I think we can ignore the issue
> of irreflexive instances here, because the lookup logic already
> requires reflexivity.
>
> * The Eq instances of containers' Set and IntSet types and of HashSet
> from unordered-containers. These instances seem particularly
> expensive, and Set and HashSet already require reflexivity. I don't
> think we can apply the same optimizations to the Eq instances of the
> various Map types, because we might run into irreflexive values there.
>
> * Eq for lazy ByteStrings – another expensive instance. The instance
> for strict ByteStrings already makes use of pointer equality.
>
> Cheers,
> Simon
>
>
>
>
>
>
>
>
> Am Di., 8. Juni 2021 um 18:51 Uhr schrieb Sebastiaan Joosten
> <sjcjoosten+haskell(a)gmail.com>:
> >
> > The containers library uses this trick:
> > https://github.com/haskell/containers/blob/30ccbaa201043109bf1ee905c66ccd0d…
> > It mentions the useful hint to evaluate the arguments to WHNF before calling PtrEquality.
> > The function ptrEq is used here (for instance):
> > https://github.com/haskell/containers/blob/30ccbaa201043109bf1ee905c66ccd0d…
> > The places where ptrEq is used in that file, its purpose seems to be to reduce memory by reusing existing data-structures, which I suppose also helps with performance.
> > Surprisingly enough (at least to me) ptrEq is not used in the Eq instance there:
> > https://github.com/haskell/containers/blob/30ccbaa201043109bf1ee905c66ccd0d…
> >
> > Outside of GHC, there are some (pure) languages that extensively make use of this principle and it's too cool not to mention:
> > The programming language Elm does this in its generated code (at least when generating JavaScript): https://github.com/elm/compiler/
> > The theorem proving environment ACL2 uses this principle for memoizing functions, fast 'Map's ('dictionaries' in python lingo, 'alist' or association-list in ACL2 lingo), as well as fast equality. As a LISP dialect, all data-structures are pairs (called CONS). In ACL2, the function 'HONS' (hashed CONS) will construct a pair if it does not already exist, and otherwise it returns a pointer to the already existing object. The point of using HONS in ACL2 is to only perform pointer comparison, without needing to do any other equality check.
> > General background information: https://www.cs.utexas.edu/~ragerdl/acl2-manual/index.html?topic=ACL2____HON…
> > The equality test: https://www.cs.utexas.edu/users/moore/acl2/manuals/current/manual/index-seo…
> > And there is of course a function to create a 'normed object': https://www.cs.utexas.edu/users/moore/acl2/manuals/current/manual/index-seo…
> > Note that the ACL2 approach only works because it is supported by the run time system (the implementation needs to access 'all data in memory') so it won't work in Haskell (assuming you're not writing your own RTS).
> >
> > Hope this helps.
> >
> > On Tue, Jun 8, 2021 at 10:47 AM Joachim Durchholz <jo(a)durchholz.org> wrote:
> >>
> >> Am 08.06.21 um 16:25 schrieb Simon Jakobi via Haskell-Cafe:
> >> > Hi everyone!
> >> >
> >> > In https://github.com/haskell-unordered-containers/unordered-containers/issues…
> >> > we're wondering whether certain Eq instances, for example record types
> >> > or strings, could be optimized by including a pointer equality check
> >> > that detects when an object is compared with itself.
> >>
> >> You have to be aware that the pointer comparison itself does not come
> >> for free. Execution prediction means that the "happy path" may be so
> >> rare it's not loaded into the CPU cache and you might end with a slower
> >> system - the case is somewhat pathological but not so rare that you can
> >> just assume that it will not happen to you.
> >> A lot also depends on whether the data to be compared needs to be loaded
> >> anyway. If yes, the pointer comparison won't give you any gains, it will
> >> be just one instruction more to execute, creating more execution unit
> >> contention inside the CPU. If no, then obviously the pointer comparison
> >> will help.
> >>
> >> In the end, you need to benchmark to see if it helps you.
> >> And you cannot usefully benchmark unless you have also nailed down all
> >> performance-relevant compiler and runtime options, which you do only if
> >> you have exhausted all other optimization possibilities.
> >>
> >> IOW if it complicates your code, don't do it - unless you are already
> >> long past the point where code reusability has taken a back seat to raw
> >> optimization.
> >>
> >> Regards,
> >> Jo
> >> _______________________________________________
> >> Haskell-Cafe mailing list
> >> To (un)subscribe, modify options or view archives go to:
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >> Only members subscribed via the mailman list are allowed to post.
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
1
0