Clojure++ (notes from Rich Hickey talk)

[ataggart]

The changes are pretty substantial when you need them. I wrote a clojure implementation of Base64 that's faster than apache's commons-codec. In 1.2 it was about 5x slower.

[nickik]

In what version of clojure could you write it with the same speed?

[jules]

Couldn't you speed up loops without annotations by compiling two versions: one that uses longs and one that uses bignums. You start in the loop that uses longs and before an operation that can overflow you check whether it overflows and if so you jump to the loop that uses bignums. This way you only suffer a few extra checks which is a lot cheaper than boxed numbers.

[SeanLuke]

Hmmm, Kawa's been doing this for better part of a decade. I tried this in kawa:

    (def (fib n :: <long>) :: <long>
        (if (<= n 1) 1
            (+ (fib (- n 1)) (fib (- n 2))

Almost identical speed results to Rich's "improved" version.

[fogus]

Rich is not trying to improve over Kawa. He's trying to improve over previous versions of Clojure.

[nickik]

We are in Clojure Alpha 1.3 v1 and allready the same speed.

The did it for a dacade and rich does it for a couple months and you bash him? We arn't the kawa guys faster after a decade.

Clojure is faster in other stoff like interop witch is really importend on the JVM. Can Kawa write down-to-java speed types?

[d0m]

But: (defn ^:static fib ^long [^long n]) is really not sexy.

[ataggart]

The performance alternative was dipping into java. It's sexy enough.

[nickik]

its better then optimicing CL. But you write you will only to that if you really need the bare metal performance. I want do that in day to day code.

The ^long thing is pretty cool bettr then : <long> or something. Its nice that it is just metadata.

[rbanffy]

shouldn't it be called (++ clojure) or something like it?

[djacobs]

Or (inc clojure) perhaps? Isn't (++) an abomination in functional programming with immutable state?

[tvachon]

I guess the right thing to do would be to claim I was being ironic here, but really, it was just a poorly thought out late night titling decision.

If I could do it again, I'd go with (inc clojure), as below.

[nickik]

thats not the officale name. Its just clojure 1.3. The author choisse the name because of the groofy++ thing.

[herdrick]

"... most numeric functions in Clojure, will no longer auto-promote values to Big numbers..."

Oh no! Clojure is choosing the route of premature opt. What a terrible shame.

[prospero]

I was at the talk in question. Some more context:

Bignums "contaminate" surrounding operations. Adding a long and a bignum yields a bignum. Seeding an equation with a single bignum (42N is a bignum representation of 42) will prevent overflow.

No one has come forward with a single real-world scenario where they're using bignums in Clojure. Choosing a default that is only theoretically useful rather than a 10x performance improvement seems a bit silly.

In any situation where the compiler cannot be sure you're using primitives everywhere, it will emit non-overflowing bytecode.

By my measure, there's nothing premature about this optimization. In Rich Hickey's words, Clojure is a replacement for Java, not Ruby. Giving up Java-like performance makes the language quantitatively less useful.

[swannodette]

Premature? No people have been complaining (or just getting very confused) about Clojure's numeric performance without oodles of invasive type-hinting for two years now.

More importantly with these changes it's now possible to reimplement Clojure's core datastructures in Clojure without sacrificing performance.

The majority of people who care about BigInts are solving Project Euler problems, not writing Clojure libraries or deploying apps into production.

[peregrine]

This is only true if you use the annotations, at least that is my understanding.

[c00p3r]

We don't need Scheme++ to implement .... (c) Brian Harvey, a famous CS61A teacher. ^_^