Re: Clojure Performance For Expensive Algorithms
On Wednesday, February 27, 2013 2:46:25 PM UTC-8, Ben Mabey wrote: On 2/27/13 9:59 AM, Isaac Gouy wrote: (defn blank? [s] (every? #(Character/isWhitespace %) s)) Have you ever wondered about its performance? No. Why would I wonder about the performance of a one line code snippet that was written without concern for performance? Because that one line of code is representative of the majority of clojure functions (i.e. idiomatic clojure using core functions against seqs). Is that one line of code representative of the majority of Closure programs? Perhaps function composition has implications for program performance. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure Performance For Expensive Algorithms
On Wednesday, February 27, 2013 1:13:10 AM UTC-8, Marko Topolnik wrote: On Wednesday, February 27, 2013 5:19:20 AM UTC+1, Isaac Gouy wrote: If idiomatic Clojure was used... The problem, of course, is that: the code one-person considers to be idiomatic; another person considers to be idiotic, naïve. Not really. Take Stuart Halloway's opening example in the section entitled *Why Clojure?* (defn blank? [s] (every? #(Character/isWhitespace %) s)) Have you ever wondered about its performance? No. Why would I wonder about the performance of a one line code snippet that was written without concern for performance? -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure Performance For Expensive Algorithms
On Wednesday, February 27, 2013 9:48:15 AM UTC-8, Marko Topolnik wrote: However, if someone comes along with *(let [m (HashMap.)] (loop []...(recur (.put m ...)))* claiming that is in fact idomatic, he's just being unreasonable---by everyone's agreement. You don't think there are fast-code idioms? -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure Performance For Expensive Algorithms
On Tuesday, February 26, 2013 12:50:17 PM UTC-8, Marko Topolnik wrote: Again, only the fastest entries are shown. True, except for the special-case included to show that programs can be made slower (and sometimes more concise) -- the shortest C++ programs. If idiomatic Clojure was used... The problem, of course, is that: the code one-person considers to be idiomatic; another person considers to be idiotic, naïve. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure Performance For Expensive Algorithms
On Sunday, February 24, 2013 9:33:52 AM UTC-8, Marko Topolnik wrote: For example, Scala beats Java by a wide margin on some benchmarks. Turns out it's because it uses JNI to solve the problem with the C bignum library. Turns out the benchmarks game website shows both Scala programs and Java programs that use GMP via JNI -- http://benchmarksgame.alioth.debian.org/u32/program.php?test=pidigitslang=javaid=2 http://benchmarksgame.alioth.debian.org/u32/program.php?test=pidigitslang=scalaid=4 -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure Performance For Expensive Algorithms
On Sunday, February 24, 2013 1:45:33 PM UTC-8, Ben Mabey wrote: Yeah, I wish the Benchmarks allowed for idiomatic submissions and finely tuned submissions. So you wish the benchmarks game website would show, for example, both pi-digits programs that use BigInteger and pi-digits programs that use the highly optimised GMP library? http://benchmarksgame.alioth.debian.org/u32/program.php?test=pidigitslang=javaid=1 http://benchmarksgame.alioth.debian.org/u32/program.php?test=pidigitslang=javaid=2 Along those lines this older post did an interesting analysis on the benchmark solutions where it explored the tension that exists between expressiveness and performance across the various languages: http://blog.gmarceau.qc.ca/2009/05/speed-size-and-dependability-of.html Where do you think Guillaume Marceau took the data from? http://benchmarksgame.alioth.debian.org/u32/code-used-time-used-shapes.php -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
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
What changed 1.2/1.3 to cause this program slowdown?
thread-ring Clojure 1.2 N=50 1.8 secs N=500 7.1 secs N=5000 58.3 secs thread-ring Clojure 1.3 N=50 2.8 secs N=500 25.3 secs N=5000 1800 secs http://shootout.alioth.debian.org/u64q/program.php?test=threadringlang=clojureid=1 chameneos-redux Clojure 1.2 N=50 2.7 secs N=500 11.5 secs N=5000 100.0 secs chameneos-redux Clojure 1.3 N=50 2.9 secs N=500 18.1 secs N=5000 1800 secs http://shootout.alioth.debian.org/u64q/program.php?test=chameneosreduxlang=clojureid=1 -- 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: Reactions to google dart?
On Oct 11, 7:43 am, Timothy Washington twash...@gmail.com wrote: I believe this is google's official blog http://dartinside.com/ to discuss and track issues around Dart http://www.dartlang.org/ ... H - Dart Inside The Unofficial Google Dart Blog Dart Inside is an online service from Trifork A/S, and is not affiliated with Google®. -- 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: Clojure 1.3 Released
On Sep 23, 2:44 pm, Christopher Redinger redin...@gmail.com wrote: We are pleased to announce today the release of Clojure 1.3: The chameneos-redux program that now timeout after 30 minutes, previously completely after 100 seconds with Clojure 1.2 The thread-ring programs that now timeout after 30 minutes, previously completely after 58 seconds with Clojure 1.2 ...OK binarytrees.clojure-4.clojure [33] ...OK binarytrees.clojure-2.clojure [32] ...OK .binarytrees.clojure [31] ...OK .binarytrees.clojure-5.clojure [30] ...OK .binarytrees.clojure-3.clojure [29] ...TIMED OUT .chameneosredux.clojure [28] ...OK fannkuchredux.clojure-2.clojure [27] ...OK .fasta.clojure [26] .PROGRAM FAILED fasta.clojure-3.clojure [25] ...OK .fasta.clojure-5.clojure [24] .PROGRAM FAILED fasta.clojure-4.clojure [23] ...OK .fasta.clojure-2.clojure [22] .PROGRAM FAILED fastaredux.clojure-4.clojure [21] ...OK knucleotide.clojure [20] ...OK knucleotide.clojure-4.clojure [19] ...OK knucleotide.clojure-2.clojure [18] .PROGRAM FAILED knucleotide.clojure-3.clojure [17] ...OK .mandelbrot.clojure-2.clojure [16] ...OK .mandelbrot.clojure-6.clojure [15] ...OK .mandelbrot.clojure-5.clojure [14] ...OK .mandelbrot.clojure [13] .OK .meteor.clojure-2.clojure [12] ...OK .nbody.clojure [11] ...OK .pidigits.clojure-2.clojure [10] ...OK .regexdna.clojure-3.clojure [9] ...OK .revcomp.clojure-3.clojure [8] ...OK .revcomp.clojure-4.clojure [7] ...OK .spectralnorm.clojure-7.clojure [6] ...OK .spectralnorm.clojure-2.clojure [5] ...OK .spectralnorm.clojure-5.clojure [4] ...OK .spectralnorm.clojure-6.clojure [3] ...TIMED OUT .threadring.clojure-2.clojure [2] ...TIMED OUT .threadring.clojure [1] http://shootout.alioth.debian.org/u64q/measurements.php?lang=clojure -- 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: Language shoutout clojure code does not have types
On Sep 19, 5:56 am, Ken Wesson kwess...@gmail.com wrote: On Sun, Sep 18, 2011 at 11:20 AM, Andy Fingerhut andy.finger...@gmail.com wrote: One more detail. The Scala program, and I think all of the fastest programs for that problem, use the GNU GMP library for big integer arithmetic. If that's true, then it indicates that the Java BigInteger class is less than maximally efficient It might just indicate that those who contributed Java programs were curious about using GMP or saw GMP as the easiest route to a faster program or ... and so did not explore other ways to make a faster program as much as they may have done without that siren call. -- otherwise, the JIT should likely turn it into native code of speed the equal of GMP's (perhaps superior, since the JIT could optimize for the exact architecture of the hardware it was running on while your libgmp.so would be compiled for generic x86 hardware so as to be compatible with any x86 box, whether or not it supported 3DNow, MMX, or any of the other various extensions that have cropped up on x86 descendants over the years). Can the BigInt class introduced in Clojure 1.3, perhaps, be made to JIT into code as fast as GMP's? Well, if you can make it past slides 16, 17, 18, 19 and 20 - where the Java optimisation expert falsely would have you believe that the benchmarks game doesn't even show a correct arithmetic mean - slides 21 and 22 suggest there are ways to make considerable improvements to the Java implementation without using GMP - but also note his programs are being run 3-4x longer. http://people.apache.org/~shade/talks/javatechday-Feb2011-performanceBoF.pdf (Let's be charitable about slides 16, 17, 18, 19 and 20, let's just say the Java optimisation expert chose to poke around in someone else's code base, didn't understand what they saw, and couldn't find any better way to mock and dismiss the benchmarks game.) -- 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: Clojure 1.3 Beta 2
On Aug 31, 10:07 pm, Andy Fingerhut andy.finger...@gmail.com wrote: Isaac, all of the programs that fail with Clojure 1.3 now can be made to compile and run on both 1.2 and 1.3 by changing a relatively small part of the programs. I have them on my computer (and probably checked into the github repo clojure-benchmarks), but haven't put them on the benchmarks game web site because it adds a bit of unnecessary clutter to programs that were only intended to run on Clojure 1.2 when they were written. Does the fact that you produced these test results mean that you are considering moving to Clojure 1.3 soon on the benchmarks game web site? When Clojure 1.3 is released - and obviously the beta already is being shown on those /u64 pages. If so, I can contribute the small modifications necessary. Cool - send 'em in! Rich Hickey has written a quite different Clojure 1.3-specific program... Well as the author, he'd have to contribute that. -- 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: Clojure 1.3 Beta 2
Not surprisingly, some of the benchmarks game programs written for Clojure 1.2 have problems with 1.3 Beta 2. My guess is that small changes to the programs will be required to catch up with the new version, but occasionally program failures have indicated a bug in new versions of other languages. Mon 15:17:15 ...OK .binarytrees.clojure-5.clojure [33] Mon 15:21:02 ...OK .binarytrees.clojure-4.clojure [32] Mon 15:30:04 ...OK .binarytrees.clojure [31] Mon 15:37:59 ...OK .binarytrees.clojure-2.clojure [30] Mon 15:49:27 ...OK .binarytrees.clojure-3.clojure [29] Mon 15:54:51 ...OK fannkuchredux.clojure-2.clojure [28] Mon 15:58:54 ...OK .fasta.clojure-2.clojure [27] Mon 16:00:21 ...OK .fasta.clojure [26] Mon 16:02:01 .PROGRAM FAILED fasta.clojure-4.clojure [25] Mon 16:02:04 .PROGRAM FAILED fasta.clojure-3.clojure [24] Mon 16:02:07 .PROGRAM FAILED fastaredux.clojure-4.clojure [23] Mon 16:02:10 .PROGRAM FAILED knucleotide.clojure-3.clojure [22] Mon 16:02:12 ...OK knucleotide.clojure-2.clojure [21] Mon 16:10:07 ...OK knucleotide.clojure [20] Mon 16:21:06 ...OK .mandelbrot.clojure [19] Mon 16:29:08 .PROGRAM FAILED mandelbrot.clojure-3.clojure [18] Mon 16:29:11 .PROGRAM FAILED mandelbrot.clojure-4.clojure [17] Mon 16:29:14 ...OK .mandelbrot.clojure-2.clojure [16] Mon 16:37:06 .PROGRAM FAILED meteor.clojure [15] Mon 16:37:12 ...TIMED OUT nbody.clojure-2.clojure [14] Mon 17:47:43 .PROGRAM FAILED pidigits.clojure [13] Mon 17:47:46 ...OK .regexdna.clojure-3.clojure [12] Mon 17:52:45 .PROGRAM FAILED regexdna.clojure-2.clojure [11] Mon 17:52:47 ...PROGRAM FAILED .revcomp.clojure [10] Mon 17:53:38 ...PROGRAM FAILED .revcomp.clojure-2.clojure [9] Mon 18:03:45 ...OK .revcomp.clojure-4.clojure [8] Mon 18:04:31 ...OK .revcomp.clojure-3.clojure [7] Mon 18:05:07 ...OK .spectralnorm.clojure-5.clojure [6] Mon 18:09:07 ...OK .spectralnorm.clojure-7.clojure [5] Mon 18:11:06 ...OK .spectralnorm.clojure-2.clojure [4] Mon 18:16:31 ...OK .spectralnorm.clojure-6.clojure [3] Mon 18:18:28 ...TIMED OUT .threadring.clojure [2] Mon 19:21:30 ...TIMED OUT .threadring.clojure-2.clojure [1] (Note reverse-complement and reverse-complement #2 fail because memory settings were requested to show reduced Clojure memory usage on the other reverse-complement programs.) The program source code, with build and run logs can be reached from the program name links - http://shootout.alioth.debian.org/u64/measurements.php?lang=clojure -- 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: Clojure Speed performance test
On Aug 18, 6:50 am, David Nolen dnolen.li...@gmail.com wrote:
The Clojure code posted there is pretty awful and shows a gross, gross
misunderstanding of Clojure data types. I submitted one improved version
already, but didn't spend the time to make it really, really fast.
For this particular kind of pointless benchmark it's not hard to get
identical Java perf. If you want to see how I suggest you look at the Alioth
benchmarks where the Clojure code shows a much better understanding of the
language and the fast paths and where the microbenchmarks are quite so
micro.
I'm sure you meant to say - I suggest you look at the Alioth
benchmarks where the Clojure code shows a much better understanding of
the language and the fast paths and where the microbenchmarks are -
not - quite so micro. :-)
As it happens, back in 2005 when trying to come up with new tasks for
what would become the benchmarks game, I considered trying something
based on the Josephus problem as a replacement for the old Doug Bagley
List processing task.
http://web.archive.org/web/20040805114635/http://www.bagley.org/~doug/shootout/bench/lists/
But it just seemed perverse not to solve such a simple problem with an
array and integer add/subtract like this -
public static int countoffSoldiers(int n, int kth)
{
int[] soldiers = new int[n];
for (int i = 0 ; i n ; i++) soldiers[i] = i+1;
//int k = kth-1, survivedLastRound = n; // standard Josephus
problem
int k = 0, survivedLastRound = n;
while (survivedLastRound 1) {
int survived = 0;
for (int i = 0 ; i survivedLastRound; i++)
if (i != k) {
soldiers[survived++] = soldiers[i];
} else {
k += kth;
}
k -= survivedLastRound; // wrap around
survivedLastRound = survived;
}
return soldiers[0];
}
http://java.dzone.com/articles/contrasting-performance
--
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: Clojure Speed performance test
On Aug 18, 7:34 am, Michael Jaaka michael.ja...@googlemail.com wrote: For list reduction it is said to remove every third solder but just with 1 step they remove 1 soldier. There is something wrong Scully. The author knows, and says that variant seemed more interesting. (It should be easy enough to factor out the difference between the variant and the standard Josephus problem into one line of code.) -- 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
Clojure Dev: How you can help! (Hint: Alioth Benchmarks)
1) When I saw this posting on Clojure Dev a month ago http://groups.google.com/group/clojure-dev/browse_thread/thread/2abe6d79087af4fc/9030a0b0c15f26a2?hl=enie=UTF-8q=alioth+shootout+clojurepli=1 I recognised the desire to have some quick and dirty performance regression testing, the Scala developers have been using benchmarks game programs for exactly that purpose - http://www.scala-lang.org/node/360 What puzzled me then, and still puzzles me, is why all the work done by Andy Fingerhut and others is being ignored? 2) Also I don't see why this approach - Our approach was to start with the Java solution and do a direct port. Then, examine where we might have bottle-necks and improve. Repeat until we are on par with Java performance. - would create programs that show anything that interesting about Clojure? Of course, for some of those tiny benchmarks game tasks a Clojure program really won't be much different from the Java program - but for others my guess is that something different would be done in Clojure than Java. -- 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: Anyone want to take a crack at making the fasta shootout program faster?
On Feb 12, 9:51 pm, Michael Gardner gardne...@gmail.com wrote: -snip- Those are all good, but ... Before I pointed out that code size was already shown, you thought just including such a measure would possibly do the trick but now that seems not to be good enough for you. how many people actually look at anything beyond the fastest implementation for a given language? To some extent this is their problem, sure, ... Their problem? Isn't it their choice? but it's not helped by the prominence the shootout site gives to the fastest implementations in various places. The site name is given prominence - The Computer Language Benchmarks Game - but if that isn't what someone wants to see they'll use a different name. In the first place, I'm not even sure what the purpose of all that data is. There's a response to that at the very top of the Help page. -snip- If it's just for entertainment (as the word game seems to imply), There's a response to that misunderstanding at the foot of the Help page. In my opinion, it's simply not meaningful nor interesting to compare the fastest implementations across different languages. -snip- You're welcome to your opinion. Perhaps each language could have one best implementation selected by the community or by a panel of judges; then the default or most prominent comparisons could use these best implementations rather than the fastest ones. -snip- I look forward to seeing you publish the results of your proposed project. -- 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: Anyone want to take a crack at making the fasta shootout program faster?
Yeah but it's not too hard to see why the Lisp programmer Juho Snellman opined on HN the [sic program] implementations seem to have totally dived off the deep end of complexity. On Feb 11, 2:28 pm, Andy Fingerhut andy.finger...@gmail.com wrote: fasta.java-3.java calls the method next(), implementing the linear congruential generator, 200,000,000 times, once for each randomly generated DNA character in the output file. -- 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: Anyone want to take a crack at making the fasta shootout program faster?
On Feb 10, 1:41 pm, Bill James w_a_x_...@yahoo.com wrote: -snip- The C++ program was evidently deprecated because it did not go through the process of generating a random character for each character that it output. The author realized that the pseudo-random-number-generator had a cycle-length less than 200_000. Both the C++ program and the Clojure program use a much more efficient algorithm than the other programs. That may violate the rules. Now the SBCL 1.0.45 updates and the LuaJIT 2.0.0-beta6 updates are done, and those long long running Ruby mandelbrot and Python fannkuch- redux programs have finished - time for some Clojure. I agree with your assessment that the C++ program and the Clojure program use a much more efficient algorithm than the other programs. Showing your Clojure program would go against the use the same algorithm spirit of the benchmarks game - so it won't be shown. In contrast, meteor-contest is pretty much open to whatever algorithm you can dream up (with obvious exceptions - trivial programs that just print the hard coded result). http://shootout.alioth.debian.org/u32q/benchmark.php?test=meteorlang=all#about -- 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: Anyone want to take a crack at making the fasta shootout program faster?
Bill James doesn't seem to have had difficulty answering that question - Both the C++ program and the Clojure program use a much more efficient algorithm than the other programs. That may violate the rules. But what about that fasta Java 6 -server #3 program? On Feb 10, 1:02 pm, Andy Fingerhut andy.finger...@gmail.com wrote: It would be easier for submitters to answer that question if it was more obvious *why* a program is in the interesting alternative program section. Even a brief note in comments at the top of such programs explaining the reason for their alternative status would be enlightening. Thanks, Andy On Feb 10, 2011, at 12:47 PM, Isaac Gouy wrote: On Feb 10, 1:17 am, Bill James w_a_x_...@yahoo.com wrote: http://shootout.alioth.debian.org/u32/benchmark.php?test=fasta〈=all The fastest program shown here is in Java and runs in 1.72 seconds. However, at the bottom of the page (under interesting alternative programs) there is a C++ program that runs in 0.25 seconds; it seems to work basically the same way that my program does. So this Clojure program will probably be relegated to the bottom of the page. Should it be relegated to the bottom of the page? -- 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: Anyone want to take a crack at making the fasta shootout program faster?
On Feb 10, 1:17 am, Bill James w_a_x_...@yahoo.com wrote: http://shootout.alioth.debian.org/u32/benchmark.php?test=fasta〈=all The fastest program shown here is in Java and runs in 1.72 seconds. However, at the bottom of the page (under interesting alternative programs) there is a C++ program that runs in 0.25 seconds; it seems to work basically the same way that my program does. So this Clojure program will probably be relegated to the bottom of the page. Should it be relegated to the bottom of the page? -- 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: only 3 benchmarks game tasks still have no Clojure programs
On Jan 10, 6:27 am, Stuart Halloway stuart.hallo...@gmail.com wrote: I notice that the fastest Java version of pidigits uses a native library named jpargmp. Is there documentation somewhere that spells out how and when you are allowed to use native libraries and still claim to be written in language X? If the standard language X implementation wraps the native library, are the programs you write in language X using the wrapped functionality of the native library written in language X? If the standard language implementation for language X wraps a native library, providing that functionality to all language X programs, why should language Y programs be prevented from using that same native library? In addition to language specific multiprecision arithmetic, we will accept programs that use GMP. http://shootout.alioth.debian.org/u32/performance.php?test=pidigits#about -- 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: only 3 benchmarks game tasks still have no Clojure programs
On Jan 10, 6:27 am, Stuart Halloway stuart.hallo...@gmail.com wrote: I notice that the fastest Java version of pidigits uses a native library named jpargmp. Is there documentation somewhere that spells out how and when you are allowed to use native libraries and still claim to be written in language X? As a practical matter, presumably the same wrapper could be used from Clojure? http://alioth.debian.org/scm/viewvc.php/shootout/bench/Include/java/GmpUtil.h?view=markuprevision=1.3root=shootout http://alioth.debian.org/scm/viewvc.php/shootout/bench/Include/java/GmpUtil.c?view=markuprevision=1.3root=shootout -- 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: only 3 benchmarks game tasks still have no Clojure programs
On Jan 10, 6:27 am, Stuart Halloway stuart.hallo...@gmail.com wrote: I notice that the fastest Java version of pidigits uses a native library named jpargmp. Is there documentation somewhere that spells out how and when you are allowed to use native libraries and still claim to be written in language X? As a practical matter, presumably the same wrapper could be used from Clojure? http://alioth.debian.org/scm/viewvc.php/shootout/bench/Include/java/GmpUtil.h?view=markuprevision=1.3root=shootout http://alioth.debian.org/scm/viewvc.php/shootout/bench/Include/java/GmpUtil.c?view=markuprevision=1.3root=shootout -- 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
only 3 benchmarks game tasks still have no Clojure programs
Only 3 tasks on the computer language benchmarks game still have no Clojure programs - 1) meteor-contest http://shootout.alioth.debian.org/u32q/benchmark.php?test=meteor 2) chameneos-redux http://shootout.alioth.debian.org/u32q/benchmark.php?test=chameneosredux 3) pidigits http://shootout.alioth.debian.org/u32q/benchmark.php?test=pidigits http://shootout.alioth.debian.org/help.php#stepbystep -- 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: benchmarking tipps and tricks
On Nov 21, 3:15 pm, nickik nick...@gmail.com wrote: -snip- - What are the best tools to benchmark on the jvm (and optimize your tests) JavaStats http://shootout.alioth.debian.org/help.php#languagex -- 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: Clojure vs F# performance
On Nov 22, 10:18 am, Mark Engelberg mark.engelb...@gmail.com wrote: I doubt that F# Mono benchmarks are representative of F#'s performance on Windows. Perhaps they are representative of F#'s performance on Mono on Windows :-) But I wouldn't take a bet on that - performance measurements can be very brittle. -- 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: Clojure vs F# performance
On Nov 22, 12:54 pm, Ralph grkunt...@gmail.com wrote: That is almost certainly true, since the Microsoft have probably done extensive optimization on the CLR. On Nov 22, 1:18 pm, Mark Engelberg mark.engelb...@gmail.com wrote: I doubt that F# Mono benchmarks are representative of F#'s performance on Windows. If Microsoft have only *probably* done extensive optimization on the CLR you're better off staying away from almost certainly true - how about probably true? http://shootout.alioth.debian.org/demo/compare.php?lang=fsc -- 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: Clojure 1.2 and the Computer Language Benchmarks Game
On Sep 9, 10:15 pm, gary ng garyng2...@gmail.com wrote: On Thu, Sep 9, 2010 at 10:04 PM, Isaac Gouy igo...@yahoo.com wrote: Is there any point speculating about this as outsiders? It was available - Data.HashTable seems to be copyright 2003. http://ogi.altocumulus.org/~hallgren/Programatica/tools/pfe.cgi?Data Huh ? point ? it was just a casual comment, no point was intended. And I have read some comments by Don that what is in the shoutout is way faster than Data.HashTable If you knew there was another option why write I doubt there is any choice for Haskell ? And Data.HashTable also use some mutable array thing so it is still not the idiomatic Haskell of everything is immutable. afaict idiomatic is everything referentially transparent not everything immutable, as in - I needed a halfway decent mutable collection type – having a properly tested mutable collection that actually performs well would be a godsend. how can you assure that(let's put aside the under the hood things where it is done in C) if you break the assumption that value can be changed. Reading the first paragraph Introduction to Uniqueness Typing of this paper should help you with that question - http://www.st.cs.ru.nl/papers/2008/vrie08-IFL07-UniquenessTypingSimplified.pdf BTW, it seems that to verteran Haskellers, the speed of Data.HashTable is not a concern to them as they said they don't see the need of that(mutable hasktable) in their usage. There seems to be a bug(as in it is slow) filed for this package for quite a while but no one even bother to attempt to improve it. I'm not going to speculate about what unnamed verteran Haskellers have or have not said. Read the bug report and you'll see that the root problem was GC - do you think changing GC is a quick fix? -- 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: Clojure 1.2 and the Computer Language Benchmarks Game
On Sep 10, 10:35 am, gary ng garyng2...@gmail.com wrote: On Fri, Sep 10, 2010 at 8:49 AM, Isaac Gouy igo...@yahoo.com wrote: Huh ? point ? it was just a casual comment, no point was intended. And I have read some comments by Don that what is in the shoutout is way faster than Data.HashTable If you knew there was another option why write I doubt there is any choice for Haskell ? That was referring to the original comment about 'making a mutable implementation' meaning the program itself ASKED for that particular functionality. The one in the shoutout is one implementation of it, the one in Data.HashTable is another. When I said no choice, I was saying no choice but to implement a mutable hash table, in respond to the underlying message of 'why did they implement a mutable hashtable' as if making it mutable is only for performance purpose. Clearly, they did choose to write all that code in order to get a much faster program - I can't tell you if Andy had noticed the benchmark was about Hashtable update and k-nucleotide strings or whether he knew about Data.HashTable. And Data.HashTable also use some mutable array thing so it is still not the idiomatic Haskell of everything is immutable. afaict idiomatic is everything referentially transparent not everything immutable, as in - I needed a halfway decent mutable collection type – having a properly tested mutable collection that actually performs well would be a godsend. how can you assure that(let's put aside the under the hood things where it is done in C) if you break the assumption that value can be changed. Reading the first paragraph Introduction to Uniqueness Typing of this paper should help you with that question - http://www.st.cs.ru.nl/papers/2008/vrie08-IFL07-UniquenessTypingSimpl... Would try to digest that. Bite-sized: An important property of pure functional programming languages is referential transparency: the same expression used twice must have the same value twice. A side effect on a variable (file) is okay as long as that variable is never used again: it is okay for a function to modify its input if the input is not shared. Referential transparency then trivially holds because the same expression never occurs more than once. Rather than just returning the read character, fgetc returns a pair consisting of the read character and a new file, file1. Although file0 and file1 point to the same file on disk, they are conceptually and syntactically different, and thus it is clear that a and b may have different values. I'm not going to speculate about what unnamed verteran Haskellers have or have not said. Read the bug report and you'll see that the root problem was GC - do you think changing GC is a quick fix? Don suggested on reddit for some fixes that tackle the GC issue(not changing the GC, but the way to get around the performance caused by GC), using similar approach as in the shoutout. -- 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: Clojure 1.2 and the Computer Language Benchmarks Game
On Sep 10, 11:54 am, gary ng garyng2...@gmail.com wrote: On Fri, Sep 10, 2010 at 11:13 AM, Isaac Gouy igo...@yahoo.com wrote: Clearly, they did choose to write all that code in order to get a much faster program - I can't tell you if Andy had noticed the benchmark was about Hashtable update and k-nucleotide strings or whether he knew about Data.HashTable. I know they did it to get a faster program, but under the requirement of : IT MUST BE MUTABLE HASHTABLE If you change the requirement to something else that acheives the end result without this specific requirement, they may not use hashtable at all. Which is also the message I get from various place like reddit or stackoverlow about this same issue. That is 'use your language's strength to solve the problem, not to mimic other language, i.e. the what not the how'. It's starting to look like actually there was a point you wanted to make ;-) If you change the requirement to something else you'd simply be missing the point - which was to look at hashtable updates and strings. Does it actually say that the hashtable updates have to be destructive? And this sentiment is not unique to Haskell. I recently saw similar questions on J language of 'how can I write a Haskell style filter(HOF)', the overall answers there are 'you don't need haskell style filter and can achieve the same result in a J way'. Similarly for Haskell which is 'you don't need to use mutable hash table and can very likely get the same result using other immutable data structure' But in this case the problem is 'implement a mutable hashtable' which is what my 'no choice' was referring to. Unlike language say Python or F# where hash table is in general considered to be part of the language, Data.HashTable is not. It is just one 'sample' of implementation of mutable hash table which happens to be slow. There's no choice in binary-trees either - you must use binary-trees and you must allocate all the memory. There's no choice in pi-digits either - you must use that particular step-by-step spigot algorithm taken from that Haskell paper. There's no choice in fannkuch-redux either - you must use that particular ordering of permutations taken from that Lisp paper. etc etc Forgive me but you do seem to be belabouring the obvious. -snip- Bite-sized: An important property of pure functional programming languages is referential transparency: the same expression used twice must have the same value twice. A side effect on a variable (file) is okay as long as that variable is never used again: it is okay for a function to modify its input if the input is not shared. Referential transparency then trivially holds because the same expression never occurs more than once. Rather than just returning the read character, fgetc returns a pair consisting of the read character and a new file, file1. Although file0 and file1 point to the same file on disk, they are conceptually and syntactically different, and thus it is clear that a and b may have different values. I read this part, trying to fit that into this mutable hashtable context. Below this paragraph, it mentioned some requirement/assumption that file0, file1 ... cannot be 're-used' which I don't know how to apply to hashtable. Do you know if we re-write that as - Rather than just returning the updated value, htAddOrUpdate returns a pair consisting of the updated value and a new hashtable, hashtable1. Although hashtable0 and hashtable1 point to the same structures in memory, they are conceptually and syntactically different, and thus it is clear that a and b may have different values. -- 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: Clojure 1.2 and the Computer Language Benchmarks Game
On Sep 10, 2:22 pm, gary ng garyng2...@gmail.com wrote: -snip- My initial comment was all about 'it seems that Haskell submission is not the typical elegant form' and to me because of the specific you want to measure, there is no acceptable elegant Haskell form. So what are we to do when there's a problem that has no acceptable elegant Haskell form? Does it actually say that the hashtable updates have to be destructive? If want to go that route, be my guest. I don't understand what you mean, didn't you say - it must be a mutable hashtable? Why couldn't it be a hashtable that copied values? Indeed. Your benchmark suite are very specific about how certain things must be done in order to measure a specific aspect you want to measure. The other complaint is that it's not specific enough and allows too much play, with programs in one language being too different to programs in other languages. -- 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: Clojure 1.2 and the Computer Language Benchmarks Game
On Sep 2, 4:51 pm, Isaac Gouy igo...@yahoo.com wrote: On Sep 1, 9:46 pm, John Fingerhut andy.finger...@gmail.com wrote: Thanks to many people on this list in Aug 2009 who helped improve my code, to Johannes Friestad for writing a nice fast Clojure program using deftype for the n-body problem, to Isaac Gouy for setting up the shootout web site to accept Clojure submissions, and to my having more time than good sense to work on this, there are now Clojure programs for 5 of the 10 shootout web site benchmark problems. iirc Clojure won't show up on the summary pages until there are 7 programs implemented. Nontheless I've put Clojure on the home page. You can see a brief summary of results comparing run time, memory, and code size against Java 6 -server here: http://shootout.alioth.debian.org/u32/benchmark.php?test=all〈=clo... Clojure now shows up on the summary pages http://shootout.alioth.debian.org/u32q/which-programming-languages-are-fastest.php?calc=chartjava=onscala=onsbcl=onclojure=onpython3=onjruby=on -- 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: Clojure 1.2 and the Computer Language Benchmarks Game
On Sep 9, 6:06 pm, gary ng garyng2...@gmail.com wrote: On Thu, Sep 2, 2010 at 6:07 PM, John Fingerhut andy.finger...@gmail.com wrote: Some of the Haskell submissions are quite long for what they do. The k-nucleotide one, for example, implements a mutable hash table using features in Haskell that I had never seen before looking at that program. Did they need to write all of that code to solve the problem? No. Did they choose to, in order to get a much faster program that would be more competitive in run time versus other languages. Definitely. Is it the requirement for that particular program to handle hash table (to test in place update) ? That seems to be the message I get from the description of the program. Yes. If that is the case, I doubt there is any choice for Haskell. iirc the Haskell programs, and the Clean programs, and the Pascal programs, and ... use translations of the simple hash table used by the C programs. If I ever knew, I don't recall why the Haskell program does not use Data.HashTable -- 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: Clojure 1.2 and the Computer Language Benchmarks Game
On Sep 9, 7:19 pm, gary ng garyng2...@gmail.com wrote: On Thu, Sep 9, 2010 at 7:02 PM, Isaac Gouy igo...@yahoo.com wrote: iirc the Haskell programs, and the Clean programs, and the Pascal programs, and ... use translations of the simple hash table used by the C programs. If I ever knew, I don't recall why the Haskell program does not use Data.HashTable Could be that it wasn't there at the time it was submitted. Is there any point speculating about this as outsiders? It was available - Data.HashTable seems to be copyright 2003. http://ogi.altocumulus.org/~hallgren/Programatica/tools/pfe.cgi?Data.HashTable And Data.HashTable also use some mutable array thing so it is still not the idiomatic Haskell of everything is immutable. afaict idiomatic is everything referentially transparent not everything immutable, as in - I needed a halfway decent mutable collection type – having a properly tested mutable collection that actually performs well would be a godsend. And maybe the description for this bug report says it all - http://hackage.haskell.org/trac/ghc/ticket/3149 -- 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: Shootout fannkuch
On Sep 3, 4:24 pm, Miki miki.teb...@gmail.com wrote: Fannkuch has required the permutations to be generated in a particular order for years because too many programmers contributed programs that did not generate some of the permutations or used faster algorithms to generate the permutations. I've read several implementation so far and I'm still not clear about the exact algorithm used to generate the permutations. The permutations are generated in the same order as as permutations generated by the Tompkins-Paige algorithm, see pages 150-151 Permutation Generation Methods Robert Sedgewick. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.77.7533 -- 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: Shootout fannkuch
On Sep 2, 11:45 pm, John Fingerhut andy.finger...@gmail.com wrote: Most likely. That one I found somewhat annoying in that the checksum computation does depend upon the permutations being generated in a particular order. Fannkuch has required the permutations to be generated in a particular order for years because too many programmers contributed programs that did not generate some of the permutations or used faster algorithms to generate the permutations. At first the requirement was met simply by printing the first 30 permutations but too many programmers contributed programs that used the accepted algorithm for the first 30 permutations and then did not generate some of the permutations or used faster algorithms for the bulk of the work - somewhat annoying. It also seems to depend upon the sign flipping being done for every permutation, even those beginning with a '1', for which the pfannkuch function returns 0. The checksum is computed as follows: checkSum += permutationIndex % 2 == 0 ? flipsCount : -flipsCount; where permutationIndex is determined by a fixed order in which all n! permutations are to be generated. The goal is to prevent programs from questionable optimizations when significant permutation subsets were excluded from processing, in contradiction with an explicitly stated rule prohibiting such shortcuts, thus giving those programs unfair advantage. The cheksum is very lightweight and can be computed in parallel. To which I'll add - At least one person noticed that the isEven test reduces what needs to be known about permutationIndex - so they simply toggle between -1 and 1. One way to find out what the order is is to download the Java benchmark, add some debug print statements, and run it with a small argument like 6 or 7. Either that, or read and understand its permutation generating code. Andy On Thu, Sep 2, 2010 at 11:01 PM, Miki miki.teb...@gmail.com wrote: Hello, I've tried writing a a solution to shootout fannkuch (http:// shootout.alioth.debian.org/u32/performance.php?test=fannkuchredux), however I seem to have a bug in the checksum. Is it just the order of permutations or am I missing something? Code athttp://bitbucket.org/tebeka/shootout-clj/src/tip/fannkuch.clj All the best, -- Miki -- 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.comclojure%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: Shootout fannkuch
On Sep 2, 11:01 pm, Miki miki.teb...@gmail.com wrote: Hello, I've tried writing a a solution to shootout fannkuch (http:// shootout.alioth.debian.org/u32/performance.php?test=fannkuchredux), however I seem to have a bug in the checksum. Is it just the order of permutations or am I missing something? I've added a file of the permutations N = 7 generated by one of the programs to the website, which may help you to debug your program - http://shootout.alioth.debian.org/u32/iofile.php?test=fannkuchreduxfile=extra -- 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: Shootout fannkuch
On Sep 3, 4:24 pm, Miki miki.teb...@gmail.com wrote: Fannkuch has required the permutations to be generated in a particular order for years because too many programmers contributed programs that did not generate some of the permutations or used faster algorithms to generate the permutations. I've read several implementation so far and I'm still not clear about the exact algorithm used to generate the permutations. We all struggle with that same problem because the algorithm was taken from program source code in the paper Performing Lisp Analysis of the FANNKUCH Benchmark. The Lua program provides a succinct implementation, lines 29 through 42 http://shootout.alioth.debian.org/u32/program.php?test=fannkuchreduxlang=luaid=1 If you find Lisp easier to read then take a look at the deprecated fannkuch program - http://shootout.alioth.debian.org/gp4/program.php?test=fannkuchlang=sbclid=2 -- 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: Clojure 1.2 and the Computer Language Benchmarks Game
On Sep 1, 9:46 pm, John Fingerhut andy.finger...@gmail.com wrote: Thanks to many people on this list in Aug 2009 who helped improve my code, to Johannes Friestad for writing a nice fast Clojure program using deftype for the n-body problem, to Isaac Gouy for setting up the shootout web site to accept Clojure submissions, and to my having more time than good sense to work on this, there are now Clojure programs for 5 of the 10 shootout web site benchmark problems. iirc Clojure won't show up on the summary pages until there are 7 programs implemented. Nontheless I've put Clojure on the home page. You can see a brief summary of results comparing run time, memory, and code size against Java 6 -server here: http://shootout.alioth.debian.org/u32/benchmark.php?test=all〈=clo... Note: All Clojure programs are AOT compiled before any time measurements are made when running the program. The programs are short enough that I believe the longest one was around 1.5 or 2 seconds on my MacBook Pro, but that time isn't included on the web site results. Are there improvements that could be made to the Clojure programs to make them faster? Most likely so. I doubt very much these are the fastest ones possible. I have not written any Java code for these solutions. I am sure that when push comes to shove in improving the run time of parts of a real-world program that were performance-critical, most programmers would optimize using Java or even C/C++. The goal here was to see what could be done without using those techniques. If people want to beat each other up using the shootout web site's results, I would probably recognize in them some of the my language is best for every purpose attitude I once had as a teenager. Now I just see it as one of several ways to evaluate a programming language, and often not the most important one. Thanks, Andy On Thu, Aug 26, 2010 at 11:59 AM, Isaac Gouy igo...@yahoo.com wrote: On Aug 26, 8:37 am, John Fingerhut andy.finger...@gmail.com wrote: I have now submitted small modifications that permit AOT compilation. The compile time was small -- on the order of 1 to 2 sec of the total CPU time, which is often a small percentage of the long runs that are reported on the shootout web site. But of course it is better if it is not included in the reported times, which it soon will not be. AOT compiled http://shootout.alioth.debian.org/u32q/program.php?test=mandelbrotla... http://shootout.alioth.debian.org/u32q/program.php?test=regexdnalang... http://shootout.alioth.debian.org/u32q/program.php?test=knucleotidel... Andy On Thu, Aug 26, 2010 at 12:26 AM, Meikel Brandmeyer m...@kotka.de wrote: Hi, On 26 Aug., 07:58, Isaac Gouy igo...@yahoo.com wrote: Have you actually measured the time difference? Compare the mandelbrot numbers for Haskell, Java and Scala. The ranges are (0.07s 0.86s 13s), (0.19s 0.86s 12s), (0.22s 0.97s 15s). So Java and Scala are not slower than Haskell, but the low iteration numbers say something different. So you don't measure what you claim you measure. And the fact that things vanish asymptotically doesn't fix a broken methodology. Sincerely Meikel -- 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.comclojure%2bunsubscr...@googlegroups.com clojure%2bunsubscr...@googlegroups.comclojure%252bunsubscr...@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.comclojure%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: Clojure 1.2 and the Computer Language Benchmarks Game
On Sep 2, 5:28 pm, Sean Corfield seancorfi...@gmail.com wrote: On Wed, Sep 1, 2010 at 9:46 PM, John Fingerhut andy.finger...@gmail.com wrote: You can see a brief summary of results comparing run time, memory, and code size against Java 6 -server here: http://shootout.alioth.debian.org/u32/benchmark.php?test=all〈=clo... Very interesting. Clojure is faster than several languages (surprisingly so in some cases - at least for me) but seems to use more code to express solutions - which really surprised me! Perhaps some of those Clojure programs include code that isn't actually required, for example, code to display a usage message? Perhaps some of those Clojure programs are written to use all the cores on the quad-core machine and the programs you have compared them with are only written to use one core? Memory use was what I noticed. -- 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: Clojure 1.2 and the Computer Language Benchmarks Game
On Aug 26, 12:26 am, Meikel Brandmeyer m...@kotka.de wrote: Hi, On 26 Aug., 07:58, Isaac Gouy igo...@yahoo.com wrote: Have you actually measured the time difference? If you have measured the time difference with/without AOT compilation then apparently you don't wish to share those measurements. Oh well. Without Clojure AOT compilation http://shootout.alioth.debian.org/u32q/program.php?test=mandelbrotlang=clojureid=1 With AOT compilation http://shootout.alioth.debian.org/u32q/program.php?test=mandelbrotlang=clojureid=2 Compare the mandelbrot numbers for Haskell, Java and Scala. The ranges are (0.07s 0.86s 13s), (0.19s 0.86s 12s), (0.22s 0.97s 15s). So Java and Scala are not slower than Haskell, but the low iteration numbers say something different. So you don't measure what you claim you measure. And the fact that things vanish asymptotically doesn't fix a broken methodology. If I didn't measure what I claimed to measure then where did you get those numbers from? Sincerely Meikel -- 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: Clojure 1.2 and the Computer Language Benchmarks Game
On Aug 26, 8:37 am, John Fingerhut andy.finger...@gmail.com wrote: I have now submitted small modifications that permit AOT compilation. The compile time was small -- on the order of 1 to 2 sec of the total CPU time, which is often a small percentage of the long runs that are reported on the shootout web site. But of course it is better if it is not included in the reported times, which it soon will not be. AOT compiled http://shootout.alioth.debian.org/u32q/program.php?test=mandelbrotlang=clojureid=2 http://shootout.alioth.debian.org/u32q/program.php?test=regexdnalang=clojureid=2 http://shootout.alioth.debian.org/u32q/program.php?test=knucleotidelang=clojureid=1 Andy On Thu, Aug 26, 2010 at 12:26 AM, Meikel Brandmeyer m...@kotka.de wrote: Hi, On 26 Aug., 07:58, Isaac Gouy igo...@yahoo.com wrote: Have you actually measured the time difference? Compare the mandelbrot numbers for Haskell, Java and Scala. The ranges are (0.07s 0.86s 13s), (0.19s 0.86s 12s), (0.22s 0.97s 15s). So Java and Scala are not slower than Haskell, but the low iteration numbers say something different. So you don't measure what you claim you measure. And the fact that things vanish asymptotically doesn't fix a broken methodology. Sincerely Meikel -- 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.comclojure%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: Clojure 1.2 and the Computer Language Benchmarks Game
On Aug 25, 6:17 am, John Fingerhut andy.finger...@gmail.com wrote: I will try submitting one or a few of my benchmark programs created 1 year ago. For anyone that wants to look at some timing results and/or my source code used to achieve them before then, they are available on github here: http://github.com/jafingerhut/clojure-benchmarks I just pushed a few changes required for Clojure 1.2 about 10 minutes ago. There aren't many changes to the results from Clojure 1.1 alpha I tested against a year ago, except for the following -- note that besides updating my Clojure version since last time, I have also upgraded the version of OS X on my Mac, and the version of Java from Apple. I have not attempted to test these changes independently to see which one or ones caused the change in run time: k-nucleotide benchmark completed in about 2/3 the time of earlier runs (good) mandelbrot also runs in about 2/3 the time of before n-body takes about 5x longer than before. I do not know why. As always, improvements to my versions are welcome. I am pretty sure some people have posted programs they have worked on for these problems during the most recent 1 year to the group, but I'm sorry to say I haven't kept up with all of them to see if they are faster than my fastest versions. Andy 1) The command line requested for these first programs doesn't AOT compile so the measured time includes compiling the program. Perhaps AOT compilation is an usual way to use Clojure - or perhaps it would be better to show programs that used AOT compilation? http://groups.google.com/group/clojure/browse_thread/thread/e9902e30afbb805e 2) mandelbrot - There seems to be some problem with the mandelbrot program - the program doesn't seem to exit for perhaps a minute after the output file is created - see the difference between CPU secs and Elapsed secs. http://shootout.alioth.debian.org/u32q/program.php?test=mandelbrotlang=clojureid=1 3) regexdna http://shootout.alioth.debian.org/u32q/program.php?test=regexdnalang=clojureid=1 -- 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: Clojure 1.2 and the Computer Language Benchmarks Game
On Aug 25, 10:31 pm, Meikel Brandmeyer m...@kotka.de wrote: Hi, On 26 Aug., 05:37, Isaac Gouy igo...@yahoo.com wrote: 1) The command line requested for these first programs doesn't AOT compile so the measured time includes compiling the program. Which makes the comparison of languages with this benchmark even more uninteresting. Have you actually measured the time difference? Perhaps AOT compilation is an usual way to use Clojure - or perhaps it would be better to show programs that used AOT compilation? If startup time matters AOT compilation is a valid step to take. AOT is not necessary but helps in such a case. 2) mandelbrot - There seems to be some problem with the mandelbrot program - the program doesn't seem to exit for perhaps a minute after the output file is created - see the difference between CPU secs and Elapsed secs. (shutdown-agents) Sincerely Meikel -- 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: Clojure 1.2 and the Computer Language Benchmarks Game
On Aug 23, 7:07 pm, ataggart alex.tagg...@gmail.com wrote: It's never been clear to me exactly what the code is supposed to be do. For example, the spec for the binary-tree test is so wholly lacking in any details that I'm left to infer that one is supposed to copy an implementation used previously, though without any indication as to which is the canonical version. Do I really need to perform the itemCheck math ops in the binary-tree test which is ostensibly about allocating/deallocating memory? Who knows? Some people complain - underspecified - and some people complain - overspecified - and some people just contribute programs. Some people complain - forced to write code that isn't idiomatic - as if there was a canonical version. (Did you find any programs that didn't perform itemCheck?) In Clojure does one integer addition and one integer subtraction per node take a significant amount of time? Who knows? (I guess you could measure with/without.) -- 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: Clojure 1.2 and the Computer Language Benchmarks Game
On Aug 23, 7:35 pm, Robert McIntyre r...@mit.edu wrote: I hear you --- I got excited about this too, and implemented the fannuchredux algorithm, only to be thwarted by an undocumented checksum each program is also supposed to calculate. This checksum depends heavily on the exact order in which a set of permutations are traversed. And of course, they aren't traversed in lexical order, but whatever order the original implementation used. By design - This checksum depends heavily on the exact order in which a set of permutations are traversed. - people kept finding ways to not generate some of the permutations or used faster algorithms to generate the permutations - so fannkuch-redux now allows little flexibility. -- 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: Clojure 1.2 and the Computer Language Benchmarks Game
On Aug 24, 6:44 am, Stuart Halloway stuart.hallo...@gmail.com wrote: Clojure 1.3's performance improvements will significantly impact perf on some of the benchmarks. If you are trying these out, please try them on both 1.2 and 1.3. Has Clojure 1.3 been released? Also: the benchmarks are totally a numbers game: throw idioms and readability out the window. Clojure 1.3 should be able to match Java performance if you basically write Java-in-Clojure. On Clojure 1.2 you will have to do stranger things to get there. If you choose to throw idioms and readability out the window then don't be surprised at the comments that will be made about Clojure. If you have to do stranger things to get there with Clojure 1.2 then doesn't that simply suggest Clojure 1.2 performance doesn't match Java performance? -- 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: Clojure 1.2 and the Computer Language Benchmarks Game
On Aug 24, 8:48 am, Stuart Halloway stuart.hallo...@gmail.com wrote: On Aug 24, 6:44 am, Stuart Halloway stuart.hallo...@gmail.com wrote: Clojure 1.3's performance improvements will significantly impact perf on some of the benchmarks. If you are trying these out, please try them on both 1.2 and 1.3. Has Clojure 1.3 been released? No, but since the num/prim/equiv work specifically targets performance, we want to collect people's experiences comparing 1.2 and 1.3. This is totally separate from the benchmark submission process and for our own information. Also: the benchmarks are totally a numbers game: throw idioms and readability out the window. Clojure 1.3 should be able to match Java performance if you basically write Java-in-Clojure. On Clojure 1.2 you will have to do stranger things to get there. If you choose to throw idioms and readability out the window then don't be surprised at the comments that will be made about Clojure. Let me reduce the stridency of my previous statement: throwing things out the window is too strong. Benchmarks are a numbers contest, not a beauty contest. But, there's no saying the resulting programs will be ugly (or even non-idiomatic). Try things. Measure. It is simply the case that some idiomatic code (i.e. numeric code with no hints in the body) is faster in master/1.3 than in 1.2, and that some benchmark-useful things (fns taking/returning primitives) are available only post 1.2. Well when Clojure 1.3 is released... The phrase idiomatic code often seems to be used to mean - code written in a natural way for that language and as if performance doesn't matter - whereas I seem to have the strange notion that both code written as if performance matters and code written as if performance doesn't matter can be idiomatic code. http://shootout.alioth.debian.org/u32q/program.php?test=spectralnormlang=ghcid=2 http://shootout.alioth.debian.org/u32q/program.php?test=spectralnormlang=ghcid=4 If you have to do stranger things to get there with Clojure 1.2 then doesn't that simply suggest Clojure 1.2 performance doesn't match Java performance? If I had wanted to suggest that, I would have said you can't get there. With Clojure 1.2, you can get fast programs easily, or screaming-fast programs with effort. Some of the work in Clojure 1.3 reduces that effort. Stu -- 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: Clojure 1.2 and the Computer Language Benchmarks Game
On Aug 24, 9:58 am, Nicolas Oury nicolas.o...@gmail.com wrote: On Tue, Aug 24, 2010 at 5:33 PM, Isaac Gouy igo...@yahoo.com wrote: Well when Clojure 1.3 is released... The phrase idiomatic code often seems to be used to mean - code written in a natural way for that language and as if performance doesn't matter - whereas I seem to have the strange notion that both code written as if performance matters and code written as if performance doesn't matter can be idiomatic code. For most of the code, being slower (in a reasonable limit) is not important if you are correct and easily maintable, and reusable. When it doesn't matter it doesn't matter but when it matters it matters. -- 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: Clojure 1.2 and the Computer Language Benchmarks Game
On Aug 24, 7:48 pm, ataggart alex.tagg...@gmail.com wrote: Thanks for focusing solely on one example, and still not providing any useful, specific information. You asked - Do I really need to perform the itemCheck math ops in the binary-tree test - and if you can't see the answer from simply looking at the other programs and the program output, then you need more hand-holding than I'm going to provide. Will it really make a big difference when I add the indefinite article to what it already says in the description? Each program should ... - walk the tree nodes, checksum node items (and maybe deallocate the node) There may be a number of possible implementations for a given design criterion. The binary-tree memory allocation/deallocation test (for example) includes not only that, but also math ops, in a particular fashion, a particular style of looping, with particular string concatenation, and particular places for printing to stdout, etc. Yes. From what I can infer, the criterion being tested is how well can clojure code perform when it's written just like the imperative version in, say, C++. Nonsense. You could as easily say - the criterion being tested is how well can clojure code perform when it's written just like the functional version in, say Clean or Haskell? I had been assuming this was a serious comparison various languages performance in achieving a particular design goal. After so many people have contributed programs for binary-trees in so many languages, I had been assuming it was kind-of easy. Time to move on to something productive. On Aug 24, 11:17 am, Isaac Gouy igo...@yahoo.com wrote: On Aug 24, 9:50 am, ataggart alex.tagg...@gmail.com wrote: It would have been more useful to answer the question (particularly with regards to a canonical implementation) than getting all passive- aggressive. Did you find any programs that didn't perform itemCheck? In Clojure does one integer addition and one integer subtraction per node take a significant amount of time? On Aug 24, 5:55 am, Isaac Gouy igo...@yahoo.com wrote: On Aug 23, 7:07 pm, ataggart alex.tagg...@gmail.com wrote: It's never been clear to me exactly what the code is supposed to be do. For example, the spec for the binary-tree test is so wholly lacking in any details that I'm left to infer that one is supposed to copy an implementation used previously, though without any indication as to which is the canonical version. Do I really need to perform the itemCheck math ops in the binary-tree test which is ostensibly about allocating/deallocating memory? Who knows? Some people complain - underspecified - and some people complain - overspecified - and some people just contribute programs. Some people complain - forced to write code that isn't idiomatic - as if there was a canonical version. (Did you find any programs that didn't perform itemCheck?) In Clojure does one integer addition and one integer subtraction per node take a significant amount of time? Who knows? (I guess you could measure with/without.) -- 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: AOT compilation newbie mistakes
On Aug 22, 4:28 pm, Robert McIntyre r...@mit.edu wrote: oh yes -- please don't do it manually for anything production But, it's good to know what's actually going on behind the scenes, especially when things stop working :) For my simple needs - java -cp .:clojure.jar -Dclojure.compile.path=. clojure.lang.Compile hello - is exactly what I was looking for. -- 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
Clojure 1.2 and the Computer Language Benchmarks Game
Now Clojure 1.2 has been released, Clojure programs will be included in the Computer Language Benchmarks Game. If you'd like to contribute Clojure programs, please follow the step- by-step http://shootout.alioth.debian.org/help.php#contribute -- 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
AOT compilation newbie mistakes
$ /usr/local/src/jdk1.6.0_18/bin/java -cp .:clojure.jar clojure.main Clojure 1.2.0 user= (compile 'clojure.examples.hello) java.io.IOException: No such file or directory (hello.clj:1) $ ls clojure/examples hello.clj $ cat clojure/examples/hello.clj (ns clojure.examples.hello (:gen-class)) (defn -main [greetee] (println (str Hello greetee !))) 1) What do I need to do to have the REPL find hello.clj ? 2) How can I AOT compile Clojure files without using the REPL? -- 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: AOT compilation newbie mistakes
On Aug 22, 3:06 pm, Robert McIntyre r...@mit.edu wrote: I feel like a lot of people have trouble with this (I certainly do!) so I made this tutorial with working examples to follow. this is by default the $PROJECT-DIR/classes folder Is there a way to set that default to something else? Maybe using -Dclojure.compile.path= -- 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: AOT compilation newbie mistakes
On Aug 22, 3:06 pm, Robert McIntyre r...@mit.edu wrote: I feel like a lot of people have trouble with this (I certainly do!) so I made this tutorial with working examples to follow. Thanks $ /usr/local/src/jdk1.6.0_18/bin/java -cp .:clojure.jar - Dclojure.compile.path=. clojure.main Clojure 1.2.0 user= (compile 'clojure.examples.hello) clojure.examples.hello $ /usr/local/src/jdk1.6.0_18/bin/java -cp clojure.jar clojure.examples.hello Fred Hello Fred! Is there are reason not to simplify further? $ cat hello.clj (ns hello (:gen-class)) (defn -main [greetee] (println (str Hello greetee !))) $ /usr/local/src/jdk1.6.0_18/bin/java -cp .:clojure.jar - Dclojure.compile.path=. clojure.main Clojure 1.2.0 user= (compile 'hello) hello $ /usr/local/src/jdk1.6.0_18/bin/java -cp clojure.jar hello John Hello John! -- 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: Pure-functional N-body benchmark implementation
On Aug 10, 3:00 pm, Andy Fingerhut andy_finger...@alum.wustl.edu wrote: On Aug 10, 2:19 pm, Jonathan Smith jonathansmith...@gmail.com wrote: 1.) use something mutable 2.) unroll all the loops (mapping is a loop) 3.) try not to coerce between seq/vec/hash-map too much. in real world, stuff like theshootoutis pretty useless, as generally you'd reach for a better algorithm rather than implementing the shackled, crippled, naive algorithms that the benchmark forces you to implement. (Not that they aren't useful to some extent, just that language productivity and how fast you can iterate your software design in the language is, IMO, a much better indicator of a good language than micro benchmarking). I agree that they are useful to some extent. In the real world, you would use a better algorithm, but those better algorithms can be implemented in any language, too. As you say, a higher level language that lets you iterate more quickly on multiple implementations of different algorithms has advantages. -snip- An opportunity to use Clojure to iterate quickly to an implementation that exploits all of the available cores? --~--~-~--~~~---~--~~ 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: Clojure performance tests and clojure a little slower than Java
On Jul 27, 2:26 pm, AndyF andy_finger...@alum.wustl.edu wrote: -snip- I thought it was interesting that even the Haskell entry to the k- nucleotide benchmark uses a *mutable* hash table (at least, I think they are from the discussion on the Wiki page linked below -- my Haskell knowledge isn't extensive enough to understand all of their code). I don't think that is idiomatic Haskell, but the people writing the Haskell entry are apparently willing to forego pure functional programming when they can get significantly better performance from a mutable data structure. Perhaps they understood that the way to have a program accepted was to have it do as asked - update a hashtable of k-nucleotide keys http://shootout.alioth.debian.org/u32q/benchmark.php?test=knucleotidelang=allbox=1#about --~--~-~--~~~---~--~~ 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: when performance matters
On Jan 13, 10:07 am, cliffc cli...@acm.org wrote: -snip- 5- The debianshootoutresults generally badly mis-represent Java. Most of them have runtimes that are too small (10sec) to show off the JIT, and generally don't use any of the features which commonly appear in large Java programs (heavy use of virtuals, deep class hierarchies, etc) for which the JIT does a lot of optimization. I give a public talk on the dangers of microbenchmarks and all the harnesses I've looked at in theshootoutfail basic sanity checks. Example: the fannkuch benchmark runs 5 secs in Java, somewhat faster in C++. Why does anybody care about a program which runs 5sec? I guess they wonder if somewhat faster might become 25 minutes as the workload increases ;-) usr+sys :: elapsed N=10 Java 0.756s :: 0.643s C++ 0.332s :: 0.099s N=11 Java 5.944s :: 1.859s C++ 3.540s :: 1.063s N=12 Java 74.689s :: 20.460s C++ 51.895s :: 14.167s N=13 Java 1083.592s :: 271.876s C++796.506s :: 199.856s N=14 Java 18015.666s :: 5296.275s C++ 12392.987s :: 3791.224s --~--~-~--~~~---~--~~ 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 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: when performance matters
On Jan 13, 10:07 am, cliffc cli...@acm.org wrote: Some comments: 1- If you think that HotSpot/Java is slower than C++ by any interesting amount, I'd love to see the test case. Being the architect of HotSpot -server I've a keen interest in where performance isn't on par with C. -snip- 5- The debianshootoutresults generally badly mis-represent Java. Most of them have runtimes that are too small (10sec) to show off the JIT, When you say most of the runtimes are 10sec I wonder what exactly you are looking at - on u32 u64, 6 of 13 are 10sec (on quadcore u32q u64q, 8 of 13 are 10sec). I'm always puzzled when I read something like have runtimes that are too small (10sec) because in my innocence it seems as though JIT gets to do a lot more in 10 sec on Q6600 than it did on Pentium 4 - am I just wrong about that? The benchmarks game has never aimed to show off the JIT anymore than it's aimed to show off C++ but - http://shootout.alioth.debian.org/gp4/miscfile.php?file=dynamictitle=Java%20Dynamic%20Compilation and generally don't use any of the features which commonly appear in large Java programs (heavy use of virtuals, deep class hierarchies, etc) for which the JIT does a lot of optimization. I think that has to be right although it seems like similar issues would apply to all the other programming languages, not just Java. your application is the ultimate benchmark http://shootout.alioth.debian.org/u32/miscfile.php?file=benchmarkingtitle=Flawed%20Benchmarks#app I give a public talk on the dangers of microbenchmarks and all the harnesses I've looked at in theshootoutfail basic sanity checks. Example: the fannkuch benchmark runs 5 secs in Java, somewhat faster in C++. Why does anybody care about a program which runs 5sec? Why does anybody care that a program runs 4sec rather than 6sec? (otoh those programs which run 10 minutes...) Of course you could choose other examples from the benchmarks game which show a Java program only a few tenths of a second from the fastest C++ program. (The reaction I frequently see is surprise that Java can be that close to C++). (there's other worse problems: e.g. the C++ code gets explicit constant array sizes hand-optimized via templates; the equivalent Java optimization isn't done but is trivial (declare 'n' as a *final* static var) and doing so greatly speeds up Java, etc). Which is to say that some of the programs are better than some of the other programs - isn't that always going to be the case? It's not obvious which Java fannkuch program you're talking about - my guess would be Java 6 -server rather than Java 6 -server #2 or Java 6 -server #4 (both of which seem to declare 'n' final but don't use all the cores) ? --~--~-~--~~~---~--~~ 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 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: when performance matters
On Jan 13, 4:30 am, Mark P pierh...@gmail.com wrote: On Jan 13, 5:49 pm, Zak Wilson zak.wil...@gmail.com wrote: You're probably thinking of this:http://www.flownet.com/gat/papers/lisp-java.pdf Thanks for the link. There's also the (in)famous language benchmark site:http://shootout.alioth.debian.org/ This is primarily what I was going on. I realize no benchmarking approach is going to be perfect, but this attempt doesn't seem too bad. Is there any reason to be particularly sceptical about results found here? Oh, and I realize my comments about SBCL lisp being 3 to 4 times slower than C++ only apply for the quad core machines. Notice which programs are using more than one core and which aren't. The single core machines have SBCL as 2.2 or 2.3 times slower than C++. Perhaps this is a truer representation of SBCL's raw capabilities. But a 120% performance hit is still quite a whack. Cheers, Mark P. --~--~-~--~~~---~--~~ 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 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: when performance matters
On Jan 13, 4:41 am, Eric Lavigne lavigne.e...@gmail.com wrote: There's also the (in)famous language benchmark site:http://shootout.alioth.debian.org/ This is primarily what I was going on. I realize no benchmarking approach is going to be perfect, but this attempt doesn't seem too bad. Is there any reason to be particularly sceptical about results found here? The programs are written by volunteers, so the languages which have people that care about the results (and spend more time writing optimized code for their language of choice) get a big boost in score. It's easy to see which languages have suffered from relative neglect - they're the ones where most of the programs were written by me and still haven't been re-written by anyone else :-) C# Mono, Mozart/Oz, PHP, Scala otoh Scheme programs by Matthew Flatt, Haskell programs by Don Stewart, Clean programs by John van Groningen, etc - wow! Results are also affected by whether relevant libraries (often highly optimized for speed and memory) are included in the language's standard library, as third party libraries can't be used in shootout submissions. Except when they can - pcre, libgmp Also, for many shootout problems, the answer can be determined at compile-time, so you are potentially testing an aspect of compilation optimization that is not so relevant for practical programming problems. I don't know of a better set of benchmark results to look at - I use the shootout results myself - but I would take them with a grain of salt. In the words of Simon Peyton-Jones - flawed, but available http://www.haskell.org/pipermail/haskell-cafe/2008-December/052589.html --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
