- Glasgow-haskell-users

Why is partition no good list producer?
by Jan Scheffczyk 25 Feb '04

25 Feb '04

Hi all, I'm about to optimize a fairly large Haskell program, which uses partition quite often (and a fold immediately afterwards). The GHC User guide section about RULE pragmas says that filter is a good producer, whereas partition is not mentioned (therefore, I assume it is not). I put a little test program together: > fuse1 :: [Bool] -> (Bool,Bool) > fuse1 xs = (x,y) > where (fs,gs) = partition id xs > x = foldr (&&) True fs > y = foldr (||) False gs > fuse2 :: [Bool] -> (Bool,Bool) > fuse2 xs = (x,y) > where fs = filter id xs > gs = filter not xs > x = foldr (&&) True fs > y = foldr (||) False gs Compiling it via ghc -O and loading the compiled object to ghci results in: Prelude Test> fuse2 (replicate 10000000 False) (True,False) (8.19 secs, 241174592 bytes) Prelude Test> fuse1 (replicate 10000000 False) (*** Exception: stack overflow (6.18 secs, 48472660 bytes) I understand the results: Using partition an intermediate list seems to be build. But WHY? Is it simply because of a missing RULE pragma for partition or is there a "deeper" reason? Cheers, Jan

2 2

RE: inconsistent GHC building documentaion
by Simon Marlow 25 Feb '04

25 Feb '04

