Would it be a good or bad idea to make dropWhile try to fuse?

[Carter Schonwald]

Why not do both? :-) criterion is a very powerful tool for these micro
benchmark workloads.

On Saturday, July 26, 2014, David Feuer <david.feuer at gmail.com> wrote:

> I am not convinced that Criterion is the appropriate tool for most of
> this work. I believe we need to look primarily at allocation numbers
> when looking at these in isolation, and only look at benchmarks
> comparing the performance of realistic programs using them. The
> trouble is that allocation and nursery GC are both very fast (normally
> that's a good thing), so I believe the primary benefit we hope to get
> from fusion is better L1 cache utilization. We will only see that in
> benchmarks when enough other computation is going on in the vicinity
> of the list pipeline. It may be possible to write benchmarks to
> investigate that, but I certainly don't know how. That said, I do
> believe your idea of some sort of automated/semi-automated test suite
> is a good one. I will try to learn a bit more about GHC profiling and
> see if I can come up with at least a first draft of a rough test
> suite.
>
> On Sat, Jul 26, 2014 at 7:16 AM, Joachim Breitner
> <mail at joachim-breitner.de <javascript:;>> wrote:
> > Hi David,
> >
> >
> > Am Freitag, den 25.07.2014, 17:32 -0400 schrieb David Feuer:
> >> I think I'm going to leave that one alone for now and focus on the
> >> ones that are more obviously good ideas: scanr, takeWhile, and (now
> >> that we have appropriate optimizations) scanl and (hopefully, if no
> >> one objects) scanl', as well as the semi-related inits. I'd also like
> >> to revisit length, which is currently a horrible mess of rules, and
> >> see if the new foldl' allows it to be written efficiently without so
> >> much trouble.
> >
> > thanks for that, by the way. I guess people generally expect more
> > functions to be fusable than they are at the moment.
> >
> > I would suggest to attack the problem more systemematically. Can you
> > create a comprehensive benchmark for list functions? Something along the
> > lines of
> >  * for every list function, create one or a few micro benchmarks.
> >  * put them into one suite, using criterion to measure them. Make it
> >    possible to easily test different implementations (e.g.
> >    have lists `lengthImpls = [("Foo", Foo.length), ... ]` so that
> >    testing another implementations amounts to writing Foo.hs and
> >    importing that.
> >  * additionally, put them into one benchmark not using criterion (but
> >    rather executing all of them on a reasonable size setting) so that
> >    we can add it to nofib.
> >  * the, based on that, we can make founded decisions.
> >
> > The point of the nofib benchmark is to make sure we don’t regress when
> > we change something in the compiler or the libraries. It will notify us
> > that something went amiss, and then we can use the criterion-based
> > testsuite to figure out what exactly broke.
> >
> >
> > It would also be a benchmark for other fusion techniques to be measured
> > against. If it turns out to be useful and if you are in academics you
> > can probably talk about the benchmark suite at some workshop and get
> > citations from every following list-fusion paper ;-)
> >
> >
> > The microbenchmarks should test both fusable and unfusable uses of the
> > functions. You can easily turn one into the other using
> >         don'tFuse = id
> >         {-# NOINLINE don'tFuse #-}
> > somewhere in the pipeline. For functions that both consume and produce,
> > we’d want to test all four combinations.
> >
> > Finally, we need to put an eye on binary sizes: If fusion does not
> > happen we want to use a compiled version of the function, and not
> > re-create it in every use site. nofib tracks module sizes, so if the
> > nofib version of your benchmark is split into modules in a sensible way,
> > these module size reports will be worth watching.
> >
> >
> > Is that something you would like to work on, and take the lead? If you
> > put your code in a git repo somewhere I’ll review and contribute, of
> > course.
> >
> > Greetings,
> > Joachim
> >
> >
> >
> > --
> > Joachim “nomeata” Breitner
> >   mail at joachim-breitner.de <javascript:;> •
> http://www.joachim-breitner.de/
> >   Jabber: nomeata at joachim-breitner.de <javascript:;>  • GPG-Key:
> 0xF0FBF51F
> >   Debian Developer: nomeata at debian.org <javascript:;>
> >
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org <javascript:;>
> > http://www.haskell.org/mailman/listinfo/libraries
> >
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org <javascript:;>
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140726/8bca6b83/attachment.html>