
Clojure++ (notes from Rich Hickey talk) - puredanger
http://combinate.us/clojure/2010/09/27/clojure/
======
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.

~~~
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?

~~~
SeanLuke
> We arn't the kawa guys faster after a decade.

Kawa _guy_. Kawa was written by a single person, Per Bother, in his spare
time. Clojure has a massively larger mindshare and collection of coders behind
it. Ask yourself: why has Clojure been so slow for so long?

> Clojure is faster in other stoff like interop witch is really importend on
> the JVM.

Actually in my experience this is where Clojure is very slow indeed. If
Clojure has to convert everything to Refs, it gets extremely slow (in our
tests on my simulation system, up to 1000x slower than Kawa. I am not making
up that number.).

> Can Kawa write down-to-java speed types?

Absolutely.

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

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

~~~
puredanger
Isn't "sexy enough" Clojure's motto?

------
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?

~~~
lmkg
(swap! clojure inc) is acceptable and a more literal translation, although
refactoring your code to use (inc clojure) is usually more idiomatic.

See also, ADD 1 TO COBOL GIVING COBOL.

~~~
djacobs
My point was not to translate the method name, it was to point out that (++)
is anti-Clojure. I wanted to refactor the title to avoid mutability. I.e.,
"return the increment of clojure", not "change the value of clojure".

------
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.

~~~
herdrick
That Clojure's target is to replace slow old Ruby (actually that never
happens, rather a successful language gains dominance in some niche and
spreads from there) is only more evidence that it isn't worth breaking the
abstraction called "numbers" to get merely an order of magnitude better
performance. Seriously, I almost can't believe this is still an open issue in
2010. And Rich Hickey, who has designed such a great language otherwise, is on
the wrong side of it? I'm boggled.

EDIT: If peregrine's comment is right, then we're arguing about something that
isn't happening. I hope so.

~~~
prospero
_Clojure's target is to replace slow old Ruby_

That is very clearly the opposite of what I wrote.

~~~
herdrick
Oh, sorry! I transposed the words.

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

