- Glasgow-haskell-users

Massive slowdown in mwc-random after switching to use of primitive package
by Bryan O'Sullivan 13 Jul '10

13 Jul '10

Hi, Roman — Recently, I switched the mwc-random package ( http://hackage.haskell.org/package/mwc-random) over from running in the ST monad to using your primitive package. I didn't notice initially, but this caused a huge performance regression. mwc-random 0.4.1.1 uses ST internally, and runs the benchmarks/Quickie benchmark in 0.017 seconds. mwc-random 0.5.1.3 uses PrimMonad internally, and takes 1.328 seconds to run the same benchmark. That's about a factor of 80 slowdown. This causes a massive knock-on performance loss in packages such as criterion that need fast PRNGs. The problem is very easy to reproduce: cabal install mwc-random-0.4.1.1 cabal install mwc-random-0.5.1.3 darcs get http://darcs.serpentine.com/mwc-random/ cd mwc-random/benchmarks ghc -fforce-recomp -O -package mwc-random-0.4.1.1 --make Quickie -o quickie-411 ghc -fforce-recomp -O -package mwc-random-0.5.1.3 --make Quickie -o quickie-513 time ./quickie-411 time ./quickie-513 If you could shed any light, I'd be most grateful, as this has me a bit confounded.

4 11

Re: unsafeCoerce# between integral and floating point types
by John Meacham 10 Jul '10

10 Jul '10

On Fri, Jul 09, 2010 at 07:14:58AM -1000, Lennart Augustsson wrote: > That might not work if the alignment constraints differ between the two types. Easy enough to fix, just compare the alignments and alloca with the greater of the two. the optimizer should be able to optimize out the test. of course, this bug[1] makes it sort of moot in ghc at least. [1] http://hackage.haskell.org/trac/ghc/ticket/r2917 John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

1 0

Lazy IO and asynchronous callbacks?
by J. Garrett Morris 09 Jul '10

09 Jul '10

Hello everyone, I'm currently in the process of wrapping a C API, and I've run across an interesting possibility. Basically, the C API exposes non-blocking versions of some potentially long-running operations, and will invoke a callback to indicate that the long running operation has finished. For instance, I have something like: int longRunningReadOperation(int length, byte * buf, void (*callback)()) When callback is called, then there are length bytes in buf. What I'd like to do is wrap this in Haskell function like: longRunningReadOperation :: Int -> IO [Byte] such that the function returns immediately, and only blocks when someone pulls on the results if the callback hasn't been triggered yet. I figure I'm going to need unsafeInterleaveIO, but I'm not sure what to do in the computation I pass to it. I had a small hope that if the callback put the results into an MVar (say var), and I returned (unsafeInterleaveIO (readMVar var)) that might work, but it seems like if the readMVar blocks then the callback doesn't execute either. This doesn't surprise me, but it does leave me needing another option. I don't see a way to get the callback into a new Haskell thread, so that it can do the putMVar from there... am I missing something obvious? Thanks in advance! /g

4 3

unsafeCoerce# between integral and floating point types
by Daniel Fischer 09 Jul '10

09 Jul '10

The docs for unsafeCoerce# say: "The following uses of unsafeCoerce# are supposed to work (i.e. not lead to spurious compile-time or run-time crashes): # Casting any lifted type to Any # Casting Any back to the real type # Casting an unboxed type to another unboxed type of the same size (but not coercions between floating-point and integral types) ..." My experience so far is consistent with the assumption that e.g. unsafeCoerce# :: Word64 -> Double is like a cast from (uint64_t *) to (double *), i.e. a bit-pattern- preserving transformation (although by the docs, that use is undefined). Would that assumption generally hold for unsafeCoerce :: a -> b where a and b are single constructor data types wrapping unboxed types of the same bit-size and hence the use of unsafeCoerce# between such types would produce reliable results *on the same machine with the same OS (and GHC version?)* ? And what about e.g. unsafeCoerce# :: Word64# -> Double# ? By the docs, that isn't supposed to work. Is it not supposed to work only because it's not value-preserving (unsafeCoerce# 1## /=## 1.0##) or are there more pitfalls? If there are more pitfalls, is there any chance of getting a function which reinterprets the bit-patterns? Thanks, Daniel

4 4

Avoiding O(n^2) instances when using associated data types to unpack values into constructors
by Johan Tibell 06 Jul '10

06 Jul '10

Hi, I'm trying to create a data type for maps where both keys and values are unpacked into the data type constructors (see code at the end of this email). I achieve this using an associated data type of two arguments (`Map` in the code below). The problem I have is that this definition requires O(n^2) instances. I use a CPP macro to make it easier to create these instances but it doesn't address the real problem that the number of instances grows quadratically. Is there a better way to have GHC unpack the keys and values into the data constructors? Cheers, Johan \begin{code} {-# LANGUAGE CPP, MultiParamTypeClasses, TypeFamilies #-} -- | This module defines a type for maps of unboxed keys and values. module Data.AdaptMap (Unbox()) where -- | The size of the map. type Size = Int -- | A map of unboxed keys and values. class Unbox k a where data Map k a :: * -- Constructors/destructors used to implement functions on the map -- in a generic manner. tipCon :: Map k a binCon :: Size -> k -> a -> Map k a -> Map k a -> Map k a unMap :: Map k a -> b -> (Size -> k -> a -> Map k a -> Map k a -> b) -> b #define primMap(map,key,val,tipcon,bincon) \ instance Unbox key val where { \ data Map key val = tipcon \ | bincon {-# UNPACK #-} !Size \ {-# UNPACK #-} !key \ {-# UNPACK #-} !val \ !(Map key val) \ !(Map key val) \ ; tipCon = tipcon \ ; {-# INLINE tipCon #-} \ ; binCon = bincon \ ; {-# INLINE binCon #-} \ ; unMap t tk bk = case t of { \ tipcon -> tk \ ; bincon sz k v l r -> bk sz k v l r } \ ; {-# INLINE unMap #-} \ } -- Example instance with keys and values of type Int. primMap(IntIntMap,Int,Int,IntIntTip,IntIntBin) ------------------------------------------------------------------------ -- Construction empty :: Unbox k a => Map k a empty = tipCon singleton :: Unbox k a => k -> a -> Map k a singleton k x = binCon 1 k x tipCon tipCon \end{code}

2 1

BlockedIndefinitelyOnMVar exception
by Neil Mitchell 06 Jul '10

06 Jul '10

Hi, I have a very big and highly threaded program that generates a BlockedIndefinitelyOnMVar exception when run. I have spent a reasonable amount of time pouring over the source code, as has Max Bolingbroke. Neither of us have the slightest idea why it raises the exception. Some questions: * Does anyone know the exact sequence of actions that causes this exception to be thrown? I couldn't find it written down. * How confident are people that this exception does really mean that it is in a blocked state? Is there any chance the error could be raised incorrectly? * Any debugging tips for this problem? Thanks, Neil

3 10

Casts, and allocation
by Louis Wasserman 02 Jul '10

02 Jul '10

Hey, I was wondering how difficult it would be to improve handling of casts, as follows: when looking at Core, I see things like (\ (ds_dcKZ :: Data.TrieMap.TrieKey.TrieMap (Data.TrieMap.Regular.Base.App f_XcwB k_XcwD) a_acAi) -> f_scPr (ds_dcKZ `cast` (trans (Data.TrieMap.Regular.App.TFCo:R:TrieMapAppa f_XcwB k_XcwD a_acAi) (Data.TrieMap.Regular.App.NTCo:R:TrieMapAppa f_XcwB k_XcwD a_acAi) :: Data.TrieMap.TrieKey.TrieMap (Data.TrieMap.Regular.Base.App f_XcwB k_XcwD) a_acAi ~ Data.TrieMap.Regular.Class.TrieMapT f_XcwB k_XcwD a_acAi))) which is equivalent to a single cast of f. I get that generalized newtype deriving does something like this automatically -- unfortunately, at the moment, I'm using a class with associated types, so I can't do that. How difficult would it be to identify and rewrite these, when they appear in non-recursive lets? (I'm actually experimenting with implementing the change myself, but I've never hacked GHC before, so we'll see how it goes...) Louis Wasserman wasserman.louis(a)gmail.com http://profiles.google.com/wasserman.louis

1 0

RE: [Haskell-cafe] checking types with type families
by Simon Peyton-Jones 01 Jul '10

01 Jul '10

| Here's a concrete case I recently ran into: | | type family SomeOtherTypeFamily a | class SomeClass a where type SomeType a | instance a ~ SomeOtherTypeFamily b => SomeClass a where | type SomeType a = (b,Int) | -- (error) Not in scope: type variable `b' | | The same thing with fundeps: | | class SomeClass a b | a -> b | instance a ~ SomeOtherTypeFamily b => SomeClass a (b,Int) | -- works fine It's not the same thing at all! The code you give certainly should fail. Suppose you use fundeps thus: class C a b | a->b where op :: a -> b -> b The idiomatic way to replace this with type functions is to remove the 'b' parameter, thus: class C a where type B a op :: a -> B a -> B a Sometimes you don't want to do this. For example, you might have a bidirectional fundep. Then you can (or rather will be able to) use a superclass thus: class (B a ~ b) => C a b where type B a The superclass says that you can only instantiate this class with a second argument b that is equal to (B a). Thus you might have an instance instance C Int Bool where type B Int = Bool Meanwhile we are working hard on the new type inference engine, which will allow superclass equalities like these. Simon

1 0

Help with Win64 port
by George Brewster 01 Jul '10

01 Jul '10

Hey, I'd really like to see ghc working on 64-bit Windows, so I've decided to take at least a quick stab at getting it going. Having talked to some of the people on #ghc, it sounds like the first thing to do is get an unregisterised build going, which sounded like it may be managable. So to that end, I've pulled the 6.12 branch, done a 32-bit build, changed the build config to do an unregisterised build and turn off the native code generator, found a version of mingw64 which seems to work for me, stuffed it in in place of the in-tree mingw, and got my build to fail. At this point, I'd like to get a general idea of what my strategy should be. I read the Building/Porting page on the wiki, and used the config file there as an example of how to do an unregisterised build, but have been ignoring anything related to the hc file bootstrapping process, as I have a working ghc on my platform, just of the wrong bitness. In particular, if there are any changes that you know I'll need to make to the source to get this working, please let me know. The more of those I learn about now, the less fumbling around I'll have to do as things break. In particular, is there some place where I indicate that I'm build a 64-bit compiler? I didn't find anything with a quick look. I have very little time to work on it, and no familiarity with ghc internals, so I wouldn't expect much, but I'm hoping I can get it going... -George

2 1

Re: [Haskell-cafe] Space leak with unsafePerformIO
by Yitzchak Gale 01 Jul '10

01 Jul '10

Henning Thielemann wrote on Haskell Cafe: >> Attached is a program with a space leak... >> I have coded a simple 'map' function, once using unsafePerformIO and >> once without. UnsafePerformIO has a space leak in some circumstances. >> In the main program I demonstrate cases with and without space leak. >> Without space leak the program writes a file to the disk until it >> is full. Bertram Felgenhauer wrote: > The program relies on the GC doing short-cut evaluation of record > selectors to avoid a space leak... > Use of suffix: Due to the call of Main.go1 this is *not* a record > selector. It is compiled to an actual case expression, which to the > garbage collector looks just like an ordinary thunk. A reference to > Main.ds is kept around until the suffix is about to be processed > and a memory leak ensues. > The good news is that the problem is completely unrelated to > unsafePerformIO (the presence of unsafePerformIO makes optimisations > more difficult, but any pure function of sufficient complexity would > have the same effect). Is there already a GHC Trac bug for this? Link to Bertram's original email, with detailed analysis of the GHC Core: http://www.haskell.org/pipermail/haskell-cafe/2010-June/079479.html Thanks, Yitz

2 1