Sam | > How to progress? Rather than try to follow the detailed path of your | > investigation, I wonder if you might do the following. When you achieve | > a stable situation where you think you have a collection of | > modifications that improve at least some programs, without making any | > significantly worse (you can negotiate about exceptions) send a patch or | > patches (to GHC and the libraries) that implements your proposal, along | > with a summary of what they do (unless that's all clear from the patch | > messages themselves). Preferably without patches that do X and later | > undo X... | > | > That way Simon and Ian and I can review and test one thing. Does that | > make sense? | | Yeah. I've been under the impression that that was going to have to | happen before my patches were applied, I've basically just been hoping | for tips. Or "oh god no, don't do that! do this instead!" or | something.
I can't promise that myself, but I'm happy to help where you have specific qns about the existing code. Meanwhile, I'm not sure it's clear to everyone else that you are looking for feedback. You could try emailing cvs-ghc, pointing to your current set of patches (better than enclosing them all), explaining what you are trying to do, and asking if anyone else is interested in optimising and would like to work with you. (You could start a GHC developer Wiki page to hold your current thoughts and patches, so you don't need to keep repeating yourself. That's also a useful permanent record.) Whether anyone will respond I don't know. But it's worth asking explicitly rather than implicitly. | I've been working with a definition of "significant" where | 1% slower doesn't count, but 5% does. And I've been assuming that a 1% | all-around increase in code size isn't too bad. Seems fair enough -- if there is a real perf boost for at least one class of programs. Simon M may want to chip in. | And lately (since the | patch that doesn't consider unlifted args interesting unless they are | literals), I haven't seen *any* changes in allocation from my | unpatched tree. Hopefully with my patch to build the libraries with | -fext-core I will actually be able to figure out what is going on in | the libraries (which seems to be where a lot of the differences that | matter are). I assume there aren't really any performance | considerations there ;-). Indeed, which is why I asked Ian to commit that patch. happy hacking Simon _______________________________________________ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc
