On Wed, Oct 29, 2008 at 10:30:12AM -0700, Jason Dagit wrote: > On Wed, Oct 29, 2008 at 7:52 AM, David Roundy <[EMAIL PROTECTED]> 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.
Was he aware that the bytestring code started out significantly slower than the OldFastPackedstring code? Or did he run any timings? I suspect there are significant regressions from the OldFastPackedstring code mixed with major improvements elsewhere. I'd rather not add these significant regressions to the repository, but since the first thing he did was to remove the older, faster code, it's very hard to track them down. It's very frustrating... Don, is there any chance that you'd be willing to go back and track down why the bytestring code in unstable is so much slower than the non-bytestring code? Or maybe this is fixed in some bytestring package that is more recent than the one that ships with ghc 6.8.2 (which is 0.9.0.1, btw)? David _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
