[darcs-users] darcs patch: add exception to haskell_policy.sh for D... (and 61 more)

[Don Stewart]

dagit:
> On Wed, Oct 29, 2008 at 7:52 AM, David Roundy <droundy at darcs.net> wrote:
> > On Wed, Oct 29, 2008 at 01:00:08PM +0000, Eric Kow wrote:
> >> As I mentioned earlier, this is the promised Salvo 8 (the big one),
> >> which I have verified to pass tests on both GHC 6.6 and 6.8.
> >>
> >> If it helps, here is my contribution to the review.
> >>
> >> I think once we get over this hump, the merging the rest of sprint
> >> patches in (or not) is easy
> >>
> >> Also, if there are any changes to be made, I think we should make them
> >> *on top* of this bundle because amend-recording is simply not going to
> >> be practical (I don't meant to belabour the point, it's just that
> >> amending is a bit ingrained in our culture, so people get a bit nervous
> >> when there is a large amount of work that wants to get in)
> >
> > I don't think I'll have time to review this bundle today, but had a
> > question I'd like to ask even before I review it.  I presume this has
> > been benchmarked against the pre-salvo-8 version.  How does it affect
> > timings? Not that timings are everything, but it'd be nice to see if
> > it speeds things up or (although it seems unlikely) slows things
> > down, and if so, by how much.
> 
> I want to see benchmarks too, but I thought I would justify why we
> expect this to be no slower than the previous code...Everything below
> is stuff that we discussed during the Sprint.
> 
> For every thing that Don rewrote (like removing the C code) he checked
> that the code generated by GHC after the change was at least as good
> as the code generated before it.  He said it looked like the generated
> code was either same or better in each case.
> 
> I recall him commenting on at least one case where some indirection
> had been removed which could speed it up if the function gets called
> often.  Don also moved around some of the pack/unpack calls to either
> remove them totally or call them less often.  This should be an
> improvement because there will be less copying and less garbage.
> 
> Finally, the last thing he did was to use more of the ByteString api
> which should also be a win because he and others have worked hard to
> make everything in ByteString faster than it was in FastPackedStrings.
> 
> Hopefully someone will make those benchmarks.  That would be cool to
> quantify the improvement.  It would make a good marketing blog post :)

Yes, I'd like to see benchmarks. I expect we removed some constant
factors.

-- Don