4 ms·

Idiomatic Clojure tends to use Clojure's persistent data structures - you don't often create custom types, all of the core functions on those data structures ar

Idiomatic Clojure tends to use Clojure's persistent data structures - you don't often create custom types, all of the core functions on those data structures are already pretty much as fast as possible. No need for ^:static or type decls. The article also doesn't get into deftype/defrecord/protocols. In those cases you always get the fastest path of the platform. Again you can build things that have the same perf of the core data structures w/o resorting to ^:static or type decls. So what exactly do you mean again by arbitrary code? Perhaps you meant numeric code - there ^:static and type decls help plenty. Perhaps you mean Java interop? Again sure. Personally I think Clojure is really taking the dynamic, generic, and fast thing to a whole new level, w/o type-hinting of any kind. EDIT: This isn't too say Clojure performance can't continue to improve. Scala's ability to use Java arrays of primitives in higher order operations is something I really, really want to see (and the the above is a big chunk of the work in that direction)

jules 16y ago
It's strange that you mention Clojure's persistent data structures as an advantage for performance. They have many advantages but performance isn't one of them.
- swannodette 16y ago
  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.
  - lukev 16y ago
    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 because it's the fastest thing possible. Java itself is far from the fastest thing possible, and the speed of Java is itself a strict upper bound on Clojure's speed.
    - swannodette 16y ago
      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 eventually approaches some kind of wacky manual memory management scheme to preserve performance w/o sacrificing correctness. I think Clojure's solution is a step in the right direction. But no, if I was writing a real-time system with extremely limited memory constraints I would not write in the Clojure. But I don't think that's what this thread is about.
      - lukev 16y ago
        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.
    - johnaspden 16y ago
      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-machine-code.html 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!).
  - sreque 16y ago
    It's threads like this that make the Clojure community really irk me sometimes. It's ok to think your language is great, but please take a reality check before you go off and try to defend it against criticism! Judging by your comments, especially this fuzzy little one about elegant design, I would guess that you've spent very little time dealing with actual CPU and memory-related performance issues.
    - edifice 16y ago
      It's not just me then.

jules 16y ago

It's strange that you mention Clojure's persistent data structures as an advantage for performance. They have many advantages but performance isn't one of them.

swannodette 16y ago
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.
- lukev 16y ago
  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 because it's the fastest thing possible. Java itself is far from the fastest thing possible, and the speed of Java is itself a strict upper bound on Clojure's speed.
  - swannodette 16y ago
    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 eventually approaches some kind of wacky manual memory management scheme to preserve performance w/o sacrificing correctness. I think Clojure's solution is a step in the right direction. But no, if I was writing a real-time system with extremely limited memory constraints I would not write in the Clojure. But I don't think that's what this thread is about.
    - lukev 16y ago
      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.
  - johnaspden 16y ago
    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-machine-code.html 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!).
- sreque 16y ago
  It's threads like this that make the Clojure community really irk me sometimes. It's ok to think your language is great, but please take a reality check before you go off and try to defend it against criticism! Judging by your comments, especially this fuzzy little one about elegant design, I would guess that you've spent very little time dealing with actual CPU and memory-related performance issues.
  - edifice 16y ago
    It's not just me then.