3 ms·

Regarding speed, you really need to read this essay that John Lawrence Aspden wrote, "Clojure Faster than Machine Code?" He walks through several experiments in

Regarding speed, you really need to read this essay that John Lawrence Aspden wrote, "Clojure Faster than Machine Code?" He walks through several experiments in which he figures out how to optimize Clojure for the JVM. Finally, he writes a macro that expands his code into code that adds type hints to all of the vars, and with the help of the type hints the JVM goes blazing fast. He concludes: " And so I wonder: This technique strikes me as very general, and very useful. All sorts of things can be represented as lookups in tables. This whole program took me one short day to write, and the whole time I was doing things that I've never done before, just going by intuition. Once you've got the hang of it, it's easy. I think that the program should be as fast as the equivalent java program would be, although I haven't got around to actually testing that, so I may have dropped the ball somewhere. In any case, it's probably possible to generate code like this that does run as fast as whatever the fastest Java implementation actually is. The JVM is widely thought to be around the same speed as native machine code or optimized C. I'm absolutely sure that I'm not able to write the equivalent program in Java, C, or assembler without code-generation. The code generation would be very very very much harder in Java, C or assembler. And so I wonder, is Clojure the fastest computer language in the world?" http://www.learningclojure.com/2010/09/clojure-faster-than-machine-code.html http://www.learningclojure.com/2010/09/clojure-faster-than-m...

CJefferson 14y ago
Fast compared to what? He doesn't benchmark against anything other than his own slow Clojure code. I see no evidence at all that this wouldn't be beaten by a simple plain Java implementation.
- Jach 14y ago
  This is a not-uncommon feeling for Lisp-like languages, and if you want a benchmark on a particular problem I'll point to http://shootout.alioth.debian.org/u64q/benchmark.php?test=fannkuchredux&lang=all http://shootout.alioth.debian.org/u64q/benchmark.php?test=fa... where the "alternative" Common Lisp program is the fastest. (Just ahead of a Java 7 program.) Why does the feeling persist? Because there's a lot of anecdotes and personal experience by lispers who have created something they didn't think they could do in another language "from scratch". I'll offer a link to a different anecdote: http://www.cs.indiana.edu/~jsobel/c455-c511.updated.txt http://www.cs.indiana.edu/~jsobel/c455-c511.updated.txt "Is Scheme Faster than C?" Here are the highlights, with the most important quote at the end. …One of the assignments in the Algorithms course was a major term project in which we were to implement and optimize the Fast Multiplication algorithm. Fast Multiplication is a recursive "divide-and-conquer" algorithm for multiplying two numbers, especially large numbers: hundreds or thousands of digits.…Part of our grade for this project was based on how fast the program ran. …What I noticed was that each of those three recursive calls had nearly the same control context. In a simple-minded implementation in C, that context would be saved and restored three times, being destroyed after the return of each call. I thought to myself: If only I had explicit control over the flow of my program, I could speed it up significantly by creating that context only once and using it three times, destroying it only after the return of the third recursive call. Function calls are so costly! But I would never want to attempt such a thing from scratch in C. …Furthermore, I could start with a simpler, more naive program and basically DERIVE the sophisticated one through a series of correctness-preserving program transformations. This is where Scheme really won. Because of its extremely algorithmic---almost mathematical---nature, Scheme can be easily manipulated in a sort of algebraic style. One can follow a series of rewrite rules (just about blindly) to transform a program into another form with some desirable property. This was exactly what I needed. …I had never had the courage to use a "goto" in C before; it was just too dangerous a tool. It was kind of fun to use them now, knowing that I was completely safe in doing so. That was the amazing part: I had PRODUCED a program that I could not have WRITTEN, and would not have wanted to write directly, for that matter. …"But does it run fast?" Speed was, after all, my main goal. The answer is a very resounding "Yes!" Out of a class of about 15 students, only one person beat me (and only barely), and he wrote significant portions of his program directly in Assembly Language. …Real efficiency comes from elegant solutions, not optimized programs. Optimization is always just a few correctness-preserving transformations away. Lisp-like languages make correctness-preserving transformations easy with their homogeneous syntax and accompanying macros. It may be that a simple Java implementation of the GP's example would be faster, I'd like to see a benchmark too, but charged with the task of making each one faster relative to itself, I know I'd rather work with the Clojure code because it's easier to transform. Compared to this http://mechanical-sympathy.blogspot.com/2012/07/native-cc-like-performance-for-java.html http://mechanical-sympathy.blogspot.com/2012/07/native-cc-li... on the problem of object serialization, getting really fast Java takes a lot of work whereas getting pretty fast Clojure takes a lot less work (if the parent post is to be considered a "pretty fast" implementation of the particular data processing problem).

