February 2009 - Glasgow-haskell-users

DPH Questions
by James Swaine 12 Feb '09

12 Feb '09

I was wondering if anyone could point me to a more in-depth explanation of why we are (currently) restricted to using a special-purpose standard Prelude when writing vectorised code with DPH. We're prototyping using several data-parallel languages for a research project here at Northwestern University, and wanted to get a better idea how we might go about adding vectorisation support for addtional types/operations. There are certain simple operations which don't appear to be supported for primitive types yet (e.g. the ^ and ** operators for an Int type). These are the kinds of things we'd like to look into as a first step. Also - there are several papers which mention foldP as being part of the (prospective) implementation, but I couldn't find this in any of the modules. Has this one not been implemented yet? Much thanks, James Swaine

3 3

bug in ghc specialiser?
by Malcolm Wallace 11 Feb '09

11 Feb '09

Here is an apparent bug in ghc's specialisation rules. The rewrite rule generated by a SPECIALISE pragma seems to want to pattern-match on exact dictionaries (as well as types). But the compiler is not necessarily able to fully resolve dictionaries before the rules are supposed to fire. First, the source code we want to specialise: {-# SPECIALISE hedgehog :: Float -> Vector3 Float -> [Cell_8 (Coord3 Float)] -> [Cell_8 (Vector3 Float)] -> [(Coord3 Float, Coord3 Float)] #-} hedgehog :: ( Fractional a, Cell cell vert, Eq vert , Geom coord, Geom vector, Embed vector coord ) => a -> vector a -> [cell (coord a)] -> [cell (vector a)] -> [(coord a, coord a)] And the core + interface generated for this module contains the rule: "SPEC Hedgehog.hedgehog" ALWAYS forall Hedgehog.hedgehog @ GHC.Float.Float @ RectGrid.Cell_8 @ CellTypes.MyVertex @ Geometries.Coord3 @ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3 GHC.Float.$f16 RectGrid.$f2 CellTypes.$f1 Geometries.$f5 Geometries.$f3 Geometries.$f1 = Hedgehog.hedgehog1 But in a different module, here is what the usage site looks like just before the specialisation rules are supposed to fire: hedgehog_a4wy = Hedgehog.hedgehog @ GHC.Float.Float @ RectGrid.Cell_8 @ CellTypes.MyVertex @ Geometries.Coord3 @ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3 $dFractional_a4xP RectGrid.$f2 CellTypes.$f1 (Dataset.$p2Embed @ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3 @ Geometries.Coord3 Geometries.$f1) (Dataset.$p1Embed @ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3 @ Geometries.Coord3 Geometries.$f1) Geometries.$f1 Notice how there are several dictionary selector functions sitting there, so although some of the dictionaries match, not all do, and the rule does not fire. However, later the worker-wrapper transformation is able to resolve those outstanding dictionaries, giving: hedgehog_a4wy = Hedgehog.$whedgehog @ GHC.Float.Float @ RectGrid.Cell_8 @ CellTypes.MyVertex @ Geometries.Coord3 @ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3 GHC.Float.$f16 RectGrid.$f2 Geometries.$f5 Geometries.$f3 Geometries.$f1 So I'm left calling the worker for the polymorphic version of the function, rather than the specialised monomorphic code I wanted. Given how many dictionaries are involved, and that this is the inner loop of the program, I'm hoping there is a big performance win waiting for me, if only I can get that specialised code to run! Regards, Malcolm

2 1

Pragma not recognised when wrapped in #ifdef
by Alistair Bayley 11 Feb '09

11 Feb '09

