Thanks for doing this. Running nofib is a great sanity check. I've spent a lot of time thinking "why does my cool improvement make some of these nofib programs get worse". It's surprisingly hard to make optimisations that always win! (Of course, some losses may be acceptable, if they aren't big, and trade for good wins elsewhere.)
Adding more nofib programs is also a good thing to do. Maybe your shifting program would make a good "imaginary" or "spectral" one. (You'll see there are three subdirectories for different classes of programs.) We'll look again at those profiling bugs -- but meanwhile there's a difficulty lurking: profiling will change what the optimiser does, which may conceal exactly what you are looking for. Instead we usually use valgrind to profile execuction at a lower level http://valgrind.org. Something like this valgrind --tool=cachegrind <prog> <args> [ creates a file like cachegrind.out.23915] cg_annotate --23915 [ use the correct number, of course ] Alexey Rodriguez is working on low-level perf measurement at the moment, so I'm ccing him. Simon PS: I pushed your nofib-analyse patches, thank you | -----Original Message----- | From: Samuel Bronson [mailto:[EMAIL PROTECTED] | Sent: 14 October 2006 19:34 | To: Simon Peyton-Jones | Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] | Subject: Re: darcs patch: Teach the inliner about primitive compar... (and 2more) | | On 10/13/06, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote: | | > Our mechanism for figuring this out is to | > - check out the nofib suite (darcs.haskell.org/nofib) | > - run the suite before and after the patch (cd nofib; make | > clean; make -k >& log) | > - run the nofib-analyse script to compare the two logs | > The third step produces a table showing whether runtimes and allocations | > went down or up. | > | > Could you do this and let us know how it goes? | | Okay... after unpulling your GADT patch... and getting stage2 to build | (it had a type error in GHCI-only type family-related code)... and | faking dos2unix... and getting nofib-analyse to at least *build* with | GHC 6.4 (but it won't build with 6.6 because Data.FiniteMap is | missing!)... and getting the numbers not to be so long and run | together... I've got some results. | | Now, a lot of the programs didn't run correctly (I think they were all | already broken, though), most of them were 1% larger, and a few | allocated and/or performed significantly worse... I think... but I'm | not too good at interpreting the results. Check the moderation queue | for patches to nofib-analyse, in case I messed it up. If you want the | logs, I'll be happy to send them to you, but I'd rather not hit the | list message size limit on this one ;-). _______________________________________________ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc
