Using the latest 1.3.0-master-SNAPSHOT:
user=> (time (let [a (int 3) b (int 5)] (dotimes [_ 100] (== a b
"Elapsed time: 3.355 msecs"
nil
user=> (time (let [a (int 3) b (int 5)] (dotimes [_ 100] (= a b
"Elapsed time: 3.884 msecs"
nil
Yay!
On Mon, Oct 18, 2010 at 2:40 PM, Jürgen Hö
2010/10/18 Dmitriy S. :
> On Oct 18, 5:46 pm, Jürgen Hötzel wrote:
>> Note the difference between "=" and "==", "=" will result in a cast to
>> the wrapped types for it's arguments.
>
> It seems that '=' is always slower than '==',
> even if types are primitive, look:
>
> Clojure 1.2.0
> user=> (t
On Oct 18, 5:46 pm, Jürgen Hötzel wrote:
> Note the difference between "=" and "==", "=" will result in a cast to
> the wrapped types for it's arguments.
It seems that '=' is always slower than '==',
even if types are primitive, look:
Clojure 1.2.0
user=> (time (let [a (int 3) b (int 5)] (dotime
On Oct 18, 5:46 pm, Jürgen Hötzel wrote:
> Note the difference between "=" and "==", "=" will result in a cast to
> the wrapped types for it's arguments.
It seems that '=' is always slower than '==',
even if types are primitive, look:
Clojure 1.2.0
user=> (time (let [a (int 3) b (int 5)] (dotime
2010/10/18 Dmitriy S. :
> On Oct 18, 3:07 pm, Jürgen Hötzel wrote:
>> > (defn sum [arr]
>> > (loop [i (int 0) s (int 0)]
>> > (if (= i *N*) s
>>
>> ^^^
>>
>> You still doing non-primitive ops here.
>
> Indeed, I overlooked that.
> But this was not the main cause of the trouble.
>
>> Al
On Oct 18, 5:15 pm, "nicolas.o...@gmail.com"
wrote:
> You can try == for numbers
17 msec (== ~idx (alength a#))
293 msec (= ~idx (alength a#))
Yes, it's the case.
I should have checked the API doc for the =/== difference.
Thank you very much.
Best regards,
Dmitriy
--
You received this mes
You can try == for numbers
--
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
On Oct 18, 4:44 pm, "nicolas.o...@gmail.com"
wrote:
> I happened to stumble on something like that in 1.2, with
> = slower than >=, which is in turn slower than zero?.
> (Even when everything is a primitive)
>
> I never really understood why and would be happy to understand it better.
> Dimitry, h
I happened to stumble on something like that in 1.2, with
= slower than >=, which is in turn slower than zero?.
(Even when everything is a primitive)
I never really understood why and would be happy to understand it better.
Dimitry, have you tryed to replace (= x y) by (zero? (- x u)), or with
an
On Oct 18, 3:07 pm, Jürgen Hötzel wrote:
> > (defn sum [arr]
> > (loop [i (int 0) s (int 0)]
> >(if (= i *N*) s
>
> ^^^
>
> You still doing non-primitive ops here.
Indeed, I overlooked that.
But this was not the main cause of the trouble.
> Also Check for areduce:
>
> (defn sum [^in
Hi,
(defn sum [^ints arr]
(areduce arr i ret (int 0)
(unchecked-add-int ret (aget arr i
2010/10/18 Dmitriy S. :
>
> (defn sum [arr]
> (loop [i (int 0) s (int 0)]
> (if (= i *N*) s
^^^
You still doing non-primitive ops here. Also Check for areduce:
(defn sum [^ints
Hi All,
I stuck with performance problem using Clojure.
It seems that when all the optimisation hints are used,
Clojure data processing is still much slower than Java.
In my simple test I sum up 16M of random integers 0 < n < 10.
The code is as follows (see below Java and C code, and the test
scr
12 matches
Mail list logo
