RE: Tree Wars (latest round :-)

On 27 May 2004 17:18, Adrian Hey wrote:
On Wednesday 26 May 2004 10:53 am, Adrian Hey wrote:
I can post the test code to anyone who wants it.
I've put the test code here.. http://homepages.nildram.co.uk/~ahey/HLibs/TreeWars.tar.gz
Interesting, I get pretty much the same results as you, except that DData.Map is now quicker on the lookup test than both FiniteMap and AVL (0.120 vs. 0.134 and 0.138 respectively). I'm not going to investigate this any further, because it'll take forever to get to the bottom of. I think we've arrived at a reasonable conclusion, that the old FiniteMap is definitely superceded but there isn't a clear choice between the others, so we should provide them all. How about the following modules: Data.Map -- a default implementation of maps, eg. DData.Map Data.Map.AVL -- same interface, based on AVL trees Data.Map.Int -- current DData.IntMap Cheers, Simon

--- Simon Marlow
Interesting, I get pretty much the same results as you, except that DData.Map is now quicker on the lookup test than both FiniteMap and AVL (0.120 vs. 0.134 and 0.138 respectively).
Ok, so that means that I should merge in the last change by Daan (and in IntSet too)? (patch in extenso at the end of the message)
I'm not going to investigate this any further, because it'll take forever to get to the bottom of. I think we've arrived at a reasonable conclusion, that the old FiniteMap is definitely superceded but there isn't a clear choice between the others, so we should provide them all.
How about the following modules:
Data.Map -- a default implementation of maps, eg. DData.Map Data.Map.AVL -- same interface, based on AVL trees Data.Map.Int -- current DData.IntMap
DData.IntMap isn't exactly a drop in replacement for DData.Map. It can't have the same interface, if only because the data types are not the same kind. So, I'm not sure it should be treated the same as AVL. Cheers, JP. ---------------------------------------------- hunk ./DData/IntMap.hs 263 + = let nk = natFromInt k in seq nk (lookupN nk t) + +lookupN :: Nat -> IntMap a -> Maybe a +lookupN k t hunk ./DData/IntMap.hs 269 - | nomatch k p m -> Nothing - | zero k m -> lookup k l - | otherwise -> lookup k r + | zeroN k (natFromInt m) -> lookupN k l + | otherwise -> lookupN k r hunk ./DData/IntMap.hs 272 - | (k==kx) -> Just x - | otherwise -> Nothing + | (k == natFromInt kx) -> Just x + | otherwise -> Nothing hunk ./DData/IntMap.hs 1102 +zeroN :: Nat -> Nat -> Bool +zeroN i m = (i .&. m) == 0 + hunk ./Makefile 52 +Test.o : Test.hs +Test.o : ./DData/IntSet.hi } __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

On Friday 28 May 2004 1:59 pm, JP Bernardy wrote:
--- Simon Marlow
wrote: Interesting, I get pretty much the same results as you, except that DData.Map is now quicker on the lookup test than both FiniteMap and AVL (0.120 vs. 0.134 and 0.138 respectively).
Ok, so that means that I should merge in the last change by Daan (and in IntSet too)?
(patch in extenso at the end of the message)
I don't think the DData I was using included this, (I was using the most recent bundled version from your website). Anyway, one thing I just tried to see if specialising AVL for maps would yield significant improvement is to remove the additional level of indirection currently caused by pairs by using AVL trees of Ints. Basically this means using the original test code and replacing.. pushKey,delKey,tryRead with.. push,del,contains I got these results for 500,000 random elements Insert Lookup Delete Data.Tree.AVL 0.756 0.155 0.763 Vs. originals 0.923 0.203 0.798 So it does look as though specialising AVL for maps (and maybe even IntMaps) would yield significant performance improvements. I don't propose to do this at this stage though, as the basic AVL library isn't finished yet. Regards -- Adrian Hey
participants (3)
-
Adrian Hey
-
JP Bernardy
-
Simon Marlow