Re: A Performance Comparison of SBCL Clojure
Since my last message, I personally have only submitted a new faster Clojure program for the knucleotide problem on the Benchmarks Game site. I haven't checked whether other Clojure programs have been submitted in that time. For all of the benchmark machines below, I'd say don't worry about the pidigits problem. It is kind of an odd case. The Clojure program does not use the GNU gmp library for arbitrary precision integer arithmetic, but the Java program and several other languages do. You can stress out about that fact if you want. I don't. Life is too short. That problem simply shows the difference between Java BigInteger performance versus the GNU gmp library performance, not Clojure vs. Java. The rest of the problems I consider reasonably fair comparisons, although I'd bet money the Clojure run time of several can still be reduced with enough skill and persistence. Some day I'd like to have side by side performance comparisons of these programs versus the easier-to-write kind that someone is more likely to come up with on a first or second try, rather than the tweaked-out oddities of programs on the site. In a few months, perhaps. 32-bit 1 core Clojure vs. Java: http://shootout.alioth.debian.org/u32/benchmark.php?test=alllang=clojurelang2=java Only 2 problems (other than pidigits) have Clojure worse than 4x the Java time. I don't know why reverse-complement and fasta-redux are so bad relative to the Java programs, because the exact same programs are at most 4x slower on the 64-bit benchmark machines. Something weird performance-wise about those programs on 32-bit machines. 32-bit 4 core: http://shootout.alioth.debian.org/u32q/benchmark.php?test=alllang=clojure Only 3 problems (other than pidigits) worse than 4x the Java time. reverse-complement and fasta-redux have the same weird 32-bit performance weirdness as mentioned above, whatever that may be. fannkuch-redux is 5x the Java run time. 64-bit 1 core: http://shootout.alioth.debian.org/u64/benchmark.php?test=alllang=clojure 64-bit 4 core: http://shootout.alioth.debian.org/u64q/benchmark.php?test=alllang=clojure All Clojure programs within 4x the run time of the corresponding Java programs, averaging around 2.5x the run time of Java. Lesson I've learned: If you've got an inner loop of your program that you really really need to run faster, code it in Java, C, or even assembler. Use profiling tools to find those spots, rather than guessing where you think they might be. Hand-coded assembler can beat optimized C by a factor of 2 or more in many cases, but who wants to program in assembler? For that matter, who wants to write large programs in C? Andy On Aug 28, 2012, at 7:02 AM, Ben Mabey wrote: 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.
Re: A Performance Comparison of SBCL Clojure
On Friday, September 7, 2012 1:12:44 AM UTC-7, Andy Fingerhut wrote: Since my last message, I personally have only submitted a new faster Clojure program for the knucleotide problem on the Benchmarks Game site. I haven't checked whether other Clojure programs have been submitted in that time. Thanks Andy (and yes, yours was the only Clojure program contributed during that time). For all of the benchmark machines below, I'd say don't worry about the pidigits problem. It is kind of an odd case. The Clojure program does not use the GNU gmp library for arbitrary precision integer arithmetic, but the Java program and several other languages do. You can stress out about that fact if you want. I don't. Life is too short. That problem simply shows the difference between Java BigInteger performance versus the GNU gmp library performance, not Clojure vs. Java. Until someone contributes a Clojure program that makes use of that Java interface to GMP ;-) The rest of the problems I consider reasonably fair comparisons, although I'd bet money the Clojure run time of several can still be reduced with enough skill and persistence. Some day I'd like to have side by side performance comparisons of these programs versus the easier-to-write kind that someone is more likely to come up with on a first or second try, rather than the tweaked-out oddities of programs on the site. I do understand the appeal of a comparison between easier-to-write first-or-second-try kind of programs -- those programs should be easier to read and easier to understand. Then again, I think it strange to compare the performance of programs written as though performance didn't matter. When performance matters we re-write programs. pi-digits already provides an example -- the utterly naive Java example program (not so much idiomatic as idiotic) I contributed, and the Clojure pidigits programs. http://shootout.alioth.debian.org/u64q/program.php?test=pidigitslang=javaid=1 http://shootout.alioth.debian.org/u64q/program.php?test=pidigitslang=clojureid=2 Lesson I've learned: If you've got an inner loop of your program that you really really need to run faster, code it in Java, C, or even assembler. Use profiling tools to find those spots, rather than guessing where you think they might be. Hand-coded assembler can beat optimized C by a factor of 2 or more in many cases, but who wants to program in assembler? For that matter, who wants to write large programs in C? My guess is that there are plenty of programmers who are happy to write large programs in C ;-) best wishes, Isaac -- 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
Re: A Performance Comparison of SBCL Clojure
Just wanted to say thanks for putting in all the work on the shootout programs, Andy. On Friday, September 7, 2012 1:12:44 AM UTC-7, Andy Fingerhut wrote: All Clojure programs within 4x the run time of the corresponding Java programs, averaging around 2.5x the run time of Java. That's pretty darn good. Lesson I've learned: If you've got an inner loop of your program that you really really need to run faster, code it in Java, C, or even assembler. Use profiling tools to find those spots, rather than guessing where you think they might be. Agreed. -S -- 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
Re: A Performance Comparison of SBCL Clojure
+1 -- Andy, thanks. On Friday, September 7, 2012 at 11:32 AM, Stuart Sierra wrote: Just wanted to say thanks for putting in all the work on the shootout programs, Andy. On Friday, September 7, 2012 1:12:44 AM UTC-7, Andy Fingerhut wrote: All Clojure programs within 4x the run time of the corresponding Java programs, averaging around 2.5x the run time of Java. That's pretty darn good. Lesson I've learned: If you've got an inner loop of your program that you really really need to run faster, code it in Java, C, or even assembler. Use profiling tools to find those spots, rather than guessing where you think they might be. Agreed. -S -- 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
Re: A Performance Comparison of SBCL Clojure
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=alllang=clojurelang2=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=alllang=clojurelang2=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 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 -- 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
Re: A Performance Comparison of SBCL Clojure
Yes. Look at test.benchmark. Java is the baseline there. We don't accept
Clojure versions that are not competitive.
On Monday, August 27, 2012, 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=alllang=clojurelang2=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=alllang=clojurelang2=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
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.comjavascript:_e({}, 'cvml',
'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({}, 'cvml',
'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.comjavascript:_e({}, 'cvml',
'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({}, 'cvml',
'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
Re: A Performance Comparison of SBCL Clojure
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=alllang=clojurelang2=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=alllang=clojurelang2=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
Re: A Performance Comparison of SBCL Clojure
Maybe my impressions are out of date. Personally, I have neither the time nor the interest, but optimizers do your stuff! -S -- 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
Re: A Performance Comparison of SBCL Clojure
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=alllang=clojurelang2=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=alllang=clojurelang2=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({}, 'cvml', '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({}, 'cvml',
'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
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
Re: A Performance Comparison of SBCL Clojure
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=**
alllang=clojurelang2=sbclhttp://shootout.alioth.debian.org/u32/benchmark.php?test=alllang=clojurelang2=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.comjavascript:_e({}, 'cvml',
'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({}, 'cvml',
'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
Re: A Performance Comparison of SBCL Clojure
On Sun, Aug 26, 2012 at 3:07 PM, David Nolen dnolen.li...@gmail.com wrote: I haven't found this to be the case. Java fares pretty well on Alioth. http://shootout.alioth.debian.org/help.php#java Shows that it does not change much on programs that run for mor than a few seconds. -- 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
Re: A Performance Comparison of SBCL Clojure
Hello Ray, Just a factor of 3 slower is pretty good :-) The increased memory use is more disturbing to me since I often use Clojure+Noir for deploying small web services and web apps. The extra memory is more of a hassle than slightly slower execution speed. Best regards, Mark On Sat, Aug 25, 2012 at 1:51 PM, Raymond de Lacaze dela...@hotmail.com wrote: Folks, Here’s a performance benchmark comparison of SBCL and Clojure. http://shootout.alioth.debian.org/u32/benchmark.php?test=alllang=clojurelang2=sbcl Interesting… --rpl Raymond Pierre de Lacaze dela...@hotmail.com -- Mark Watson, consultant and author: http://markwatson.com It is better to travel well than to arrive. - Buddha -- 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
Re: A Performance Comparison of SBCL Clojure
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.comjavascript: wrote: Here’s a performance benchmark comparison of SBCL and Clojure. http://shootout.alioth.debian.org/u32/benchmark.php?test=alllang=clojurelang2=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 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
