- Glasgow-haskell-users

ForeignPtr performance
by Scott Dillard 17 Dec '07

17 Dec '07

Hi, I do a lot of programming with small compound objects, things like 3d vectors or RGBA tuples for images. For performance reasons, I keep them in StorableArrays, since there is no way to use these things with UArrays. (But that's a topic for another thread.) Some how the notion got into my head that StorableArrays were slow, I think from old versions of GHC. So I've gotten into the habit of using withStorableArray and peek/poke to work on my arrays. This, as you can imagine, is cumbersome. Not only because of the extra typing, but also because I have to do everything in the IO monad, even if the array is read-only. So I'm thinking about writing my own IArray instance using ForeignPtr for storage and unsafePerformIO for access. I did a little experiment, comparing > forM_ [0..lots] $ \i -> withForeignPtr fp $ \p -> pokeElemOff p i i to > withForeignPtr fp $ \p -> forM_ [0..lots] $ \i -> pokeElemOff p i i And there seemed to be no difference in running time, which is great. So I'm thinking of making unsafeAt something like > unsafeAt (MyArray fp) i = unsafePerformIO $ withForeignPtr fp $ \p -> peekElemOff p i My question is: what exactly does GHC.Prim.touch# do? This appears to be the critical function of withForeignPtr, and if I write my IArray instance as above, I have no way to float this touch# out of my loops, as I currently do using withStorableArray. It appears from my simple experiment that touch# does nothing at runtime. But maybe this is only because no memory is allocated inside my simple loop? Maybe if I write non-trivial loops, then touch# will actually cost something? Intensely curious, Scott

4 6

Type Relations
by Paulo J. Matos 17 Dec '07

17 Dec '07

Hello all, I've came across a problem which would be best implemented if I could define what I think to be a Type Relation. Let's consider classes as being type properties. When you say: class Num a where (+) :: a -> a -> a ... it defines a property of the type a. Basically all types a of class Num are addable, etc.. However, how can I (if I can) represent the fact that you can coerce a type a to a type b? A particular example of that is the fromInteger function from Num class where you say that if your type a is of class Num, you must be able to coerce an Int to a. I would like to define a relation between types and then say that two types are in the relation if they define the coerce function. Something I imagine would be: typerelation Coercible a b where coerce :: a -> b And then you would define instances of Coercible if you could define the function coerce between the types. You could then define function only over types which can be coerced from one to the other. Any suggestions on how to do something like this? -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK

2 2

Performance bug maybe
by Scott Dillard 17 Dec '07

17 Dec '07

Hi, I think I found a performance bug. Either that, or something is going on that I don't understand. I've attached an example program. Here's my session with it: =============== ghc --make -O2 MaybeBug.hs; time ./MaybeBug +RTS -tstderr [1 of 1] Compiling Main ( MaybeBug.hs, MaybeBug.o ) Linking MaybeBug ... ./MaybeBug +RTS -tstderr -1452071552 191905792 <<ghc: 800037360 bytes, 4 GCs, 40960/40960 avg/max bytes residency (1 samples), 383M in use, 0.00 INIT (0.00 elapsed), 3.96 MUT (4.36 elapsed), 0.00 GC (0.00 elapsed) :ghc>> real 0m4.408s user 0m3.960s sys 0m0.448s ghc --make -O2 MaybeBug.hs -DSLOW -no-recomp; time ./MaybeBug +RTS -tstderr [1 of 1] Compiling Main ( MaybeBug.hs, MaybeBug.o ) Linking MaybeBug ... ./MaybeBug +RTS -tstderr -1452071552 191905792 <<ghc: 4000037408 bytes, 6106 GCs, 400588800/400588800 avg/max bytes residency (2 samples), 765M in use, 0.00 INIT (0.00 elapsed), 9.71 MUT (10.53 elapsed), 0.05 GC (0.08 elapsed) :ghc>> real 0m10.717s user 0m9.761s sys 0m0.876s ================== There are two functions, initArray1 and initArray2, that have exactly the same implementation. I use them to initialize two arrays. If I use initArray1 on the first, and initArray2 on the second, then things get inlined and specialized wonderfully and no heap is used. If I use initArray1 to initialize both arrays, then less inlining happens. Since I'm doing possibly dangerous things with unsafePerformIO, I'm inclined to think this is not a bug, but I'm still wondering what's going on. On that note: is this use of unsafePerformIO in fact dangerous? I'm aware that allocating memory inside unsafePerformIO is not wise, especially when that function is to be inlined. If the function body is duplicated at the call site, I might get two identical arrays where I could have one that is shared. I can live with that possibility, but I'm more worried about the allocation being floated out of the unsafePerformIO, and having unintended sharing. Can this happen, the way I've written it? The inlining seems to be crucial for performance, so that constructor specialization can kick in. If there's a better way to do truly polymorphic unboxed immutable arrays, I'm all ears. (I'm aware of Bulat's ArrayRef library, but it doesn't seem to be maintained.. is it?) Scott

1 0

mingw64
by Bulat Ziganshin 14 Dec '07

14 Dec '07

Hello Glasgow-haskell-users, are you know about http://sourceforge.net/projects/mingw-w64 ? this project was started just a few months ago, but it already provides downloads to test. the win64 support is very important for my project so please look at it -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

upgrading visual studio integration to use 6.8.2....
by Nicholls, Mark 14 Dec '07

14 Dec '07

I've just downloaded the vs integration package....which looks great....but it comes with 6.6.1, and I was hoping to move to 6.8.2....does anyone know how to do this? Lead Broadcast and Corporate Architect Technology London (44) 0207 284 7596

5 8

Hugs faster than GHC
by Bernd Brassel 14 Dec '07

14 Dec '07

The following program reveals a performance bug in ghc 6.6 module HCBenchmark where type M1 a = () type M2 a = M1 a type M3 a = M2 a type M4 a = M3 a type M5 a = M4 a type M a = M4 a -- use M5 for 10 times the compile time and M3 for 1/10 f :: M (M (M (M (M (M (M (M (M (M x))))))))) f = () Each element you add in the chain of type synonyms adds a factor of ten to the compile time. Hugs is "a bit" faster :o) Trouble is, the module I wanted to compile originally, takes an estimated 6 thousand and 600 hours to compile and I am not sure that this bug is the only obstacle for the compiler ... Could anyone cope if that is still a problem with the newest instance of ghc? Thanks a lot Bernd

2 2

where's the best place to post those really irratating noddy questions that people who are learning Haskell ask.....
by Nicholls, Mark 14 Dec '07

14 Dec '07

4 3

Portage slots for GHC?
by Dinko Tenev 13 Dec '07

13 Dec '07

Hi, I'm using GHC on Gentoo, and so far I've had to stay clear of GHC 6.6, because I've also installed stuff depending on 6.4.2, like wxHaskell, for instance. Now I see a new version of mtl, which I also have installed, depends on 6.6.1, while all of the rest of the stuff is "lagging behind" with a dependency on 6.4.2. Of course, I can easily solve the problem partially by masking out the new version for mtl, but this is going to become a major inconvenience with new versions of GHC and its dependents. What I'm getting at is, can we please have separate slots for GHC 6.4.2 and 6.6 on portage? Cheers, Dinko

3 5

suggestion: add a .ehs file type
by Alex Jacobson 13 Dec '07

13 Dec '07

.ehs stands for extended haskell and encapsulates the 90% case of people just wanting -fglasgow-exts with a minimum of fuss. Having a filetype seesm better than the alternatives of either adding boilerplate language/options pragmas to the top of your source files or putting them in a cabal file. -Alex-

14 52

newtypes and optimization
by Scott Dillard 13 Dec '07

13 Dec '07

Hi, I have a statically-sized-list library that I use for linear algebra stuff. It's got a vector type something like this: > data V a b = V a b so that a 3D vector is > type Vec3 a = V a (V a (V a ())) and I have type classes for operations on these things, like so: > class VZipWith a b c u v w | {-lots of fundeps-} where > vzipWith :: (a -> b -> c) -> u -> v -> w > > instance VZipWith a b c (V a ()) (V b ()) (V c ()) where > vzipWith f (V x ()) (V y ()) = V (f x y) () > > instance > VZipWith a b c (V a u) (V b v) (V c w) > => VZipWith a b c (V a (V a u)) (V b (V b v)) (V c (V c w)) > where > vzipWith f (V x u) (V y v) = V (f x y) (vzipWith f u v) so that vector addition is > vadd = vzipWith (+) I put strictness annotations and INLINE pragmas all over the place, and GHC does wonders with it. Using Storable instances something like the following, > instance Storable a => Storable (V a ()) where > sizeOf _ = sizeOf (undefined::a) > peek p = peek (castPtr p) >>= \a -> return (V a ()) > --etc > > instance (Storable a, Storable v) => Storable (V a v) where > sizeOf _ = sizeOf (undefined::a) + sizeOf (undefined::v) > peek p = > a <- peek (castPtr p) > v <- peek (castPtr (p`plusPtr`sizeOf(undefined::a))) > return (V a v) GHC can turn a loop like this, > forM_ [0..n] $ \i -> > do a <- peekElemOff aptr i > b <- peekElemOff bptr i > pokeElemOff cptr i (vadd a b) into something as fast as C, using no heap. You look at the core and its nothing but readDoubleOffAddr#, +## and the like. I went so far as to generalize this to matrices with things like vector-matrix and matrix-matrix multiplication, determinants and all that and, when used in loops like above, it's consistently as fast or even faster than C. However when I do this: > newtype Quaternion = Q (Vec4 Double) Everything is ruined. Functions like peek and vadd are no longer inlined, intermediate linked lists are created all over the place. The Quaternion Storable instance looks like this > instance Storable s => Storable (Quaternion s) where > sizeOf _ = 4*sizeOf (undefined::s) > peek p = peek (castPtr p :: Ptr (Vec4 s)) >>= \v -> return (Q v) with strictness annotations and INLINEs for everything. I also tried automatic newtype deriving, with no luck. Why does a newtype defeat so much of the optimization? Thanks, Scott

4 4