Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There are a few things wrong with this benchmark. In Lush, he's measuring the time it takes to sum 3 million pre-computed random numbers. In Clojure, he's measuring the time it takes to generate 3 million random numbers, and then sum them.

It also looks like he's using two different data structures. In Clojure, its a lazily generated linked list of objects; in Lush, it appears as if he's using a vector pre-initiated to the right size.

He also doesn't mention which versions of Clojure and Lush he's using, or how much memory Lush uses. He complains that a JVM with a 130M is too small, but the 30 million long array in Lush would have been almost twice that size if it was populated with 64-bit doubles.

For reference, it takes me 571ms to run the 300 thousand number example that took him 861ms. If I factor out the random-number generation from the Clojure benchmark, it cuts the time down to 120ms.

If then I use a pre-generated fast array and the specialized areduce function (to match his specialized idx-sum function), I get 16ms for 300k, 22ms for 3m and 230ms for 30m.

So performance is on par with Lush, so long as you compare like for like.



"The point is, Lush has datatypes for fast numerics: it’s designed to do fast numerics. Clojure doesn’t have such datatypes..."

He knows he's not comparing like for like. What he apparently doesn't know is that there is a better data type.


Whats the better datatype? I'm looking at doing some numeric programming and I wondered about Clojure for this.


If your aim is raw speed, not a lot beats a standard JVM array.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: