On Sun, Jul 11, 2010 at 12:59 AM, Dan Doel wrote:

You're using GHC 6.12.x presumably?

That's right.

There are known performance problems with using abstract PrimMonads in that version (and, actually, just using IO as well).

Ah, that's a shame. I'm surprised it would be affecting IO too!

In the IO case for instance, checking the core tends to reveal lots of casting

between RealWorld and PrimState IO, despite the fact that those should be

identical.

I'd certainly noticed that the Core for the PrimMonad code was huge and almost impossible to follow for the enormous amount of casting that was taking place. The good news is that, last I checked, this isn't a problem in HEAD. The

optimizer does better there somehow. The bad news is that 6.14 isn't out yet, so you probably have to wait for a real fix.

I might revert both mwc-random and statistics back to using plain ST for now, then, as having them run slightly faster than 1% of their former speed is a bit painful :-(

| The head has -dsuppress-coercions which omits coercion terms when pretty | printing Core. It would be easy to backport that to 6.12. The HEAD also has a coercion optimiser that dramatically shrinks some large coercion terms. | > I might revert both mwc-random and statistics back to using plain ST for | now, then, as having them run slightly faster than 1% of their former speed | is a bit painful :-( | | I fear that's the only sensible solution. I wouldn't throw away your current | code, though, as 6.14 won't have these problems (hopefully). Yes, I hope that's possible because I really really don't want to have to dig into 6.12's inliner. Partly we'd then need to make yet another release, and partly it's just delicate -- that's why I redid it for 6.14. It's very helpful to have the test, though, so I can ensure 6.14 stays good. Thanks for that Simon

On Sunday 11 July 2010 1:31:23 pm Simon Peyton-Jones wrote:

This is the first I've heard of this. Do you have a test case that shows up the problem? Then we can put it in the regression tests so it won't go wrong again.

That depends on what dependencies you're willing to accept. I think all the mutable algorithms in vector-algorithms are affected (I first discovered the problem after porting my benchmarks), so if you don't mind depending on vector and vector-algorithms, it shouldn't be hard to write one. If something stand-alone is required, I (at least) don't have anything prepared at the moment. -- Dan

On Mon, Jul 12, 2010 at 9:12 AM, Simon Peyton-Jones wrote:

Well, fewer dependencies make it much easier to test and reproduce. But something concrete is certainly better than nothing. Please submit a Trac ticket. (Worth checking with Roman -- perhaps he already has?)

I can probably cook up a smaller repro than Dan, since I depend on neither package for a standalone test case. Let me get cracking on it promptly, and I'll file a ticket later.

Thank you! I am utterly buried just now (POPL) but will get to this. Simon From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Bryan O'Sullivan Sent: 12 July 2010 13:58 To: Simon Peyton-Jones Cc: glasgow-haskell-users@haskell.org Subject: Re: Massive slowdown in mwc-random after switching to use of primitive package On Mon, Jul 12, 2010 at 10:40 AM, Bryan O'Sullivan mailto:bos@serpentine.com> wrote: I can probably cook up a smaller repro than Dan, since I depend on neither package for a standalone test case. Let me get cracking on it promptly, and I'll file a ticket later. I filed http://hackage.haskell.org/trac/ghc/ticket/4184 just now, which includes two workarounds that I found for my particular version of the problem, the second of which I stumbled upon quite by accident while creating the standalone repro.