Excerpts from Michał Marczyk's message of Tue Feb 23 12:09:15 -0500 2010: > Haskell's IntMap performs no hashing, but also doesn't allow non-Int > keys. It stands to reason it would be very fast at the cost of a > decrease in utility.
This is an oversight in the test harness. I went and made the test code hash the integers before inserting them. Since the hashes are, internally, 32-bit or 64-bit integers, I don't really see any reason why IntMap couldn't be "genericized" for general use; you'd just have to make sure you has a hash function for your key data type! > By the way, I don't view this as a Haskell vs Clojure contest (GHC, > native code vs HotSpot, JVM), but rather one of data structures. That is my hope! But unless I have totally misunderstood the algorithm in my Haskell reimplementation (which is quite possible, though I have reviewed it several times), the Haskell version is drastically slower than the Java implementation. It could be the case that GC/Runtime/etc is critical to the performance of the algorithm. > Perhaps the fact that they simply aren't interchangeable (due to > IntMap's type constraint on keys -- as mentioned above, it's always > Ints, not even (Integral a)) makes this a bit pointless (take a HAMT, > add the constraint that keys are all machine word-sized integers and > the problem of hash collisions just doesn't exist and you might be > able to make it faster). I was under the impression that Java hashCode() was also a machine sized integer. Is this not the case? Cheers, Edward -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
