That's pretty encouraging! :-D
The language does work as advertised, but is still under development.
One shouldn't expect it to crush Java on speed, nor take full advantage
of multiple processors... yet.
Clojure is a language for the future, after all. It can only get
better. Whereas Java
On Dec 7, 2008, at 10:11 AM, Peter Wolf wrote:
> Shouldn't the number of processors on the test machine make a big
> difference to how fast it runs? Whereas, the Java version is only
> dependent on the clock rate of the individual processors.
Replacing the "map" call with "pmap" on a 2 core ma
Hmmm...
Looking at the code I see
(defn sum-trees [iterations depth]
(let [sum #(+ (check-tree (make-tree % depth))
(check-tree (make-tree (- %) depth)))]
(reduce + (map sum (range 1 (inc iterations))
Shouldn't expressing the algorithm as a REDUCE and MAP instea
On Sunday 07 December 2008 07:11, Peter Wolf wrote:
> I'm a n00b, but isn't the point of this language to be *faster* than
> Java?... at least on a multiprocessor machine.
I don't think performance is a particular criterion for the design of
this language. It's not unimportant, but the quality o
--- On Sun, 12/7/08, Peter Wolf wrote:
> I'm a n00b, but isn't the point of this language to
> be *faster* than Java?...
I don't believe so. My impression was that the point was to be *better* than
Java by: being a Lisp, being functional, and allowing safe and easy
multithreading/concurrency.
I'm a n00b, but isn't the point of this language to be *faster* than
Java?... at least on a multiprocessor machine.
Shouldn't the number of processors on the test machine make a big
difference to how fast it runs? Whereas, the Java version is only
dependent on the clock rate of the individual
Has anyone been able to use type hints to successfully close the last
bit of difference between the Clojure and Java version on this
benchmark?
On Sat, Dec 6, 2008 at 6:14 AM, PeterB <[EMAIL PROTECTED]> wrote:
> Running in Clojure REPL for java 1.6.0_11 with -server option:
>
> result: -2
> E
Thanks for all the suggestions!
This modified version is very close to that in the thread:
http://groups.google.com/group/clojure/browse_thread/thread/f0303a9e00b38529/99f02fef21721a2f?lnk=gst&q=alioth+tree#99f02fef21721a2f
(Thanks for pointing that out Meikel. I should have searched old
threads
On Dec 4, 7:09 pm, "Christian Vest Hansen" <[EMAIL PROTECTED]>
wrote:
> Ah, disregard that. I found the rules:
> http://shootout.alioth.debian.org/u32q/benchmark.php?test=binarytrees&lang=all#about
Yeah -- " this is an adaptation of a benchmark for testing GC so we
are interested in the whole tre
Ah, disregard that. I found the rules:
http://shootout.alioth.debian.org/u32q/benchmark.php?test=binarytrees&lang=all#about
On Fri, Dec 5, 2008 at 1:04 AM, Christian Vest Hansen
<[EMAIL PROTECTED]> wrote:
> Is it important that we build and deconstruct a complete tree in the
> process, or is mere
Is it important that we build and deconstruct a complete tree in the
process, or is merely getting the correct end result enough?
(defn checkTree [item depth]
(if (zero? depth)
item
(- (+ item (checkTree (- (* 2 item) 1) (dec depth)))
(checkTree (* 2 item) (dec depth)
(de
I already tried bOR's two suggestions (replace anonymous function with
+ and type hinting), but they made no difference on my machine.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this
using (int ..) should also help (type hinting)
--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email
> (reduce #(+ %1 %2) 0 (map sum (range 1 (inc iterations
can be replaced by (reduce + (map sum (range 1 (inc iterations
There is at least some functions in clojure's api for doing unchecked
calculations. That should speed up things. I'm not yet familiar
enough
with clojure or build
A couple quick suggestions:
On my machine, Peter's code runs in 120 seconds.
Changing make-tree to return vectors rather than lists reduced time to
47 seconds.
Taking out the nil? test (just (if tree branch1 branch2) shaved off a
few more seconds.
Removing the pattern-matching let in check-tree (
Hi,
Am 04.12.2008 um 20:55 schrieb PeterB:
However, there is a heavy price to be paid for this elegance:
'Elapsed time: 100730.161515 msecs'
Ouch! That's rather disappointing :-(
Any suggestions for improving the performance?
http://groups.google.com/group/clojure/browse_thread/thread/f0303a9
ahhh... to answer my own question (and if I had looked at the code
and the API a bit closer),
it turns out that "recur" can only be used in tail-position... and
your code (as a tree-recursor) would
not benefit from this.
On Dec 4, 5:39 pm, Daniel Eklund <[EMAIL PROTECTED]> wrote:
> oops...
>
>
oops...
I am just learning the language right now and just quickly looked
at what you did...
Would the use of "recur" instead of self-calls potentially help
consuming stack space?
http://clojure.org/special_forms#toc10
On Dec 4, 5:37 pm, Daniel Eklund <[EMAIL PROTECTED]> wrote:
> I
>
> On D
I
On Dec 4, 2:55 pm, PeterB <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I downloaded clojure_20080916.zip and had a go with a simple tree
> benchmark (cut-down version of the one in the computer language
> shootout http://shootout.alioth.debian.org/).
>
> The Java version is pretty simple and runs in a
Hi,
I downloaded clojure_20080916.zip and had a go with a simple tree
benchmark (cut-down version of the one in the computer language
shootout http://shootout.alioth.debian.org/).
The Java version is pretty simple and runs in about 2s on my laptop:
public class Main
{
public static void ma
20 matches
Mail list logo
