February 2004 - Glasgow-haskell-users

ghc and signal processing
by Jeremy Shaw 23 Feb '04

23 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 23 Feb '04

23 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 23 Feb '04

23 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 23 Feb '04

23 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 22 Feb '04

22 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

problems building GHC from source in Windows
by Andre W B Furtado 22 Feb '04

22 Feb '04

I was trying to build GHC in my Windows XP, using Cygwin, following the steps in the building guide. I'm stuck in the following error when executing "make" in fptools: creating libgmp.la (cd .libs && rm -f libgmp.la && ln -s ../libgmp.la libgmp.la) make[6]: Leaving directory `/cygdrive/c/haskell/cvs/fptools/ghc/ghc/rts/gmp' make[5]: Leaving directory `/cygdrive/c/haskell/cvs/fptools/ghc/ghc/rts/gmp' ../../ghc/compiler/ghc-inplace -H16m -O -O2 -static -c Apply.hc -o Apply.o make[3]: *** [Apply.o] Error 1 make[2]: *** [all] Error 1 make[2]: Leaving directory `/cygdrive/c/haskell/cvs/fptools/ghc/ghc' make[1]: *** [build] Error 1 make[1]: Leaving directory `/cygdrive/c/haskell/cvs/fptools/ghc' make: *** [build] Error 1 Any suggestions? Thanks, -- Andre

2 1

inconsistent GHC building documentaion
by Andre W B Furtado 20 Feb '04

20 Feb '04

Hi, 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.html) 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. Suggestions: 1) Make happy 1.14 available in its website 2) Change GHC building instructions in chapter 12 (saying that version 1.14 of Happy must be used and it can be built from the CVS sources). BTW, is there any problem using happy 1.14 compiled from source? Cheers, -- Andre

1 0

Subject: Generic compilation warnings...
by MR K P SCHUPKE 17 Feb '04

17 Feb '04

When deriving Data with all warnings enabled, for example compiling the following line: data TestType = TestType Int deriving (Typeable,Data) ghc 6.2 gives the following warnings: Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: GHC.Base.I# #x with #x `notElem` [1#] Is there a problem with the 'derived' code, or should this warning be ignored? regards, Keean Schupke.

1 0