Clojure 1.3 First Impression (It's Fast) • Hacker News Board

Re: Clojure 1.3 First Impression (It's Fast)

#21

Post by lukev » Thu, Sep 30, 2010, 2:56 PM UTC

swannodette wrote: post #20

lukev wrote: post #16

Earlier quoted context omitted.

If you're going for raw speed you should use mutable data structures. Sadly, that's just the way it is - you can update a mutable data structure in a couple of instructions by swapping out a pointer, while "updating" an immutable/persistent object is inherently more work at the machine level. Clojure is awesome because it provides immutable persistent structures that are well onto the good side of "good enough", not…

Sure, but of course if you want raw speed you would write assembly. Most people move up the food chain to C to get some basic level of correctness. I think the history of production oriented PLs has revolved around balancing correctness/performance. And it's always a question of diminishing return (I've written enough C/C++/Objective-C++ to know this). Every sizeable application I've written in a lower level language…

There is a large class of problems that aren't worth writing in assembly but for which Clojure is (currently) still too slow.

Sometimes you just need something at Java's (or preferably Scala's) position on the power/performance spectrum.

That said, the way Clojure is improving, I think it will continue to asymptotically approach Java's speed anyway.

Re: Clojure 1.3 First Impression (It's Fast)

#22

Post by johnaspden » Thu, Sep 30, 2010, 4:23 PM UTC

lukev wrote: post #16

swannodette wrote: post #15

Earlier quoted context omitted.

I'm curious how you come to this conclusion? Programs in any language will often be designed around immutability in order to improve code maintainability. Without fast persistent data structures this will most certainly decrease the performance of your otherwise elegant design due to considerable amounts of copying.

If you're going for raw speed you should use mutable data structures. Sadly, that's just the way it is - you can update a mutable data structure in a couple of instructions by swapping out a pointer, while "updating" an immutable/persistent object is inherently more work at the machine level. Clojure is awesome because it provides immutable persistent structures that are well onto the good side of "good enough", not…

Being a sometime embedded man myself, I was nodding sagely at your comment until this bit: "Java itself is far from the fastest thing possible, and the speed of Java is itself a strict upper bound on Clojure's speed"

Clojure doesn't compile to Java, it compiles to JVM bytecode, and I think (although I don't know) that that's supposed to be very fast.

In this post:

http://www.learningclojure.com/2010/09/clojure-faster-than-m...

I compiled a (lookup into a map (potentially constructed at run time)) into a series of nested if statements, which then ran very fast indeed.

I shouldn't think I've achieved anything like the holy grail here, it all goes wrong at the end anyway, and I think that clojure 1.3 might actually have broken the optimization techniques I used.

But I think there's a case for saying that an immutable lisp on the JVM might one day be the fastest language in the world, because you can do those sorts of tricks in lisp in a way that you can't feasibly do in assembler, and the JVM does optimization dependent on run-time behaviour, as well as on static analysis.

I don't have the data. I'm not asserting this.

But I am asserting that Java speed is not a strict upper bound on JVM language speed, (unless every JVM bytecode program is also a Java program, which I can't imagine is the case!).

Re: Clojure 1.3 First Impression (It's Fast)

#23

Post by johnaspden » Thu, Sep 30, 2010, 4:30 PM UTC

nickik wrote: post #10

edifice wrote: post #5

Earlier quoted context omitted.

Scala effectively has these kinds of type declarations on every function. This article itself proves the point. Take out the :static and type decls and see.

Of corse scala is fast with stuff like that because its typed. But should we talk about all the stuff you can't do because you have types all the time? I think clojure is getting really close to a dynamic language that can get down to the speed of a static language if you need it.

Yes, let's. You first!

Re: Clojure 1.3 First Impression (It's Fast)

#24

Post by swah » Thu, Sep 30, 2010, 4:37 PM UTC

swah wrote: post #18

johnaspden wrote: post #2

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!

And Ocaml is faster than Ruby!

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.

Re: Clojure 1.3 First Impression (It's Fast)

#25

Post by lukev » Thu, Sep 30, 2010, 5:26 PM UTC

johnaspden wrote: post #22

lukev wrote: post #16

Earlier quoted context omitted.

If you're going for raw speed you should use mutable data structures. Sadly, that's just the way it is - you can update a mutable data structure in a couple of instructions by swapping out a pointer, while "updating" an immutable/persistent object is inherently more work at the machine level. Clojure is awesome because it provides immutable persistent structures that are well onto the good side of "good enough", not…

Being a sometime embedded man myself, I was nodding sagely at your comment until this bit: "Java itself is far from the fastest thing possible, and the speed of Java is itself a strict upper bound on Clojure's speed" Clojure doesn't compile to Java, it compiles to JVM bytecode, and I think (although I don't know) that that's supposed to be very fast. In this post: http://www.learningclojure.com/2010/09/clojure-faster…

You're right, of course. I should have said JVM instead of Java.

That said, in reality, JVM bytecode is tied pretty closely with Java. The bulk of a program: method calls, types, loops, etc all map pretty much 1:1 with what Java emits - there's not a whole lot of room for improvement. And if there were, it would probably be through MORE static typing and compile-time analysis, not less.

I expect that for any arbitrary Clojure program you give me, I can write a Java program that will execute as fast or faster. Of course, it might take me ten times as long to write and have ten times the amount of source code.

Re: Clojure 1.3 First Impression (It's Fast)

#26

Post by lukev » Thu, Sep 30, 2010, 5:35 PM UTC

johnaspden wrote: post #22

lukev wrote: post #16

Earlier quoted context omitted.

If you're going for raw speed you should use mutable data structures. Sadly, that's just the way it is - you can update a mutable data structure in a couple of instructions by swapping out a pointer, while "updating" an immutable/persistent object is inherently more work at the machine level. Clojure is awesome because it provides immutable persistent structures that are well onto the good side of "good enough", not…

Being a sometime embedded man myself, I was nodding sagely at your comment until this bit: "Java itself is far from the fastest thing possible, and the speed of Java is itself a strict upper bound on Clojure's speed" Clojure doesn't compile to Java, it compiles to JVM bytecode, and I think (although I don't know) that that's supposed to be very fast. In this post: http://www.learningclojure.com/2010/09/clojure-faster…

By the way, compiling a data structure to a lookup function is a very clever trick, and fortunately something Clojure makes easy. It reminds me of how old-school assembly programmers would blur the lines between code and data for better performance. Only this is more structured and easier to manage.

There are a couple of drawbacks, though:

1. It really only works for read-only data. Generating a new lookup-fn is a pretty expensive operation. I don't think I could use this for data that changed at all.

2. Compiled code uses permgen space and isn't garbage collected as easily. If you make extensive use of this technique, especially with large maps, it'd be really easy to blow your permgen space.