> In the "Building the Glasgow Functional Programming Tools > Suite", chapter > 12, Notes for building under Windows > (http://www.haskell.org/ghc/docs/6.2/html/building/winbuild.ht > ml), it is > said: "Install an executable Happy, from > http://www.haskell.org/happy". The > latest version of happy in its website is 1.13. When running > configure in > fptools, however, I get the error: > > configure: error: Happy version 1.14 or later is required to > compile GHC. Firstly, discussion about the development versions of GHC usually take place on cvs-ghc(a)haskell.org rather than here (to avoid confusion). The CVS HEAD currently requires Happy 1.14, which hasn't been released yet. It is available in the source tree (fptools/happy), so to build the CVS HEAD you currently also need to either: (a) check out fptools/happy and use --enable-src-tree-happy when configuring GHC. (b) Build & install Happy separately from CVS Cheers, Simon

1 0

GC behaviour in GHC
by Nivia Q. 24 Feb '04

24 Feb '04

Hello, GHC users, I'm a Computational Engineering student in the University of Pernambuco (Brazil). In my research, I'm working with applications written in Haskell , where time is a critical factor. But there is a pretty high GC overhead I can't understand . Can someone indicate some paper or reference about the GC behaviour in GHC? Thanks, _________________________________________________ Nivia Cruz Quental Graduação em Eng. Computação - UPE Técnica em Telecomunicações - CEFET-PE - Brasil --------------------------------- Yahoo! Mail - O melhor e-mail do Brasil. Abra sua conta agora!

4 4

ghc and signal processing
by Jeremy Shaw 24 Feb '04

24 Feb '04

Hello, I was thinking about using haskell to do some 'realtime' audio signal processing, and am trying to figure out how close to the holy grail of "C" code I can get when it comes to speed. Currently, it looks like I might be looking at running 10 times slower. Is there stuff I could do to get better performance out of haskell? In example 1, I create an unitialized 1.8MB array of type 'IOUArray Int Word8', and write it to a file. This takes a mere 0.056 seconds (on an Athlon 600). module Main where import Data.Array import Data.Array.IO import System.IO main = do h <- openBinaryFile "test.b" WriteMode a <- newArray_ (1,1800000) hPutArray h a 1800000 In example 2, I apply a filter to the array (in this case, the filter is just the id function). This takes around 1.06 seconds. main = do h <- openBinaryFile "test.b" WriteMode a <- newArray_ (1,1800000) b <- mapArray id a hPutArray h b 1800000 If I apply the 'filter' twice, the time increases to 2.58 seconds: main = do h <- openBinaryFile "test.b" WriteMode a <- newArray_ (1,1800000) b <- mapArray id a c <- mapArray id b hPutArray h c 1800000 By comparison, the following c program runs in 0.10 seconds: #include <stdio.h> int main (int argc, char *argv[]) { FILE *fp; char *a; char *b; int i; a = (char *)malloc (1800000); b = (char *)malloc (1800000); for (i = 0; i < 1800000; i++) { b[i] = a[i]; } fp = fopen("test.b","w"); fwrite(b, 1, 1800000, fp); fclose(fp); free(b); free(a); return 0; } I compile using ghc from cvs as follows: ghc -O2 -fvia-C Test.hs -o test I also tried just -O, and no -fvia-C, and the performance was the same. Without -O, it was about 5 times slower. I compiled the c code with: gcc -O2 test.c -o test. I am using ghc from cvs head and gcc 2.95 on FreeBSD. Are there secret options I should enable on the compiler? Or perhaps there is a faster way than using mapArray and unboxed arrays? Thanks! Jeremy Shaw.

2 3

optimization question
by John Meacham 24 Feb '04

24 Feb '04

I was wondering if: case x of "foo" -> Foo "bar" -> Bar "fuzz" -> Fuzz "fuzo" -> Fuzo x -> other .. thing would optimize to let z = other .. thing in case x of ('f':x) -> case x of ('u':'z': x) -> "z" -> Fuzz "o" -> Fuzo _ -> z "oo" -> Foo _ -> z "bar" -> Bar _ -> z The reason I ask is I am writing someting which will generate large case statements like the first form and want to know if I should bother pre-optimizing it to the second. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ---------------------------------------------------------------------------

6 5

RE: optimization question
by Simon Peyton-Jones 24 Feb '04

24 Feb '04

The trouble is that you probably *don't* want to expand this case x of { "foogle" -> e1; _ -> e2 } to this case x of c1:x1 -> case c1 of 'f' -> case x1 of c2:x2 -> case c2 of 'o' -> of .... So GHC generates a series of equality tests instead. A decent alternative might be: generate case expressions when there is more than one string in the list, otherwise use an equality test That would not be hard to do. If it becomes important to you, I'd have a go. But before doing so, could you do the work by hand and see if it makes a useful performance difference? Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Sven Panne | Sent: 22 February 2004 15:32 | To: John Meacham | Cc: glasgow-haskell-users(a)haskell.org | Subject: Re: optimization question | | John Meacham wrote: | > I was wondering if: | > | > case x of | > "foo" -> Foo | > "bar" -> Bar | > "fuzz" -> Fuzz | > "fuzo" -> Fuzo | > x -> other .. thing | > | > would optimize to | > | > let z = other .. thing in | > case x of | > ('f':x) -> case x of | > ('u':'z': x) -> | > "z" -> Fuzz | > "o" -> Fuzo | > _ -> z | > "oo" -> Foo | > _ -> z | > "bar" -> Bar | > _ -> z | | String literals are handled in a special way in GHC, so your example is | essentially converted into an if-cascade, which is not what you want. | OTOH, if you write the strings in their expanded form like ['f','o','o'], | you get your optimized version automatically. Perhaps Simon^2 can comment | on the rationale behind this, I can't remember the reason... | | Cheers, | S. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

4 3

Hugs98 - GHC
by gaby82＠adinet.com.uy 24 Feb '04

24 Feb '04

Hi, I've an application in Hugs98 and i've to integrate it with another application using GHC. I don´t know how to do this. I tried to compiled the hugs98 application using GHC but i couldn´t Another question: can i compiled many hs at the same time? Thanks a lot Gabriela

1 0

Array optimisation...
by MR K P SCHUPKE 23 Feb '04

23 Feb '04

Was just thinking about GHC's implementation of arrays, and their poor performance. I know little about GHC's internal workings, but I was thinking about how array performance could be improved. What if when writing an array you instead construct a function: f :: (Ix x,Ix y) => Array a -> Ix x -> a -> Ix y -> a f a x b y | x==y = b | otherwise = a!y Then the update in place operator // becomes a curried application of 'f' above. You could then define a a series of 'overlays' for a base array. The clever bit would be to get the garbage collector to merge the two as soon as any reference to the original array is discarded. Does GHC already do anything like this? Regards, Keean Schupke.

2 1

Re: ghc and signal processing
by MR K P SCHUPKE 23 Feb '04

23 Feb '04

>b <- mapArray id a The reason it is slow is because the array type is copied every time a member is assigned. There are two solutions: 1) Use a mutable-array in the StateMonad then freeze it. 2) In this particular case where processing is sequential (IE you are only altering values based on *nearby* values, you can use streams. One of the nicest features of Haskell is how lists (being lazy) operate just like streams... So read the data into a list and define a filter of the type filter :: [a] -> [a] Your program then becomes: main :: IO () main = do s <- getMyDataAsList() putMyList (filter s) where the commands getMyDataAsList and putMyList have the types: getMyDataAsList :: IO [a] putMyList :: [a] -> IO () This should be fast, and also use very little memory. Regards, Keean Schupke.

2 1

How to write this correct...
by HNBeck＠t-online.de 23 Feb '04

23 Feb '04

Hi, I have the following problem: Vertex3 ist defined as data Vertex3 a = Vertex3 a a a a is defined as class a VertexComponent But I fail to write to following correct type GLVertex = (GLfloat, GLfloat, GLfloat) toVertex :: GLVertex -> Vertex3 a <<<<<<<< how do it correctly toVertex (x,y,z) = Vertex3 x y z The compiler says "cannot infer a with type GLFloat" or something like this.... I don't understand. Thank you for help Hans

3 3