Regression moving to ghc7
I'm trying to write a rolling window variation of the adler32 hash function (here: https://gist.github.com/1011151), and I got it to a nearly acceptable speed under ghc 6.12.3 (~35MB/s on my work machine), so I thought I'd see how the new ghc 7.0.3 treated it. The answer is "not good". I get about 270KB/s. The key difference that I'm seeing from looking at the ghc-core program is that ghc 7.0.3 isn't using primitive ops for anything (unless they are no longer annotated with "#"). Can anybody shed any light as to what's going on? I'd also welcome any optimization tips that people would like to share. I've been messing with the code so much over the past day or two that I'm not even sure if it computes an adler32 anymore, but I hope that any optimization tops that pertain to that code would also apply to a correct algorithm. Right now, I'd just like to have the code run quickly, and to figure out why I'm seeing such a terrible regression under ghc7.
Right now, I'd just like to have the code run quickly, and to figure out why I'm seeing such a terrible regression under ghc7.
From the #haskell channel, it looks like the horrible speed issue on this code is specific to my system. I'm re-building ghc7 now (bootstrapping ghc7 with ghc7 instead of ghc6), so maybe that will make something happier. If it doesn't, how does one go about figuring out why a program isn't being compiled to use primitive operations? just running ghc -v5 gives me so much information that I can't make any sense of it. Is there a less shotgun-like approach to seeing where the compiler is getting confused?
From the #haskell channel, it looks like the horrible speed issue on this code is specific to my system. I'm re-building ghc7 now (bootstrapping ghc7 with ghc7 instead of ghc6), so maybe that will make something happier.
FWIW, rebuilding ghc7 using ghc7 as the bootstrapping implementation (and disabling the ghcquickbuild option, whatever that does) did give me a sane ghc7 that is giving the expected speeds. So, if anybody feels like pointing fingers at anything I could be doing better in my program, that's definitely welcome, but the regression part of my problem is gone.
On 7 June 2011 10:12, tsuraan
From the #haskell channel, it looks like the horrible speed issue on this code is specific to my system. I'm re-building ghc7 now (bootstrapping ghc7 with ghc7 instead of ghc6), so maybe that will make something happier.
FWIW, rebuilding ghc7 using ghc7 as the bootstrapping implementation (and disabling the ghcquickbuild option, whatever that does) did give me a sane ghc7 that is giving the expected speeds. So, if anybody feels like pointing fingers at anything I could be doing better in my program, that's definitely welcome, but the regression part of my problem is gone.
Oh, you built with ghcquickbuild? I don't remember the details, but if memory serves it disables a lot of optimisations, etc. just to get GHC built quicker to test that it compiles. So you probably don't want that ;-) -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
Oh, you built with ghcquickbuild? I don't remember the details, but if memory serves it disables a lot of optimisations, etc. just to get GHC built quicker to test that it compiles. So you probably don't want that ;-)
That's good to know. It's too bad there doesn't seem to be a warning in the "-v" output that says all optimization is disabled or something, but now I know :)
participants (2)
-
Ivan Lazar Miljenovic -
tsuraan