CJefferson 14y ago

Fast compared to what? He doesn't benchmark against anything other than his own slow Clojure code. I see no evidence at all that this wouldn't be beaten by a simple plain Java implementation.

Jach 14y ago
This is a not-uncommon feeling for Lisp-like languages, and if you want a benchmark on a particular problem I'll point to http://shootout.alioth.debian.org/u64q/benchmark.php?test=fannkuchredux&lang=all http://shootout.alioth.debian.org/u64q/benchmark.php?test=fa... where the "alternative" Common Lisp program is the fastest. (Just ahead of a Java 7 program.) Why does the feeling persist? Because there's a lot of anecdotes and personal experience by lispers who have created something they didn't think they could do in another language "from scratch". I'll offer a link to a different anecdote: http://www.cs.indiana.edu/~jsobel/c455-c511.updated.txt http://www.cs.indiana.edu/~jsobel/c455-c511.updated.txt "Is Scheme Faster than C?" Here are the highlights, with the most important quote at the end. …One of the assignments in the Algorithms course was a major term project in which we were to implement and optimize the Fast Multiplication algorithm. Fast Multiplication is a recursive "divide-and-conquer" algorithm for multiplying two numbers, especially large numbers: hundreds or thousands of digits.…Part of our grade for this project was based on how fast the program ran. …What I noticed was that each of those three recursive calls had nearly the same control context. In a simple-minded implementation in C, that context would be saved and restored three times, being destroyed after the return of each call. I thought to myself: If only I had explicit control over the flow of my program, I could speed it up significantly by creating that context only once and using it three times, destroying it only after the return of the third recursive call. Function calls are so costly! But I would never want to attempt such a thing from scratch in C. …Furthermore, I could start with a simpler, more naive program and basically DERIVE the sophisticated one through a series of correctness-preserving program transformations. This is where Scheme really won. Because of its extremely algorithmic---almost mathematical---nature, Scheme can be easily manipulated in a sort of algebraic style. One can follow a series of rewrite rules (just about blindly) to transform a program into another form with some desirable property. This was exactly what I needed. …I had never had the courage to use a "goto" in C before; it was just too dangerous a tool. It was kind of fun to use them now, knowing that I was completely safe in doing so. That was the amazing part: I had PRODUCED a program that I could not have WRITTEN, and would not have wanted to write directly, for that matter. …"But does it run fast?" Speed was, after all, my main goal. The answer is a very resounding "Yes!" Out of a class of about 15 students, only one person beat me (and only barely), and he wrote significant portions of his program directly in Assembly Language. …Real efficiency comes from elegant solutions, not optimized programs. Optimization is always just a few correctness-preserving transformations away. Lisp-like languages make correctness-preserving transformations easy with their homogeneous syntax and accompanying macros. It may be that a simple Java implementation of the GP's example would be faster, I'd like to see a benchmark too, but charged with the task of making each one faster relative to itself, I know I'd rather work with the Clojure code because it's easier to transform. Compared to this http://mechanical-sympathy.blogspot.com/2012/07/native-cc-like-performance-for-java.html http://mechanical-sympathy.blogspot.com/2012/07/native-cc-li... on the problem of object serialization, getting really fast Java takes a lot of work whereas getting pretty fast Clojure takes a lot less work (if the parent post is to be considered a "pretty fast" implementation of the particular data processing problem).