On Jul 1, 5:42 pm, Greg wrote:
> Ooo... sorry for the side-question, but I noticed that your code doesn't seem
> to use coercions for primitives and uses type-hints instead.
>
> I was just asking the other day on #clojure why Clojure had coercion
> functions at all and why type hints didn't work
On Jul 1, 6:24 pm, "Heinz N. Gies" wrote:
> One reason here is that clojures literals as 1 2 and 3 you use for array
> indexes are longs, the aget methods want int's
Agreed. If we can take the profiling snapshot I linked to at face
value, the boxing and casting adds up to ~40% of the CPU time.
G
Ooo... sorry for the side-question, but I noticed that your code doesn't seem
to use coercions for primitives and uses type-hints instead.
I was just asking the other day on #clojure why Clojure had coercion functions
at all and why type hints didn't work for primitives, does this mean 1.2 will
> I did:
> "Java arrays 18s" is Java arrays in Clojure.
> "Plain Java 2s" is Java arrays in Java.
One reason here is that clojures literals as 1 2 and 3 you use for array
indexes are longs, the aget methods want int's so you've funny casting there
which is slow for comparison I've done it on a p
I did:
"Java arrays 18s" is Java arrays in Clojure.
"Plain Java 2s" is Java arrays in Java.
Here's the Java code: http://gist.github.com/460063
That's what you meant, right?
I agree that it looks very good :)
"Mutable deftype" is a special case in that apart from the dotimes
loop counter all nu
On Thu, Jul 1, 2010 at 2:27 AM, j-g-faustus wrote:
> Using the equiv branch, I get
> * Java arrays: 18s
> * Immutable deftype: 10s
> * Mutable deftype: 2s
> * Plain Java: 2s
>
That's a very encouraging result! That proves that the equiv branch, and
deftypes, can be as fast as java.
Could you tes
I'm getting some form of boxing during array access, even on the equiv
branch.
Speaking of which: (type (+ 1N 1)) => clojure.lang.BigInt means that
I'm using the correct branch, right?
Here is a simple speed test comparing 3-element vectors using Java
arrays, immutable deftype and mutable deftype
OK, I'll try again. Thanks.
jf
On Jun 30, 6:14 pm, David Nolen wrote:
> On Wed, Jun 30, 2010 at 10:19 AM, j-g-faustus
> wrote:
>
>
>
>
>
> > Tried the equiv branch briefly: The "1.1 style" version is ~4%
> > quicker, but still ~4x slower than Java and ~2x slower than mutable
> > deftype.
>
> > B
$ java -version
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode)
Running the bechmark with -client or -server flag makes just a couple
of percent difference in timing.
On Jun 30, 5:20 pm, Ni
On Wed, Jun 30, 2010 at 10:19 AM, j-g-faustus
wrote:
> Tried the equiv branch briefly: The "1.1 style" version is ~4%
> quicker, but still ~4x slower than Java and ~2x slower than mutable
> deftype.
>
> But I found another issue: Array access apparently converts primitives
> to boxed values at eve
On Wed, Jun 30, 2010 at 3:19 PM, j-g-faustus wrote:
>
> The number of calls to Double.valueOf(double) seems to suggest that it
> is called only on aset, not on aget, though I can't think of any
> reason how that could be.
>
> Does anyone know more about this?
Do you use the client or server Hots
Tried the equiv branch briefly: The "1.1 style" version is ~4%
quicker, but still ~4x slower than Java and ~2x slower than mutable
deftype.
But I found another issue: Array access apparently converts primitives
to boxed values at every access. This is perhaps because aget/aset is
a function and pr
On Jun 29, 8:05 pm, j-g-faustus wrote:
> Definterface and defprotocol, on the other hand
Correction: definterface and deftype.
--
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 po
On Tue, Jun 29, 2010 at 2:05 PM, j-g-faustus wrote:
> OK, I tried this. Object field access instead of arrays made a few
> percent difference, but not enough to be significant.
>
> Definterface and defprotocol, on the other hand, not only gave cleaner
> code but was more than twice as fast. A huge
OK, I tried this. Object field access instead of arrays made a few
percent difference, but not enough to be significant.
Definterface and defprotocol, on the other hand, not only gave cleaner
code but was more than twice as fast. A huge win if you ask me :)
So summarizing this particular benchmar
Well, it gives a baseline to compare 1.2 improvements against. In
terms of speed, convenience or readability.
On Jun 28, 8:02 pm, Aaron Cohen wrote:
> Doing these tests on clojure 1.1, while self-enlightening, is kind of
> missing the point.
--
You received this message because you are subscrib
On Sun, Jun 27, 2010 at 10:59 PM, j-g-faustus
wrote:
> Whatever JVM flag tweaks can be done for Clojure can be done for Java
> too, and I'm primarily interested in relative performance, which I
> suppose is roughly the same as long as I use the same flags for both.
>
That's not exactly true. Cloj
Doing these tests on clojure 1.1, while self-enlightening, is kind of
missing the point.
The current primitive work on master for 1.2 are trying to make optimizing
more practical, possible and less ugly. It's well known that 1.1
optimization is ugly at best and often not completely successful.
--
On Jun 27, 6:03 pm, Nicolas Oury wrote:
> Which Hotspot and flags do you use?
Sun JVM 1.6.0 64 bit, the one that comes bundled with OS X 10.6. No
flags.
Specifying something like "-server -Xms256M" shaves off a couple of
seconds (3-4%), but I haven't looked very closely at the options.
Whatever J
On Sat, Jun 26, 2010 at 6:56 PM, j-g-faustus wrote:
>
> On my machine this is about 4x slower than the shootout Java
> implementation. Using Java as the baseline and comparing my local
> results to the shootout timings, it puts Clojure 1.1 on par with
> Erlang, Go and OCaml.
>
> On profiling I hav
Possibly of interest here, although I've only tested it using Clojure
1.1:
I just did an implementation of the n-body problem from
http://shootout.alioth.debian.org/u32q/benchmark.php?test=nbody&lang=all
The fastest code I've managed so far is here:
http://github.com/j-g-faustus/Clojure-test-code
could you also give more info of the jvm/flags you use.
Especially I see you are on a mac where last time I checked the default was
the client HotSpot.
On Fri, Jun 25, 2010 at 12:18 PM, Heinz N. Gies wrote:
>
> On Jun 25, 2010, at 12:19 , Nicolas Oury wrote:
>
> > Have you tried manual copying
On Jun 25, 2010, at 12:19 , Nicolas Oury wrote:
> Have you tried manual copying of the perm array (as in the scala version)?
> It is probably not much better or worse, but it would be nice to have the
> same algorithm than scala, for comparaison purpose.
Yes the original version did that, the im
On Fri, Jun 25, 2010 at 8:20 AM, Mark Engelberg
wrote:
> When exactly did people start expecting Clojure to be as fast as Java
> and/or Scala?
>
> I seem to recall in one of the original Clojure videos, Rich talked
> about the relationship between Clojure and Java. There's a long
> history of C p
Have you tried manual copying of the perm array (as in the scala version)?
It is probably not much better or worse, but it would be nice to have the
same algorithm than scala, for comparaison purpose.
On Fri, Jun 25, 2010 at 10:10 AM, Heinz N. Gies wrote:
>
> On Jun 24, 2010, at 23:17 , David
On Jun 24, 2010, at 23:17 , David Nolen wrote:
> Don't have time to dive into this right now, but all I can say is now you are
> starting to have an idea what the "other side" looks like. The kind of hoop
> jumping you have to do get within 3x of Scala is absurd.
Yes to see what the "other side
On Thu, Jun 24, 2010 at 10:50 PM, Mark Engelberg
wrote:
> With respect to this particular benchmark, I don't think it will be
> possible to get idiomatic code in the same ballpark as Java, because
> if you use Clojure's vectors to store the permuted values, they will
> be boxed. Unless Clojure st
Mark,
I don't disagree with your message as a whole, but:
Once you start using mutable arrays and type hinting every single
variable, why aren't you just using Java?
The argument I've heard is this: there are two ways to get a fast
program in a slow-by-default language.
The first is Pytho
On Jun 24, 2010, at 10:50 PM, Mark Engelberg wrote:
> When exactly did people start expecting Clojure to be as fast as Java
> and/or Scala?
>
One of the earlier talk/video, the claim was clojure is between 1x to 3x of java
performance.
Fast math performance was touched on here also
http://www
When exactly did people start expecting Clojure to be as fast as Java
and/or Scala?
I seem to recall in one of the original Clojure videos, Rich talked
about the relationship between Clojure and Java. There's a long
history of C programmers dropping down to assembly, Python programmers
dropping d
If you want some ideas: http://gist.github.com/452032
This was posted earlier in the ML in an un-optimized Clojure form as taking
98secs while the Java version took about 16ms on the OP's machine. With
Rich's latest changes this optimized Clojure code runs in about 20-25ms on
my i7 laptop.
David
On 24 June 2010 23:17, David Nolen wrote:
> Don't have time to dive into this right now, but all I can say is now you
> are starting to have an idea what the "other side" looks like. The kind of
> hoop jumping you have to do get within 3x of Scala is absurd.
I have to admit this is true...
(With
On Thu, Jun 24, 2010 at 5:17 PM, David Nolen wrote:
> On Thu, Jun 24, 2010 at 5:08 PM, Heinz N. Gies wrote:
>
>> So out of curiosity I did some benchmarking of the new equal branch and
>> wanted to see how much I can get out of clojure if I push the limits. Now
>> that said I know equal isn't do
On Thu, Jun 24, 2010 at 5:08 PM, Heinz N. Gies wrote:
> So out of curiosity I did some benchmarking of the new equal branch and
> wanted to see how much I can get out of clojure if I push the limits. Now
> that said I know equal isn't done yet but I figured it won't hurt. Bad news
> first, despit
34 matches
Mail list logo
