List function pragma discipline

[Simon Peyton Jones]

|  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?

I'm all for such a thing.  A wiki page would be good.  Every item in your list needs at least one example so we can understand what you are saying.

Simon

|  -----Original Message-----
|  From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of
|  Joachim Breitner
|  Sent: 07 September 2015 10:08
|  To: Haskell Libraries
|  Subject: List function pragma discipline
|  
|  Dear list,
|  
|  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 finished work:
|  
|   * 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.
|  
|  Thoughts?
|  Joachim
|  
|  
|  --
|  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