5 ms·

Performance in Factor, Java, and Clojure

26 points by prospero 17y ago

chrisduesing 17y ago
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?
- apotheon 17y ago
  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.
- prospero 17y ago
  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/Performance/Conceptual/OpenCL_MacProgGuide/Example:Hello,World/Example:Hello,World.html 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.
  - plinkplonk 17y ago
    "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).
    - prospero 17y ago
      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.
      - plinkplonk 17y ago
        " 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.
        prospero 17y ago
        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.
- yangyang 17y ago
  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.
itistoday 17y ago
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?
- prospero 17y ago
  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?
  - itistoday 17y ago
    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.
    - prospero 17y ago
      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.
      - itistoday 17y ago
        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!
yangyang 17y ago
Misleading title - it should definitely include the fact that the clojure implementation was GPU based.

26 points by prospero 17y ago

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?

apotheon 17y ago
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.
prospero 17y ago
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/Performance/Conceptual/OpenCL_MacProgGuide/Example:Hello,World/Example:Hello,World.html 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.
- plinkplonk 17y ago
  "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).
  - prospero 17y ago
    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.
    - plinkplonk 17y ago
      " 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.
      - prospero 17y ago
        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.
yangyang 17y ago
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.

itistoday 17y ago

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?

prospero 17y ago
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?
- itistoday 17y ago
  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.
  - prospero 17y ago
    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.
    - itistoday 17y ago
      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!

yangyang 17y ago

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