From: Bulat Ziganshin <[EMAIL PROTECTED]>
Reply-To: Bulat Ziganshin <[EMAIL PROTECTED]>
To: "Branimir Maksimovic" <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], haskell-cafe@haskell.org
Subject: Re[2]: [Haskell-cafe] Re: Haskell Speed
Date: Fri, 30 Dec 2005 17:56:57 +0300
Hello Branimir,
Friday, December 30, 2005, 3:44:26 AM, you wrote:
BM> myHashString = fromIntegral . ff''' . ff'' . ff' . foldr f 0
i use the following hash function in my program:
filenameHash = fromIntegral . foldl (\h c -> h*37+(ord c)) 0
(it's written without explicit parameter in order to try to help GHC
machinery better optimize this function)
I've found that hasing function and anything that does calculation
is fast enough (compared imported C function and Haskell, and no real
difference,
Haskell is fast regarding calculations)
, problem is with memory leak.
In this case hashing function have to be strong in order to avoid
linear search. when memory leak with HashTable dissapears I will
use some even better hash functions.
BM> All in all functional version consumes less memory and is twice as
BM> fast.
IOArrays is second-class citizens in GHC/Haskell. they are scanned on
_each_ GC, and this can substantially slow down program which uses
large IOArrays.
Hm, there is Hans Boehm GC for C and C++ and I have gcmalloc and
gcmalloc_atomic. Why this isn;t present in Haskel? gcmalloc_atomic is
usefull
when allocating large arrays that does not contain any references/pointers.
for your program, things will be not so bad because IOArray, used inside
your HashTable, contains far less than million elements and
because your program has more to do itself. but try to compare MUT
time of functional and imperative version - may be your algorithm is
really faster and only GC times makes this comparision unfair
Hm that can be solved if hash_table use gcmaloc_atomic I guess.
(If all execution times goes for GC scans).
.. writing this message i thought that reducing number of GCs can
speed up my program and your program too. so there is third variant -
using IOArray, but with "+RTS -A100m"
Wow, that option almost doubled speed of HashTable program (memory leak
remains).
Thank you, for enlighten me about GC. After this I can think of
gc_add_scanrange,gc_remove_scanrange and gcmalloc_atomic
functions as they are now common to other languages?
We need low level GC interface in order to produce fast
programs.
Greetings, Bane.
_________________________________________________________________
Don't just search. Find. Check out the new MSN Search!
http://search.msn.com/
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
