On Aug 18, 7:34 am, Michael Jaaka
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 d
On Aug 18, 6:50 am, David Nolen 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 pointles
Below is a Clojure solution that runs in 8.58 microseconds on my
machine. I only did it for the 40, 3 case. Records are linked. The
list reduction solution runs in 23.4 and the element recursion in 27.3
--art
(defrecord Soldier [val r])
(def v (vec (map #(Soldier. % (inc %)) (range 40
(def v2
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.
On Aug 18, 3:50 pm, David Nolen wrote:
> The Clojure code posted there is pretty awful and shows a gross, gross
> misunderstanding of Clojure data types. I submi
On Thu, Aug 18, 2011 at 7:40 AM, Paulo Pinto wrote:
> Maybe Clojure code needs some type annotations.
Type annotations will not help this code at all.
David
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to cloj
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 per
Maybe Clojure code needs some type annotations.
On Aug 18, 9:40 am, Roberto Mannai wrote:
> Hello,
> I recently stumbled upon this
> page:http://java.dzone.com/articles/contrasting-performance
> They are comparing several languages (Java, Scala, Python, Erlang,
> Clojure, Ruby, Groovy, Javascrip
On Monday 02 February 2009 19:12:48 David Nolen wrote:
> Please do the list a favor and read the very long threads about
> performance.
I would be interested to see a Clojure port of my ray tracer benchmark:
http://www.ffconsultancy.com/languages/ray_tracer/
--
Dr Jon Harrop, Flying Frog Con
2009/2/3 Gregory Petrosyan :
> Here http://leonardo-m.livejournal.com/75825.html you can find similar
> microbenchmark. Java is more than 3х slower than Python's built-in
> integers, and more than 10x slower than GMPY ones. Seems like Java's
> BigIntegers have some problems with performance, hm?
Even more constructive is to take a real Python program that you've written
where you actually care about it's performance. Rewrite it Clojure. Do
some investigation about which parts seem slow to you. Spend some time on
this. Come back with some code and questions and you'll probably get some
On Feb 3, 12:50 pm, André Thieme wrote:
> Hi, welcome in the group.
> Can you please write that program in Java and see how well it
> performs for you?
Will try to compare Java and Clojure later.
Here http://leonardo-m.livejournal.com/75825.html you can find similar
microbenchmark. Java is mor
On 2 Feb., 16:35, Gregory Petrosyan
wrote:
> Clojure rev. 1173:
> user=> (defn fac [#^Integer n] (reduce * (range 1 (+ 1 n
> #'user/fac
> user=> (time (reduce + (map fac (range 1000
> "Elapsed time: 944.798019 msecs"
>
> Python 3.0:>>> import timeit
> >>> t=timeit.Timer('sum(fac(n) for n
On Feb 2, 10:29 pm, David Nolen wrote:
> Heh, this is a more reasoned reply than my own as it points out an actual
> implementation difference between Python and Clojure. And of course you
> might need arbitrary precision arithmetic in your program, but again this
> just reinforces the insignific
Heh, this is a more reasoned reply than my own as it points out an actual
implementation difference between Python and Clojure. And of course you
might need arbitrary precision arithmetic in your program, but again this
just reinforces the insignificance of microbenchmarks without some context
of w
Please do the list a favor and read the very long threads about performance.
You cannot expect to enter a new language run a microbenchmark you would
never see in a running programming and expect that to be anything like a
real comparison.
Here's something unlikely but far less so (something like
It is safe to assume that Python uses the GMP library for its infinite
precision math, no? This could be a big part of the explanation as, if
the language shootouts are to be believed, BigInteger and BigDecimal
have inferior performance when compared to what can be achieved with
GMP.
For problems
On 02.02.2009, at 16:35, Gregory Petrosyan wrote:
> Althrough I am new to Clojure, I like it a lot. Because it is
> advertised as native JVM language, I expected it to demostrate decent
> performance in simple numeric tests, so I decided to compare it to
> Python.
>
> Clojure rev. 1173:
> user=>
17 matches
Mail list logo
