List function pragma discipline
mail at joachim-breitner.de
Mon Sep 7 09:08:15 UTC 2015
I was working on
https://ghc.haskell.org/trac/ghc/ticket/10788 (performance regressions
involving minimum), and I found it quite unsatisfactory to twiddle with
individual functions, based on individual test cases, this way. Of
course I can improve things for a combination of functions and
testcase, but if so, shouldn’t I be improving others as well? What
about other test cases – will they regress? How should I balance the
goals of speed, code size and simplicity?
This feels more like a random walk rather than hill-climbing, let alone
a disciplined approach to the problem.
Can we have a disciplined approach? I.e. a set of guidelines that work
well in general, can be documented and communicated to the user, and
that we can follow in such cases?
Here is a rough draft, more to show what I am aiming for, rather than a
* Functions that can take part in list fusion have RULES to rewrite
them in terms of foldr/build, but also RULES to write them back.
Phase control ensures that this is done by phase 0, and the
following applies to phase 0.
* Recursive non-polymorphic non-higher-order functions are not
marked as INLINE (and thus not inlineable, beside possibly the
wrapper of a worker-wrapper split).
* Recursive polymorphic non-higher-order functions are marked as
INLINEABLE, and SPECIALIZE pragmas are given for common cases.
(Example: minimum, maximum).
* Recursive higher-order functions are implemented with a local
recursive function, to allow for inlining (foldl, foldr,
maximumBy), at least if there is a chance of further optimizations
due to strictness analysis.
Given such a guideline, I would then know what to do with such a
ticket, instead of stabbing in the dark. It might mean that we would
have to tell a user who observes suboptimal performance in one case
that this is unavoidable (we cannot optimize for everyone) and possibly
explain how to work around the issue. Or we might find that the
discipline could be improved, but then the improvement should be
applied to all functions.
Joachim “nomeata” Breitner
mail at joachim-breitner.de • http://www.joachim-breitner.de/
Jabber: nomeata at joachim-breitner.de • GPG-Key: 0xF0FBF51F
Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: This is a digitally signed message part
More information about the Libraries