Thanks Andy for the insightful report! I knew you and others have worked
hard on the benchmarks so this kind of analysis is very helpful.
Thanks for all your work on them,
Ben
On 8/28/12 12:07 AM, Andy Fingerhut wrote:
I've written several of the Clojure programs on the site. I'm not
omniscient when it comes to writing efficient Clojure code, but I know
a few of the techniques. Several, if not most, of the Clojure
solutions already take advantage of mutable data structures, for example.
There are some faster programs people have created for a few of the
problems, but they haven't been submitted yet, due to lack of
time/interest. I might get some of them submitted over the next
several weeks.
I suspect the average ratio of <Clojure run time> / <Java run time>
can be brought closer to the range of x1 through x5 or so, rather than
the current range of x2 through x12. It used to be in the range of x1
to x8 or so, but over the last year the Java program submissions have
gotten faster while the Clojure ones haven't been improved, or not as
much. Getting x1 or even x2 across all problems seems highly unlikely
to me, but I'd be happy to be proved wrong.
It is true that a few of the problems have very short run times for
the Java programs that extra Clojure init time makes it difficult for
them to compete (e.g. best Java run times for reverse-complement and
fasta-redux problems are under 2 sec), but half of them take over 20
sec to complete using the Java programs, which should give both Java
and Clojure programs plenty of time for JIT optimizations to take
effect. The remaining differences are either differences in the
algorithm or data structure in use, and/or the efficiency of the
resulting byte codes from Java and Clojure compilers.
As for memory used, "Hello, world" takes about 60 to 70 Mbytes of
resident memory to complete, so no Clojure program will be below that.
If you want thousands of separate JVMs running Clojure processes,
each with a small memory footprint, I wouldn't recommend it, but I
doubt anyone would want to do that. It is more fair to compare memory
use for problems that require a larger amount of memory, e.g.
reverse-complement, k-nucleotide (for which the Clojure memory
footprint can probably be reduced without a lot of effort), regex-dna,
and binary-trees problems.
Andy
On Aug 27, 2012, at 6:58 PM, Ben Mabey wrote:
Looking at clojure's benchmarks they seem to already be highly
optimized (in terms of employing all the standard tricks). Does
anyone have any idea if more could be done to lessen the gap between
java and clojure[1]? Or are these benchmarks representative of the
performance gap between clojure and java for these types of problems?
-Ben
1.
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=clojure&lang2=java
On 8/26/12 8:07 AM, David Nolen wrote:
I haven't found this to be the case. Java fares pretty well on Alioth.
On Saturday, August 25, 2012, Stuart Sierra wrote:
The Alioth benchmarks are somewhat unfair to JVM languages
because they include startup time for the JVM itself and often
don't run enough iterations to engage the optimizer.
-S
On Sat, Aug 25, 2012 at 1:51 PM, Raymond de Lacaze
<del...@hotmail.com> wrote:
> Here’s a performance benchmark comparison of SBCL and
Clojure.
>
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=clojure&lang2=sbcl
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
<javascript:_e({},%20'cvml',%20'clojure@googlegroups.com');>
Note that posts from new members are moderated - please be
patient with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
<javascript:_e({},%20'cvml',%20%20%20%20%20%20%20%20%20%20'clojure%2bunsubscr...@googlegroups.com');>
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
<mailto:clojure@googlegroups.com>
Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
<mailto:clojure+unsubscr...@googlegroups.com>
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
