> An interesting founding is that it seems typecasting from short to int
> and asetting to an int-array is 3-4 times faster than typecasting from
> int to short and asetting to an short array.
Thought: Java primitive types, when manipulated individually, are all
"secretly ints" — there is no re
An interesting founding is that it seems typecasting from short to int
and asetting to an int-array is 3-4 times faster than typecasting from
int to short and asetting to an short array.
On Sep 8, 9:33 am, evandi wrote:
> I think the problem is the typecasting and the bit-shifting. I think
> bot
Hi, evandi:
I've tried to use aset to write to a short array, and there's no
typecasting and bit-shifting, but it is still slow.
But if I write to a int array, it will be more than two times faster.
Therefore, maybe 'aset' is optimized only for 'int' ?
On Sep 8, 9:33 am, evandi wrote:
> I thi
I think the problem is the typecasting and the bit-shifting. I think
both involve casting one of the parameters to a java.lang.Number.
On Sep 7, 5:03 am, rivercheng wrote:
> Hi, icemaze:
>
> With trying the following code, I found now Clojure is only around 15
> times slower than Java. (java6 -s
I think the problem is the typecasting and the bit-shifting. I think
both involve casting one of the parameters to a java.lang.Number.
On Sep 7, 5:03 am, rivercheng wrote:
> Hi, icemaze:
>
> With trying the following code, I found now Clojure is only around 15
> times slower than Java. (java6 -s
Hello,
On Mon, Sep 7, 2009 at 7:36 PM, Jonathan
Smith wrote:
>
> Are we sure that it is the aset-* operation that is causing a slowdown
> and not the fact that the aset-* operations are not being inlined,
> whereas the regular aset operation is?
aset-* uses java.lang.reflect.Array and is really
Are we sure that it is the aset-* operation that is causing a slowdown
and not the fact that the aset-* operations are not being inlined,
whereas the regular aset operation is?
If so, the aset-* ops might be faster, and just in need of a small
update!
A lot of the time when something is slower t
> On Sep 7, 4:27 pm, B Smith-Mannschott wrote:
[snip]
>>
>> Questions about how best to optimize clojure code to approach java
>> performance have come up with fair regularity in the past. You might
>> find some good ideas if you search through the archives a bit.
>>
>> That said, Clojure is a dy
Hi, icemaze:
With trying the following code, I found now Clojure is only around 15
times slower than Java. (java6 -server)
"Elapsed time: 76.134661 msecs"
"Elapsed time: 9.509398 msecs"
"Elapsed time: 15.137116 msecs"
"Elapsed time: 1.827812 msecs"
"Elapsed time: 14.477701 msecs"
"Elapsed time:
Due to Clojure's extremely easy integration with Java, your suggestion
makes a lot of sense. But there's still a problem:
it requires everyone learns Clojure has to know Java (not only the
platform, but also the syntax). Moreover,
once we combine the compiled language and script language (just lik
@Christophe: thanks, your hint helped.
@B Smith-Mannschott:
> Questions about how best to optimize clojure code to approach java
> performance have come up with fair regularity in the past. You might
> find some good ideas if you search through the archives a bit.
I see.
As I said before (OP),
On Sun, 6 Sep 2009 07:54:33 -0700 (PDT)
Andy Fingerhut wrote:
>
> Is there any reason to keep aset-* functions around in Clojure? I
> guess backwards compatibility?
>
> It definitely seems worth flagging them when *warn-on-reflection* is
> true, in a similar way to other warnings it enables.
On Sun, Sep 6, 2009 at 16:29, icemaze wrote:
>
> Hello!
>
> First of all, let me congratulate with the devs for their great work:
> I've been using Clojure for just a couple of weeks and I had a lot of
> fun learning it and experimenting with it.
> I'm starting a concurrency-heavy project and I fe
Hello
words is not of a primitive type. Try:
(defn shorts-to-bytes [#^shorts src #^bytes dst words]
(let [words (int words)]
(loop [src-offset (int 0)
dst-offset (int 0)]
(when (< src-offset words)
(let [sample (short (aget src src-offset))]
(aset dst dst
Try unchecked-inc and try wrapping the function body in (let [words (int
words)] ... ).
I don't know why aset is still reflecting when all of the arguments are
type-hinted, but the above changes might speed up some other bits of the
code.
--~--~-~--~~~---~--~~
You r
Besides using just aset, try using unchecked-inc instead of inc.
--~--~-~--~~~---~--~~
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 m
Nicholas,
thank you for your reply. I applied the change you suggested.
Unfortunately it skimmed only about 50ms from each exectuion.
Even though I'm using aset, java.lang.reflect.Array.setByte *still*
uses ~25% of execution time. This means two things: A) Reflection is
still used for this code.
Is there any reason to keep aset-* functions around in Clojure? I
guess backwards compatibility?
It definitely seems worth flagging them when *warn-on-reflection* is
true, in a similar way to other warnings it enables. Perhaps that
might be overloading the meaning of *warn-on-reflection*, but I
Hello,
> (aset-byte dst dst-offset (byte sample))
Most of the time, aset is faster than aset-TYPE. Especially when, like here,
types are known.
If you profile your code, you should see most of the time is in
Reflect.Array.set or something similar, and that should disappear
if you want
Hello!
First of all, let me congratulate with the devs for their great work:
I've been using Clojure for just a couple of weeks and I had a lot of
fun learning it and experimenting with it.
I'm starting a concurrency-heavy project and I feel Clojure is gonna
be a great choice!
I'm thinking about
20 matches
Mail list logo
