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 (b

Re: optimization question

G'day all. Quoting Peter Simons <[EMAIL PROTECTED]>: > If you don't mind using FFI, the tool of choice would > probably be . Perfect hash functions are actually not that much better than "imperfect" hash functions for the case where you have keys to search for

RE: optimization question

G'day. Quoting Hal Daume III <[EMAIL PROTECTED]>: > Finally, I implemented a version which reads data into a finitemap. I'd be curious about the relative performance in using a ternary search trie: http://cvs.sourceforge.net/viewcvs.py/hfl/hfl/edison/Assoc/ Cheers, Andrew Bromage _

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

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

Hugs98 - GHC

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 _

Re: optimization question

Max Kirillov writes: >> [...] I will generate large case statements like the >> first form and want to know if I should bother >> pre-optimizing it to the second. > I suppose such things should be made by flex-style > generators. If you don't mind using FFI, the tool of choice would probab

RE: optimization question

I have some numbers on this. I have a list of first names for males from the census data. I have a function 'male :: String -> Maybe Double' which returns (maybe) the probability of a person being given that name. I have two versions, one based on string matching, the other based on building

Re: optimization question

Simon Peyton-Jones wrote: generate case expressions when there is more than one string in the list, otherwise use an equality test Oh, you mean like hbc does? ;-) Sorry, couldn't resist. -- Lennart ___ Glasgow-haskell-users mailing list

Re: optimization question

On Sun, Feb 22, 2004 at 12:20:35AM -0800, John Meacham wrote: > case x of > "foo" -> Foo > "bar" -> Bar > "fuzz" -> Fuzz > "fuzo" -> Fuzo > x -> other .. thing > The reason I ask is I am writing someting which will generate large case > statements like the

Re: GC behaviour in GHC

On Sat, Feb 21, 2004 at 08:43:56PM -0300, Nivia Q. wrote: > 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 unde

Re: GC behaviour in GHC

Nivia, Don has mentioned most of the documentation about GC work in GHC except for: Generational garbage collection for Haskell - Sansom, Peyton Jones http://citeseer.nj.nec.com/sansom93generational.html There isn't really a paper on the performance of GHC's current generational / compa

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 proble

Re: Array optimisation...

On Mon, 23 Feb 2004, MR K P SCHUPKE wrote: > > 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 constr

Array optimisation...

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

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 *n

RE: optimization question

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 gene