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 wrote:
> On Mon
On Mon, Nov 22, 2010 at 5:00 AM, Ralph wrote:
> On the Programming Languages Comparison Site (http://
> shootout.alioth.debian.org/u64/benchmark.php?
> test=all&lang=clojure&lang2=fsharp), if you run the Clojure vs. F#
> comparison, Clojure scores about the same in speed as F# (but does use
> mor
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 funct
id 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 wrote:
> On Wed, Sep 1, 2010 at 9:46
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,
per
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 wrote:
>
>
> O
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'
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 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
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 cha
10 matches
Mail list logo