Performance in Factor, Java, and Clojure | Hacker News Reader

Performance in Factor, Java, and Clojure

ideolalia.com

26 pointsprospero16 comments

Clojure "beating" Java performance seems like an odd claim, since they both compile to the same thing. Doesn't that simply imply the approach/algorithm is better?

I suppose it's possible that it implies Clojure idioms encourage better algorithm design. I'm afraid I don't know enough about Clojure to evaluate the value of my hypothesis, though.

The difference in performance is because the Clojure code is targeting the GPU rather than the CPU. This generally results in a faster, but more verbose solution (see this "hello world" in OpenCL: http://developer.apple.com/mac/library/documentation/Perform...).

However, the defmap and defreduce macros in the snippet abstract away all that boilerplate, resulting in something that is both significantly faster than the standard approach, and significantly more concise. The Factor vs. Java benchmark seemed like a decent way to demonstrate that.

"The difference in performance is because the Clojure code is targeting the GPU rather than the CPU."

In that case wouldn't a fairer comparison be between java code that targets the GPU and factor code that also targets the GPU. Right now its seems that the only valid conclusions is code that targets the GPU is better than code that targets the CPU (for certain kinds of tasks).

I mentioned in the post that it wasn't an apples to apples comparison.

That being said, I think that ease of development is a more practical metric for comparison than the underlying methods. Clojure lends itself to translation into GLSL, which has useful vector functionality, so it ends up being simpler and more concise to target the GPU than it would be to write it in plain Clojure. You could certainly use the GPU in other languages and achieve equal or better performance, but in the vast majority of cases it would not be the path of least resistance.

" Clojure lends itself to translation into GLSL, "

How so more than factor? Factor (like Forth) is just a set of words and it is easy to conceive of a GLSL vocabulary for it(I use "vocabulary" in the Forth/Factor sense).

How is "10 sq 5 - ." (Factor/Forth) "less translatable" than "(- (square 10) 5)" [Clojure/lisp]?

" You could certainly use the GPU in other languages and achieve equal or better performance, but in the vast majority of cases it would not be the path of least resistance."

Well here we aren't talking of most cases ( :-) )but specifically Factor vs Clojure. I hope you take the time to explain why you think Clojure is superior to Factor in this respect (if that is the point you were making). Comparing metrics of languages compiling to different chips make little sense.

Comparing Clojure compiling to the GPU and Factor compiling to the CPU makes as much sense as comparing Clojure compiling to Intel and Factor comparing to something entirely different (say the ARM). Specific tasks will be faster on one or the other. So what? Two things differ(the language being compiled and the compiled to chip) making any "comparisons", at best dubious.

As far as I understand it, Factor has a regular grammar and macros, so I don't see any reason why it couldn't do exactly what I've done here with Clojure.

My comment above was referring more to Java, which is generally considered to be the apex of potential performance for Clojure, but which would completely incapable of something like this. I didn't mean to lump Factor and Java together, sorry for the imprecision.

"My comment above was referring more to Java, which is generally considered to be the apex of potential performance for Clojure, but which would completely incapable of something like this."

Ok, No arguments then, if the expressiveness, succinctness and malleability of java vs Clojure were the point of comparison. Factor vs Clojure would be a dead heat I imagine.

The original article makes the statement

" That's 4x faster than the optimized Factor code, and more than 10x faster than Java."

I was saying this comparison is not only meaningless but misleading. The statements should be something like

"The Clojure code (which compiles to the GPU) is 4x faster than the optimized Factor code (which compiles to the CPU) , and more than 10x faster than Java(which compiles to the CPU). GPUs and CPUs make different speed tradeoffs so the above is meaningless btw "

For language speed comparisons to be (somewhat) meaningful, they should have a common baseline environment. If each language compiles to a different type of chip (GPU vs CPU in this case) there is no valid "comparison".

Ignoring the fact that, as mentioned elsewhere this comparison is not like-for-like, clojure and java won't compile to precisely the same thing. Much like common lisp and C++ compilers targeting x86 won't compile code doing the same thing to exactly the same instructions (I know the JVM JIT means this isn't really fair comparison, but the basic point holds). The runtimes are completely different, too.

Misleading title - it should definitely include the fact that the clojure implementation was GPU based.

Wondering if maybe someone familiar with penumbra could explain to me why on earth they chose to go with JOGL instead of LWJGL. Doesn't the latter have far more activity going on with it?

I chose the one that seemed closer to vanilla OpenGL, because that's all I really wanted. I don't claim to be an expert, though. What would LWJGL give me that JOGL doesn't?

I'm not an expert either, but a while back I spent over a year looking into the whole Java OpenGL gaming thing. I started out working with the Xith3D library and made some contributions to it, but soon it became painfully clear that the best 3D library for Java was jMonkeyEngine, and it used lwjgl.

Looking further into it I think I found that JOGL seemed to be a somewhat abandoned project (sortof like Java3D), and that the real action was with LWJGL/jMonkeyEngine. Both had a far larger and more active community, and LWJGL supported more OpenGL features, and LWJGL may have been faster than JOGL too, although again, you're bringing up a fairly old memories, so I can't say they're perfectly accurate, I may in fact be spewing nonsense.

I'd say take a look at both and compare.

Thanks for the suggestion, I'll look into it further. The code that binds Penumbra to JOGL is pretty small, so it would be easy to swap something else in if it seems clearly superior.

Great! Thanks for considering it, and if it's that easy then Penumbra would be even more appealing for supporting both. I'm hoping to get back into the Java world through Clojure, so I'm very happy to see that a project like Penumbra is there!

From what I can tell, JOGL is preferable in at least one situation: Applets. Since the code is signed by Sun, it's a lot less hassle to run it in a browser than if you had to get hold of signatures yourself. Might be something worth bearing in mind.

Reply on news.ycombinator.com