I have this little test program: {-# LANGUAGE CPP #-} #ifdef PRAGMA_DERIVE_TYPEABLE {-# LANGUAGE DeriveDataTypeable #-} #else {-# OPTIONS -fglasgow-exts #-} #endif -- This file is Test/Fail.hs. -- ghc --make -optP-DPRAGMA_DERIVE_TYPEABLE -XCPP Test.Fail module Test.Fail where import Data.Generics data Fail = Fail deriving Typeable If compile this wih the command ghc --make -optP-DPRAGMA_DERIVE_TYPEABLE -XCPP Test.Fail then I get this error from ghc-6.10.1: [1 of 1] Compiling Test.Fail ( Test\Fail.hs, Test\Fail.o ) Test\Fail.hs:11:26: Can't make a derived instance of `Typeable Fail' (You need -XDeriveDataTypeable to derive an instance for this class) In the data type declaration for `Fail' I've checked the preprocessor output with -E, and that looks fine. I can compile the preprocessor output with ghc without errors. Alistair

7 9

Byte in list
by Aswad, Mustafa K 10 Feb '09

10 Feb '09

Hi dear I need to calculate the size of alist consist of n element (("I(a*b)" , "I(b) , I(a)") in 32 bit machine ? -- Heriot-Watt University is a Scottish charity registered under charity number SC000278.

1 0

Re: How bad is the PowerPC backend?
by Tim Chevalier 09 Feb '09

09 Feb '09

On 2/9/09, David Brown <haskell(a)davidb.org> wrote: > > Which CPU is the x86? The modern x86 CPUs (such as Core2) will be > significantly faster than the PowerPC, even at comparable clock rates. > Have you just compared even C code tests? > I think that goes a long way towards explaining it... a simple C loop that I tried runs for 4.5s on the PC and 30s on the Mac. So probably this isn't GHC's fault. Thanks for the suggestion. Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "In fact, a sense of essence is, in essence, the essence of sense, in effect." -- Douglas Hofstadter

1 0

How bad is the PowerPC backend?
by Tim Chevalier 09 Feb '09

09 Feb '09

Hello, For obscure reasons, I'm running some benchmarks both on an x86 machine (2.20 Ghz, 2 GB of RAM, Linux 2.6.22-15) and on a PowerPC Mac (1 Ghz, 512 MB of RAM, Mac OS 10.5). I noticed that even some pretty simple programs run much slower on the Mac than on the PC. For example, the following program (edited down from the "life" nofib benchmark): ------------------------------------------------- limit xs = go [] xs go acc (x:y:xs) | x==y = acc ++ [x] | otherwise = go (acc ++ [x]) (y:xs) go acc [x] = acc ++ [x] go acc [] = error "limit" main = print (length (limit (iterate (\ x -> if x == 10000 then x else (x+1)) 1))) --------------------------------------------------- runs in about 1.5 seconds on the PC, and 14 seconds on the Mac. This is with ghc -O2, version 6.10.1. The numbers are about the same on either machine whether I use -fvia-C or -fasm. The Mac does have a lot less RAM, but I can see that the program isn't swapping. So is the PPC backend really this bad, or should I be looking for something weird with the hardware or configuration on the Mac? Thanks, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "I don't like your I-can-use-anything-as-an-adjective attitude." -- Larry Wall

2 2

length of module name affecting performance??
by Daniel Gorín 09 Feb '09

09 Feb '09

Hi While trying to see if I could make some code run faster I stumbled upon something that looks weird to me: 2x-3x performance loss when a module is renamed to a longer name! Here's what I see with the attached examples: #diff long-modname-ver.hs short-modname-ver.hs 2c2 < import VeryLongModuleName --- > import ShortM #diff VeryLongModuleName.hs ShortM.hs 1c1 < module VeryLongModuleName --- > module ShortM #ghc --make -O2 -Wall long-modname-ver.hs #ghc --make -O2 -Wall short-modname-ver.hs #time -p ./long-modname-ver > /dev/null real 55.90 user 55.17 sys 0.51 #time -p ./short-modname-ver > /dev/null real 22.23 user 21.97 sys 0.10 I'm using GHC 6.10.1 on OS X. Any ideas on what may be going on? Thanks Daniel

9 12

Display of associated types in GHCi
by Douglas McClean 06 Feb '09

06 Feb '09

I have a question about the display of names for associated types in GHCi. I have a module with a matrix type constructor: > data (Natural r, Natural c) => Matrix r c t = Matrix [[t]] deriving (Eq) which uses type-level naturals to provide dimension checking. A type class for multiplication: > class Multiply a b where > type Product a b > times :: a -> b -> Product a b and an instance for matrix multiplication: > instance (Natural a, Natural b, Natural c, Num t) => Multiply (Matrix a b t) (Matrix b c t) where > type Product (Matrix a b t) (Matrix b c t) = Matrix a c t > times m1 m2 = ... All of this works really well, I get dimension checking (and inference), and lot of other goodies. My question has to do with the following GHCi session: *Main> let a = matrix two two [[1,1],[2,6]] *Main> :t a a :: Matrix Two Two Integer *Main> :t a `times` a a `times` a :: Product (Matrix Two Two Integer) (Matrix Two Two Integer) Am I correct that the type denoted by "Product (Matrix Two Two Integer) (Matrix Two Two Integer)" is always "Matrix Two Two Integer"? It certainly behaves that way in more complicated expressions, which is desirable. If so, could someone explain the reason why GHCi chooses not to simplify such types for display? Could it? Is there a reason why such simplification would be undesirable (when it is possible, I understand that it wouldn't be if type variables were present)? Thanks, Doug McClean

3 3

Temporarily overriding Data.Generic
by Deniz Dogan 06 Feb '09

06 Feb '09

Sorry for those who receive this who have already gotten it from haskell-cafe. --- Hi I'm currently working on "hacking" Data.Generics for my master thesis. I'm basically trying to find out whether it can be made any faster using e.g. rewrite rules. The problem I'm having is that I need an easy way to import my own modified version of Data.Generics (currently located in the same directory as my testing program) without unregistering or hiding syb-0.1.0.0 as base seems to depend on it. I've read the GHC user manual trying to find nice ways to do this using a bunch of different parameters to ghc, but I can't figure it out. Does anyone here know? Any help appreciated, Deniz

3 3

Error in building profiling
by Marco Túlio Gontijo e Silva 06 Feb '09

06 Feb '09

Hello, I'm trying to package ghc-paths for debian, and I got to this: $ ./setup configure --enable-library-profiling --disable-library-vanilla Configuring ghc-paths-0.1.0.5... $ ./setup build Preprocessing library ghc-paths-0.1.0.5... Building ghc-paths-0.1.0.5... /usr/bin/ar: creating dist/build/libHSghc-paths-0.1.0.5_p.a /usr/bin/ld: dist/build/GHC/Paths.o: No such file: No such file or directory I thought this could be a problem with this package, but I've tried with mtl, and I got the same result: /usr/bin/ld: dist/build/Control/Monad/Cont.o: No such file: No such file or directory I'm using ghc6 6.10.1+dfsg1-5 and binutils 2.19-1~exp1. I tried the same with ghc6 6.8.2dfsg1-1 and it worked. Greetings. -- marcot http://marcot.iaaeee.org/

1 0