Clojure number crunching performance

前端 未结 3 976
时光取名叫无心
时光取名叫无心 2020-12-28 16:06

I\'m not sure whether this belongs on StackOverflow or in the Clojure Google group. But the group seems to be busy discussing numeric improvements for Clojure 1.2, so I\'ll

3条回答
  •  不思量自难忘°
    2020-12-28 16:40

    Not a flood of responses here :) but apparently some interest, so I'll try to answer my own question with what I've learned over the past few days:

    • With the 1.1 optimization approach (Java primitives and mutable arrays) ~4x slower than optimized Java is about as fast as it goes.
    • The 1.2 constructs definterface and deftype are more than twice as fast, coming within ~1.7x (+70%) of Java with shorter, simpler and cleaner code than for 1.1.

    Here are the implementations:

    • Clojure 1.1 approach
    • Clojure 1.2 approach

    More details including "lessons learned", JVM version and profiling screenshots.

    Subjectively speaking, optimizing the 1.2 code was a breeze compared to optimizing 1.1, so this is very good news for Clojure number crunching. (Actually close to amazing :)

    The 1.2 testing used the current master branch, I did not try any of the new numeric branches. From what I can gather the new ideas currently being discussed

    • may make non-optimized numerics faster
    • may speed up the 1.1 version of this benchmark
    • will probably not speed up the 1.2 version, it is already as "close to the metal" as it is likely to get.

    Disclaimers:

    • Clojure 1.2 is not released yet, so 1.2 benchmark results are preliminary.
    • This is one particular benchmark on physics calculations. It is relevant to floating point number crunching, but irrelevant to performance in areas like string parsing, concurrency or web request handling.

提交回复
热议问题