Clojure 1.3 First Impression (It's Fast)

http://www.learningclojure.com/2010/09/clojure-13-first-impression.html

by johnaspden • 16 years ago

102 25 16 years ago

johnaspden3• 16 years ago

Last time I tried Scala, it blew Clojure out of the water for speed on the program I translated. I assume that Java did too. I think that's probably not true any more.

Anyway, pretty fractal tree program in lisp!

edifice3• 16 years ago

You're still going to find Scala to be significantly faster on arbitrary code. It's great that there are ways to speed up key functions in Clojure now though.

swannodette6• 16 years ago

Backed up by what evidence? And by arbitrary code do you mean code that embraces mutability?

swah2• 16 years ago

And Ocaml is faster than Ruby!

swah2• 16 years ago

I was pointing out that the comparison between Scala and Clojure is between a static language and a dynamic one, the static one will almost always perform better.

whakojacko• 16 years ago

As someone familiar with Java/Scala but not Clojure, what exactly do those type hints do? Just prevent it from autoboxing the primitives? Avoid excessive reflection? Can this be done for other types or just int/long/float/etc?

apgwoz• 16 years ago

It avoids reflection, and instanceof checks.

swannodette6• 16 years ago

type-hinting Java objects to avoid reflection has been possible for some time now. What wasn't possible was for fns to take or return primitives w/o boxing. ^:static lets you do that. ^:static also allows the JVM to apply the most aggressive optimizations to your code - ^:static tells the JVM the code won't change - so callers of ^:static fns won't get the latest version if you redef them. The benefit being that with numeric code you'll often see an order of magnitude performance jump.

So a general strategy is to write your code as you normally would - def'ing redef'ing fns at will. Then when it works - declare the critical paths ^:static, and adding primitive type hints ^long, ^double if the code is numeric.

_delirium• 16 years ago

CMUCL, dealing with a similar infinitely-dynamic problem in Lisp, had a similar approach but dealt with it on a block-of-code level instead of per-function. You could declare a block to be compiled together, and any calls between functions in the block would be treated as having a promise that you'd never redef them without recompiling the whole block, so they could be statically optimized with respect to each other.

Not sure if that's a better or worse approach overall. It probably depends on the structure of your program. One nice feature was that the same function could be static from some perspectives and not from others--- to functions in the same compilation block it was static, but functions from outside that block that called it treated it as non-static, and would immediately get the new version if, say, that whole block were recompiled. That let you make the core code optimized by sticking it in one big compilation block, while not changing the normal dynamic Lisp semantics of the block when viewed from the perspective of any outside function.

nickik2• 16 years ago

The diffrence form Java/Scala is that Clojure dosn't type check (like say typed scheme). Is just for performance.

typhinting to avoid reflection can be done for all java objects. The autoboxing is only for numeric stuff.

Clojure 1.3 First Impression (It's Fast)

Related Stories