RE: ghc and signal processing
I think the HEAD goes just as fast as 6.2 now. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- | [EMAIL PROTECTED] On Behalf Of Jeremy Shaw | Sent: 24 February 2004 04:04 | To: [EMAIL PROTECTED] | Subject: Re: ghc and signal processing | | Hrm, | | Okay, it seems that my problems maybe be due to using ghc 6.3. | | Here are the results of running test under different compiler versions | (see end of message for code): | | | Athlon 600MHz + FreeBSD + GHC 6.0.1 | | real0m0.414s | user0m0.361s | sys 0m0.016s | | Athlon 600MHz + FreeBSD + GHC 6.3 (built from CVS HEAD on Feb 15, 2004) | | real0m2.517s | user0m2.289s | sys 0m0.069s | | Pentium III 1.13GHz + Debian + GHC 6.2 | | real0m0.305s | user0m0.196s | sys 0m0.027s | | Pentium III 1.13GHz + Debian + GHC 6.3 (built from CVS HEAD on Feb 1, 2004) | | | real0m1.302s | user0m1.196s | sys 0m0.044s | | | So it seems like maybe GHC 6.3's performance for this particular test | is around 3-5 slower? | | Jeremy Shaw. | | | module Main where | | import Data.Array | import Data.Array.IO | | import System.IO | | main = do h - openFile test.b WriteMode | a - newArray_ (1,180) | b - mapArray id a | c - mapArray id b | hPutArray h c 180 | | | At Mon, 23 Feb 2004 13:37:45 -0800, | Mike Gunter wrote: | | | Hmmm. With -O2 on GHC 6.2, I get 0.177s, 0.217s, and 0.348s for your | three Haskell examples and 0.187s (with gcc -O2) for your C example. | The output of -ddump-simpl for the looks perfect for the second | Haskell example. My GHC seems to be doing a bang-up job here. What's | wrong with yours? (For the third example GHC's code could be improved | by additional inlining or hoisting of a constant array outside of the | loop.) | | mike | | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc and signal processing
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. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc and signal processing
On 23.02.2004, at 13:32, MR K P SCHUPKE wrote: b - mapArray id a The reason it is slow is because the array type is copied every time a member is assigned. The array in question is already a mutable array, and even for non-mutable arrays, mapArray would use mutable arrays internally. The problem here is that mapArray's implementation isn't perfect, and that GHC doesn't generate perfect code for it. I was able to get a 16% performance increase by using the following instead of GHC's built-in mapArray: import Data.Array.Base myMapArray :: (MArray a e' m, MArray a e m, Ix i) = (e' - e) - a i e' - m (a i e) myMapArray f marr = case Data.Array.IO.bounds marr of (l,u) - do marr' - newArray_ (l,u) let loop i n | i == n = return () | otherwise = do e - unsafeRead marr i unsafeWrite marr' i (f e) loop (i+1) n loop 0 (rangeSize (l,u)) return marr' The difference is that I use an explicit loop rather than an intermediate list of indices ([1 .. rangeSize (l,u) - 1]) that GHC fails to optimize away. There are two solutions: 1) Use a mutable-array in the StateMonad then freeze it. This won't help in this case (see above). 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... [...] This should be fast, and also use very little memory. I second that. You might need to use arrays for input and output, but for everything in between, lists are probably a very good choice. Using lists this way in Haskell is probably more efficient that using an equivalent data structure in C. When you use arrays, GHC often ends up using lists internally, as we saw above. So the luxury of using lists really shouldn't cost too much. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc and signal processing
Hmmm. With -O2 on GHC 6.2, I get 0.177s, 0.217s, and 0.348s for your three Haskell examples and 0.187s (with gcc -O2) for your C example. The output of -ddump-simpl for the looks perfect for the second Haskell example. My GHC seems to be doing a bang-up job here. What's wrong with yours? (For the third example GHC's code could be improved by additional inlining or hoisting of a constant array outside of the loop.) mike ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc and signal processing
Hrm, I am going to do some new test tonight. I think my test environment may have been bad... Jeremy Shaw. At Mon, 23 Feb 2004 13:37:45 -0800, Mike Gunter wrote: Hmmm. With -O2 on GHC 6.2, I get 0.177s, 0.217s, and 0.348s for your three Haskell examples and 0.187s (with gcc -O2) for your C example. The output of -ddump-simpl for the looks perfect for the second Haskell example. My GHC seems to be doing a bang-up job here. What's wrong with yours? (For the third example GHC's code could be improved by additional inlining or hoisting of a constant array outside of the loop.) mike ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc and signal processing
Hrm, Okay, it seems that my problems maybe be due to using ghc 6.3. Here are the results of running test under different compiler versions (see end of message for code): Athlon 600MHz + FreeBSD + GHC 6.0.1 real0m0.414s user0m0.361s sys 0m0.016s Athlon 600MHz + FreeBSD + GHC 6.3 (built from CVS HEAD on Feb 15, 2004) real0m2.517s user0m2.289s sys 0m0.069s Pentium III 1.13GHz + Debian + GHC 6.2 real0m0.305s user0m0.196s sys 0m0.027s Pentium III 1.13GHz + Debian + GHC 6.3 (built from CVS HEAD on Feb 1, 2004) real0m1.302s user0m1.196s sys 0m0.044s So it seems like maybe GHC 6.3's performance for this particular test is around 3-5 slower? Jeremy Shaw. module Main where import Data.Array import Data.Array.IO import System.IO main = do h - openFile test.b WriteMode a - newArray_ (1,180) b - mapArray id a c - mapArray id b hPutArray h c 180 At Mon, 23 Feb 2004 13:37:45 -0800, Mike Gunter wrote: Hmmm. With -O2 on GHC 6.2, I get 0.177s, 0.217s, and 0.348s for your three Haskell examples and 0.187s (with gcc -O2) for your C example. The output of -ddump-simpl for the looks perfect for the second Haskell example. My GHC seems to be doing a bang-up job here. What's wrong with yours? (For the third example GHC's code could be improved by additional inlining or hoisting of a constant array outside of the loop.) mike ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc and signal processing
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,180)
hPutArray h a 180
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,180)
b - mapArray id a
hPutArray h b 180
If I apply the 'filter' twice, the time increases to 2.58 seconds:
main = do h - openBinaryFile test.b WriteMode
a - newArray_ (1,180)
b - mapArray id a
c - mapArray id b
hPutArray h c 180
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 (180);
b = (char *)malloc (180);
for (i = 0; i 180; i++) {
b[i] = a[i];
}
fp = fopen(test.b,w);
fwrite(b, 1, 180, 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.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
