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

[Jason 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 :)

Thanks,
Jason