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
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 (b
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
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
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 proble
>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 *n
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 be
