Aight. Here are the updated benchmarks. Heap size set to 1G by
default, Java run with -server; I also got myself some shiny
statistics machinery in Haskell.
The really short summary: they're... about the same?
Summary:
IntMap Java HAMT (32K-512K) Java HAMT (512K-32K)
32K .0
Excerpts from Michał Marczyk's message of Tue Feb 23 14:54:10 -0500 2010:
> That's a start. Then you'd also have to take care of key collisions.
Yup. As far I can tell, this would be easy, and hopefully not too
much performance problem in the no-collision case with unboxing.
> Incidentally, ther
On 23 February 2010 20:36, Edward Z. Yang wrote:
> 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
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
IBM has this very comprehensive guide on java benchmarking:
http://www.ibm.com/developerworks/java/library/j-benchmark1.html
It is quite long, but there are so many parameters and optimizations
on the JVM that overlooking them is not a real option for a real
benchmark.
Regards,
Daniel
On Feb 23,
Hello!
Excerpts from Rich Hickey's message of Tue Feb 23 09:41:28 -0500 2010:
> Yes, the methodology is wrong, at least on the Clojure/JVM side.
> First, benchmarking anything without -server is a waste of time.
> Second, the JVM does dynamic profile-driven compilation - performance
> on single co
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.
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.
Perhaps th
I'd suggest allocating more heap than the default JVM settings, or
running the JVM in server mode. I'm not sure what Haskell's
underlying implementation is, but I'd assume that it can grow its heap
(somewhat) arbitrarily, which the JVM cannot, beyond a fixed bound.
On Feb 23, 12:51 am, "Edward Z.
Hi,
On Feb 23, 6:51 am, "Edward Z. Yang" wrote:
> (ns maptest (:gen-class))
>
> (defn mk-random-stream []
> (let [r (new ec.util.MersenneTwisterFast)]
> (repeatedly (fn [] (. r (nextInt))
>
> (defn -main [sn]
> (let [n (Integer/parseInt sn)
>
Here's another version that's almost as fast as Rich's and it even includes
the time for computing values.
(defn mk-random-map-fast [n]
(let [m (transient {})
r (new ec.util.MersenneTwisterFast)
ni (. r (nextInt))]
(loop [i 0 result m ni ni]
(if (= i n)
(persist
I'd suggest checking your JVM memory settings. The Haskell
implementation may allow the heap to grow arbitrarily, but the default
JVM heap size is very limited, which may result in poor memory
performance.
On Feb 23, 12:51 am, "Edward Z. Yang" wrote:
> I'd first like to state that I went into th
On Feb 23, 12:51 am, "Edward Z. Yang" wrote:
> I'd first like to state that I went into this exercise expecting
> Bagwell's Hash Array Mapped Tries to blow the competition out of the
> water; I'd get a fast functional map and give it to Haskell and people
> would rejoice.
>
> Instead, I found a
12 matches
Mail list logo
