I believe the performance problems boil down to the abysmal
performance of bit-shift-right and bit-and in Clojure 1.3 alpha 1.
I'll post this in a separate thread to make sure it gets read.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to
As a side note, I notice that in clojure 1.3, bit-shift-left now
provides wraparound logic with no warning if the first input is a long
(as opposed to a bigint).
Wouldn't it be more consistent if bit-shift-left provided an overflow
error for long inputs that shift so much they overflow? Should
Hi Mark,
I tested the change to expt-int. Unfortunately, still no performance
gain.
I'm afraid I don't have a solid enough grasp of Clojure to know what
tweaks are needed to get performance fast again. Do you think you'll
have time to play with 1.3 soon?
On Sep 27, 1:00 am, Mark Engelberg
Thanks for the info. I'd need to research how clojure.lang.BigInt
differs from java.math.BigInteger, but I'm sure that adding the extra
case for BigInt in the multimethods wouldn't be too hard.
I'm still stumped as to why expt and sqrt would be 100x slower. My
first thought is that the
I found that even without patching, most functions in
clojure.contrib.math already correctly handle big nums in 1.3:
Handles big nums in 1.3?
absYes
ceil Yes
exact-integer-sqrt No
expt No
floor Yes
gcdYes
lcm
Your code was simple enough for me to make a couple of educated guesses. For
more complex code I'd use VisualVM, https://visualvm.dev.java.net/
David
I use that too.
Sampling for a first look, profiling with instrumentation for a more
precise answer.
(Here, the sampling gives even? and the
Thanks Eric :) Have you considered submitting that change as a patch?
On Sep 24, 5:35 pm, Eric Lavigne lavigne.e...@gmail.com wrote:
I think I read somewhere that max-key applies f more times than is
necessary, so should not be pass any f that takes significant time to
compute.
Yes,
I went through the rest of my Project Euler code. In addition to
even?, there are some functions in clojure.contrib that are also much
slower in 1.3 Alpha 1.
clojure.contrib.math - expt
(Clojure 1.2)
user= (time (doseq [x (range 10)] (expt x 2)))
Elapsed time: 119.417971 msecs
http://code.google.com/p/clojure/issues/detail?id=95
I just looked over this code. You can speed it up even more by
manually encoding the loop, rather than using reduce.
(defn faster-max-key
([k x] x)
([k x more]
(loop [x x,
kx (k x)
s more]
(if-not s x
On Sat, Sep 25, 2010 at 7:02 PM, Btsai benny.t...@gmail.com wrote:
I went through the rest of my Project Euler code. In addition to
even?, there are some functions in clojure.contrib that are also much
slower in 1.3 Alpha 1.
clojure.contrib.math - expt
(Clojure 1.2)
user= (time (doseq
Awesome, thanks :)
On Sep 25, 8:44 pm, Mark Engelberg mark.engelb...@gmail.com wrote:
http://code.google.com/p/clojure/issues/detail?id=95
I just looked over this code. You can speed it up even more by
manually encoding the loop, rather than using reduce.
(defn faster-max-key
([k x] x)
I haven't tried 1.3 yet, but I'd recommend downloading a copy of
clojure.contrib.math locally and replace any instances of +, -, *,
inc, dec with +', -', *', inc', dec'. This should at least make the
functions produce the correct results. I'd be curious to know whether
performance continues
FYI, I tried re-writing count-terms using loop/recur, but it didn't
really make a difference:
(defn count-terms-recur [n]
(loop [n n
count 1]
(cond
(= 1 n) count
(even? n) (recur (/ n 2) (inc count))
:else (recur (inc (* n 3)) (inc count)
Clojure 1.2 = 1153.43
(defn next-term [n]
(if (= (mod n 2) 0) (/ n 2)
(inc (* n 3
(defn count-terms [n]
(if (= 1 n) 1
(inc (count-terms (next-term n)
(time
(let [pair (juxt identity count-terms)
pairs (map pair (range 1 10))]
(println (first (apply max-key second pairs)
It
After profiling even seems effectively the culprit.
Some method reflector shows up too.
On Fri, Sep 24, 2010 at 6:15 PM, David Nolen dnolen.li...@gmail.com wrote:
(defn next-term [n]
(if (= (mod n 2) 0) (/ n 2)
(inc (* n 3
(defn count-terms [n]
(if (= 1 n) 1
(inc
Try
(defn even?
Returns true if n is even, throws an exception if n is not an integer
{:added 1.0
:static true}
[n] (zero? (bit-and (long n) (long 1
before your example.
It is fast on my computer.
(I believe there is a reflective call, without the explicit cast.)
--
You received
David, Nicolas, thank you for finding the culprit so quickly :)
What profiling technique/tool did you use? I have some other code
that is also much slower in 1.3, and thought I'd take a crack at
finding the culprit myself before spamming the list again.
On Sep 24, 11:26 am, Nicolas Oury
On Fri, Sep 24, 2010 at 5:25 PM, Btsai benny.t...@gmail.com wrote:
David, Nicolas, thank you for finding the culprit so quickly :)
What profiling technique/tool did you use? I have some other code
that is also much slower in 1.3, and thought I'd take a crack at
finding the culprit myself
Thank you David. Time for me to dig in!
On Sep 24, 3:36 pm, David Nolen dnolen.li...@gmail.com wrote:
On Fri, Sep 24, 2010 at 5:25 PM, Btsai benny.t...@gmail.com wrote:
David, Nicolas, thank you for finding the culprit so quickly :)
What profiling technique/tool did you use? I have some
I think I read somewhere that max-key applies f more times than is
necessary, so should not be pass any f that takes significant time to
compute.
Yes, max-key calls f more times than necessary.
http://code.google.com/p/clojure/issues/detail?id=95
We ran into this problem yesterday on a
20 matches
Mail list logo
