Re: Clojure benchmark memory use and future improvements (Re: Clojure vs F# performance)
Thanks, Ken. I've changed that in my program now. I've also found that one reason why the Clojure benchmarks on the shootout web site were using so much more memory than the corresponding Java programs (e.g. up to about 350 Mbytes for the fannkuch-redux benchmark program) is a combination of several factors: (1) the Clojure programs were generating garbage, i.e. allocating memory that later became unused. Even though the total amount of live objects at any one time was well under 4 MBytes for the fannkuch-redux benchmark program, for example, it was not being collected soon enough to keep the amount of resident memory low. (2) That combined with the default heap size and GC method used, when no special command line arguments were being used on the java command line, led to large measured memory usage. By selecting an appropriate maximum heap size using the -Xmx command line option, the maximum resident memory used by several of the Clojure (and also JRuby) programs have been reduced significantly. Several of the programs formerly had their memory use 30x the corresponding Java program. Now the worst case ratio of (Clojure memory use / Java memory use) is about 3x, and there are still several programs for which I haven't yet run the experiments to find an appropriate max heap size to use. After that happens, the average memory use of Clojure programs (and JRuby programs) will go down further. Here is a link where you can see the results for the one-core 32-bit benchmark machine, for example: http://shootout.alioth.debian.org/u32/benchmark.php?test=alllang=clojure Does anyone know a way from within a Java/Clojure program to determine which GC algorithm is currently in use? I'm curious what the default is when one is not specified on the command line, and accessing the one being used from inside of a program would be one good way to find out for sure. There doesn't seem to be anything returned by Runtime.getRuntime().getProperties() to indicate that. Andy On Mon, Nov 22, 2010 at 9:51 AM, Ken Wesson kwess...@gmail.com wrote: On Mon, Nov 22, 2010 at 11:47 AM, John Fingerhut andy.finger...@gmail.com wrote: max live=63.1 MB - The maximum heap size before any GC invocation was 63.1 MB. The name max live is probably not the best name for that value, since objects in heap before a GC begins are often not all live. You'll get a much better approximation to the concept of max live from the maximum heap size right AFTER any GC invocation. -- 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
Clojure benchmark memory use and future improvements (Re: Clojure vs F# performance)
On Mon, Nov 22, 2010 at 5:00 AM, Ralph grkunt...@gmail.com wrote: On the Programming Languages Comparison Site (http:// shootout.alioth.debian.org/u64/benchmark.php? test=alllang=clojurelang2=fsharp), if you run the Clojure vs. F# comparison, Clojure scores about the same in speed as F# (but does use more memory). As a preview of things to come soon, I've been focusing on adding instrumentation to my clojure-benchmarks github repository that measure memory usage. I realized some time ago that the reason many of the Clojure benchmark programs use so much memory is that the default JVM heap size is quite large. Thus if a Clojure program allocates memory *at all* in the main loop, and if you run that main loop long enough, it will fill up the available heap before a garbage collection is triggered. Such a program will be measured as using all of that memory, even though it didn't need it. The memory use measurements on the benchmark can in many cases be significantly reduced, with little or no increase in run time, by selecting an appropriate value for the JVM -Xmx maximum heap size parameter. I have some Perl programs I've hacked together that on Windows + Cygwin, Mac OS X, and Linux, will run a program multiple times while varying the -Xmx heap size limit. It first uses binary search to find the smallest heap size at which the program produces correct output, and then it does a sweep starting at that value X, and runs the program for several somewhat larger limits, to see if a small amount of additional heap space will reduce the GC time noticeably. While doing that, it is saving all of the details of the runs in an XML file, and printing summaries of a few statistics on the console. Below is an example of the console output running the k-nucleotide benchmark program on an input that is significantly smaller than the official benchmark input (I often run these programs on smaller input sizes during testing so I can get results without growing too much older in the process). I give a pretty detailed explanation of what this output means below that, in case you are curious. All of this is in the clojure-benchmarks github repo now, although I will be improving it some more for a while (parsing HotSpot GC log files better, parsing GC logs for JRockit, correcting the Max RSS calculations on Mac OS X 10.6.x, etc.) I'll warn you that the command line options are pretty numerous, but mostly documented. Testing so far has been limited to Mac OS X, Ubuntu Linux, and Windows + Cygwin. https://github.com/jafingerhut/clojure-benchmarks git clone git://github.com/jafingerhut/clojure-benchmarks.git Andy Fingerhut Example output from tmcurve program, with line numbers prepended for reference: 1 % ../bin/tmcurve --verbose --jvm-gc-stats --delta 8 --sorted-summary --results-file results.xml --min 1 --precision 1 --input input/medium-input.txt --output output/medium-clj-1.2-output.txt --check 'diff --strip-trailing-cr --brief output/medium-expected-output.txt %o' java -server -Xmx%mbm -classpath /Users/andy/lein/swank-clj-1.2.0/lib/clojure-1.2.0.jar:./obj/clj-1.2 knucleotide 1 2 Looking for smallest memory size that succeeds. 3 4 Max heap=128 MB succeed cpu=19.3 sec Max RSS=125.4 MB RSS-heap=-2.6 MB GC tot space=2847.5 MB time=0.7 sec max live=63.1 MB 5 Max heap=64 MB succeed cpu=20.517 sec Max RSS=103.9 MB RSS-heap=39.9 MB GC tot space=2860.7 MB time=1.0 sec max live=44.9 MB 6 Max heap=32 MB succeed cpu=62.947 sec Max RSS=87.8 MB RSS-heap=55.8 MB GC tot space=2871.1 MB time=43.7 sec max live=25.0 MB 7 Files output/medium-expected-output.txt and output/medium-clj-1.2-output.txt differ 8 check output cmd 'diff --strip-trailing-cr --brief output/medium-expected-output.txt output/medium-clj-1.2-output.txt' exited with error status 1 9 Copy of output file 'output/medium-clj-1.2-output.txt' (length 0 bytes) saved as 'measureproc-3JpxmO/5A7grwwKdK' 10 Max heap=16 MB fail cpu=4.077 sec Max RSS=58.7 MB RSS-heap=42.7 MB GC tot space=97.1 MB time=0.6 sec max live=11.6 MB 11 Now perform binary search on range [16,32] 12 Files output/medium-expected-output.txt and output/medium-clj-1.2-output.txt differ 13 check output cmd 'diff --strip-trailing-cr --brief output/medium-expected-output.txt output/medium-clj-1.2-output.txt' exited with error status 1 14 Copy of output file 'output/medium-clj-1.2-output.txt' (length 0 bytes) saved as 'measureproc-wzd8KX/_pSTbtcZc3' 15 Max heap=24 MB fail cpu=4.456 sec Max RSS=77.2 MB RSS-heap=53.2 MB GC tot space=97.1 MB time=0.8 sec max live=17.1 MB new range [24,32] 16 Files output/medium-expected-output.txt and output/medium-clj-1.2-output.txt differ 17 check output cmd 'diff --strip-trailing-cr --brief output/medium-expected-output.txt output/medium-clj-1.2-output.txt' exited with error status 1 18 Copy of output file 'output/medium-clj-1.2-output.txt' (length 0 bytes) saved as 'measureproc-BNjL9y/tLMKZ_tXVq' 19 Max heap=28 MB
Re: Clojure 1.2 and the Computer Language Benchmarks Game
I've got about 5 to 10 Clojure programs I've written for each of the 5 benchmark programs (many of which are only minor variations of each other, looking for ways to make it faster). If you care to see any of the others, they are on github here: http://github.com/jafingerhut/clojure-benchmarks There are definitely shorter Clojure programs that can solve these problems. In many cases (not necessarily all), those programs would also be slower, and/or use significantly more memory, than the ones on the web site. Some of the problems involve keeping large strings (tens or hundreds of megabytes, when using one byte for each ASCII character) in memory all at once, and in those cases, it is important not to represent them with the wrong data structure, or else your program won't be able to store it all in memory (e.g. a Clojure lazy seq of characters uses over 50 bytes to represent each element of the seq, at least on a machine with 64-bit pointers). 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. Andy On Thu, Sep 2, 2010 at 5:28 PM, Sean Corfield seancorfi...@gmail.comwrote: 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=alllang=clojurelang2=java 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! -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood -- 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
Most likely. That one I found somewhat annoying in that the checksum computation does depend upon the permutations being generated in a particular order. 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. 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 at http://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: Clojure 1.2 and the Computer Language Benchmarks Game
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. 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=alllang=clojurelang2=java 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=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 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: How to use Java array of primitive types as key of Clojure map?
Thanks! That worked for me. Understood on the precautions about these things not being immutable, and thus potentially unsafe as hash keys (and anything else that expects immutability, whether that is obvious or not). This raises the question in my mind -- will there be something in Clojure, perhaps for Clojure-in-Clojure, that allows any old Clojure programmer to create their own immutable types? Perhaps with deftype or some future extension of it? Sorry if this is widely known and I'm just behind the news, but I had read recently that a motivation for deftype is to get closer to the point where more of Clojure can be implemented in itself. I don't expect there to be *guarantees* provided by the compiler or run-time that the interface provided above a given API layer implements a persistent data structure, because that sounds impossible to guarantee in general. But the only guarantee that we have that Clojure vectors, maps, sequences, etc. are immutable and persistent is that the Java implementations correctly implement those features, with no automated checking of those properties. Thanks, Andy On Wed, Sep 1, 2010 at 7:11 AM, Stuart Halloway stuart.hallo...@gmail.comwrote: Be super-careful doing this. Java's array equality and hashCode are correct: since arrays are mutable, they are not values. So equals and hashCode are correctly identity-based. Also, 1.2's vector-of lets you have vectors of primitives, which may give you the perf you need. But, if you can ensure that the arrays will be used as values: (ns key (:require [clojure.string :as str])) (deftype Key [key] Object (equals [this other] (if (= (class this) (class other)) (java.util.Arrays/equals ^ints key ^ints (.key ^Key other)) false)) (hashCode [this] (java.util.Arrays/hashCode ^ints key)) (toString [this] (str/join \, (seq key (defn int-key [coll] (Key. (int-array (count coll) coll))) Stu Stuart Halloway Clojure/core http://clojure.com If you don't do anything special, and create several Java array of bytes (for example) and use them as keys in a Clojure map, the default hashCode and equals implementation will cause two arrays with identical contents to be treated as different keys in the map, unless they are also == in Java. I'd like to use Java byte arrays as keys in Clojure maps, but haven't been able to figure out how yet. I know that java.util.Arrays/hashCode and java.util.Arrays/equals have the behavior I want, so one way would be to get Clojure to somehow use those methods when given the byte arrays as keys. That led me to think of trying deftype to make my own type Key with the desired implementation of hashCode and equals. I'm using Clojure 1.2, and I don't see how to give the appropriate type hints to declare that something is a Java byte array. Here is one attempt for Java int arrays instead of Java byte arrays: (definterface IKey (^ints key []) (equals [other-key] Compare two Keys for value equality, i.e. same length and same bytes in array value) (hashCode [] Return a hash code that is the same for equal keys, and usually different for different keys)) (deftype Key [^ints key] IKey (key [this] key) (equals [this other-key] (let [^Key other other-key] (java.util.Arrays/equals key (.key other (hashCode [this] (java.util.Arrays/hashCode key)) Object (toString [this] (apply str (map char key When I try to evaluate the deftype statement, I get an error like this: java.lang.NoClassDefFoundError: java/lang/ints Same error if I replace ^ints with #^ints. If I leave out the type hints for the field key completely, I get the following error when trying to evaluate the deftype: java.lang.VerifyError: (class: user/Key, method: hashCode signature: ()Ljava/lang/Object;) Expecting to find object/array on stack I'm not wedded to deftype as being part of the solution. My real goal is as high performance way of using Java byte/int/some-native-type arrays as map keys, i.e. with no reflection warnings. Thanks, Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at
How to use Java array of primitive types as key of Clojure map?
If you don't do anything special, and create several Java array of bytes (for example) and use them as keys in a Clojure map, the default hashCode and equals implementation will cause two arrays with identical contents to be treated as different keys in the map, unless they are also == in Java. I'd like to use Java byte arrays as keys in Clojure maps, but haven't been able to figure out how yet. I know that java.util.Arrays/hashCode and java.util.Arrays/equals have the behavior I want, so one way would be to get Clojure to somehow use those methods when given the byte arrays as keys. That led me to think of trying deftype to make my own type Key with the desired implementation of hashCode and equals. I'm using Clojure 1.2, and I don't see how to give the appropriate type hints to declare that something is a Java byte array. Here is one attempt for Java int arrays instead of Java byte arrays: (definterface IKey (^ints key []) (equals [other-key] Compare two Keys for value equality, i.e. same length and same bytes in array value) (hashCode [] Return a hash code that is the same for equal keys, and usually different for different keys)) (deftype Key [^ints key] IKey (key [this] key) (equals [this other-key] (let [^Key other other-key] (java.util.Arrays/equals key (.key other (hashCode [this] (java.util.Arrays/hashCode key)) Object (toString [this] (apply str (map char key When I try to evaluate the deftype statement, I get an error like this: java.lang.NoClassDefFoundError: java/lang/ints Same error if I replace ^ints with #^ints. If I leave out the type hints for the field key completely, I get the following error when trying to evaluate the deftype: java.lang.VerifyError: (class: user/Key, method: hashCode signature: ()Ljava/lang/Object;) Expecting to find object/array on stack I'm not wedded to deftype as being part of the solution. My real goal is as high performance way of using Java byte/int/some-native-type arrays as map keys, i.e. with no reflection warnings. Thanks, Andy -- 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: Help speed up an inner loop?
Consider trying to use == in place of where you have =, which can be faster when comparing numbers for equality. Source for this and a few other performance tips: http://gnuvince.wordpress.com/2009/05/11/clojure-performance-tips/ Andy On Mon, Aug 30, 2010 at 11:46 PM, Robert McIntyre r...@mit.edu wrote: Ah, I see that I was mistaken about the timing. Sorry about that. After a lot of fiddling around, I cam up with this faster form: (defn countnl-lite [#^bytes buf] (areduce buf idx count (int 0) (if (= (clojure.lang.RT/aget buf idx) 10) (unchecked-add count 1) count))) Key points are initializing count to a primitive integer and directly calling clojure's aget to avoid an unnecessary integer cast. On my system: The unmodified countnl function takes ~ 180 msecs Without AOT compilation countnl-lite takes around 66 msecs With AOT compilation countnl-lite takes ~46 msecs The java method takes ~19 msecs. I've lost a factor of 2.25 somewhere and it makes me sad that I can't find it. I would be very interested if anyone could improve countnl-lite. --Robert McIntyre On Mon, Aug 30, 2010 at 8:41 PM, Alan a...@malloys.org wrote: I think this misses the point. Of course java, c, and clojure will all have roughly the same wall-clock time for this program, since it is dominated by the I/O. You can even see that in the output from $ time java Iterate: less than 0.5s was spent in user space, the rest was spent in system code - that is, mostly doing I/O. The java version is a second faster as counted by the wall clock, and this is unlikely to be a coincidence: tsuraan's timing data suggests that the clojure program takes 80ms longer in each loop, and loops 10 times. That comes out to 0.8 seconds, which is quite close to the differential you observed when timing from the command line. On Aug 30, 1:38 pm, Robert McIntyre r...@mit.edu wrote: I don't know what the heck is going here, but ignore the time the program is reporting and just pay attention to how long it actually takes wall-clock style and you'll see that your clojure and java programs already take the same time. Here are my findings: I saved Iterate.java into my rlm package and ran: time java -server rlm.Iterate results: time java -server rlm.Iterate Wanted 16777216 got 16777216 bytes counted 65341 nls in 27 msec Wanted 16777216 got 16777216 bytes counted 65310 nls in 27 msec Wanted 16777216 got 16777216 bytes counted 66026 nls in 21 msec Wanted 16777216 got 16777216 bytes counted 65473 nls in 19 msec Wanted 16777216 got 16777216 bytes counted 65679 nls in 19 msec Wanted 16777216 got 16777216 bytes counted 65739 nls in 19 msec Wanted 16777216 got 16777216 bytes counted 65310 nls in 21 msec Wanted 16777216 got 16777216 bytes counted 65810 nls in 18 msec Wanted 16777216 got 16777216 bytes counted 65531 nls in 21 msec Wanted 16777216 got 16777216 bytes counted 65418 nls in 21 msec real0m27.469s user0m0.472s sys 0m26.638s I wrapped the last bunch of commands in your clojure script into a (run) function: (defn run [] (let [ifs (FileInputStream. /dev/urandom) buf (make-array Byte/TYPE *numbytes*)] (dotimes [_ 10] (let [sz (.read ifs buf)] (println Wanted *numbytes* got sz bytes) (let [count (time (countnl buf))] (println Got count nls)) and ran (time (run)) at the repl: (time (run)) Wanted 16777216 got 16777216 bytes Elapsed time: 183.081975 msecs Got 65894 nls Wanted 16777216 got 16777216 bytes Elapsed time: 183.001814 msecs Got 65949 nls Wanted 16777216 got 16777216 bytes Elapsed time: 183.061934 msecs Got 65603 nls Wanted 16777216 got 16777216 bytes Elapsed time: 183.031131 msecs Got 65563 nls Wanted 16777216 got 16777216 bytes Elapsed time: 183.122567 msecs Got 65696 nls Wanted 16777216 got 16777216 bytes Elapsed time: 182.968066 msecs Got 65546 nls Wanted 16777216 got 16777216 bytes Elapsed time: 183.058508 msecs Got 65468 nls Wanted 16777216 got 16777216 bytes Elapsed time: 182.932395 msecs Got 65872 nls Wanted 16777216 got 16777216 bytes Elapsed time: 183.074646 msecs Got 65498 nls Wanted 16777216 got 16777216 bytes Elapsed time: 187.733636 msecs Got 65434 nls Elapsed time: 28510.331507 msecs nil Total running time for both programs is around 28 seconds. The java program seems to be incorrectly reporting it's time. --Robert McIntyre On Mon, Aug 30, 2010 at 4:03 PM, tsuraan tsur...@gmail.com wrote: Just to try to see if clojure is a practical language for doing byte-level work (parsing files, network streams, etc), I wrote a trivial function to iterate through a buffer of bytes and count all the newlines that it sees. For my testing, I've written a C version, a Java version, and a Clojure version. I'm running
Re: Clojure 1.2 and the Computer Language Benchmarks Game
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. 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
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 On Mon, Aug 23, 2010 at 10:29 AM, Isaac Gouy igo...@yahoo.com wrote: 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.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
