Re: Clojure Performance For Expensive Algorithms

ckOverflow. I am trying to > get an algorithm in Clojure to match Java speed and managed to get the > performance to within one order of magnitude and wondering if more is > possible. The full question is here: > > > http://stackoverflow.com/questions/14949705/clojure-p

Re: Clojure Performance For Expensive Algorithms

On Wednesday, February 27, 2013 2:46:25 PM UTC-8, Ben Mabey wrote: > > On 2/27/13 9:59 AM, Isaac Gouy wrote: > > (defn blank? [s] (every? #(Character/isWhitespace %) s)) >> >> Have you ever wondered about its performance? >> > > No. Why would I wonder about the performance of a one line co

Re: Clojure Performance For Expensive Algorithms

It's in the official API documentation. Yes, it's new with Clojure 1.5. On Friday, March 1, 2013 12:42:18 AM UTC+1, Geo wrote: > > I didn't know reduce could be short circuited! I assume from the code >

Re: Clojure Performance For Expensive Algorithms

I didn't know reduce could be short circuited! I assume from the code below this is done calling the function reduced? Is this in Clojure 1.5 only and is where is this documented? On Wednesday, February 27, 2013 4:59:33 AM UTC-5, Christophe Grand wrote: > > > On Wed, Feb 27, 2013 at 10:21 AM, Ma

Re: Clojure Performance For Expensive Algorithms

I beg to differ. You can't separate an assessment of idiomaticity from the specific problem domain. *That* is true no matter what the language. On Feb 27, 9:48 am, Marko Topolnik wrote: > On Wednesday, February 27, 2013 6:28:03 PM UTC+1, Andy Fingerhut wrote: > > If you wanted to create a colle

Re: Clojure Performance For Expensive Algorithms

On 2/27/13 9:59 AM, Isaac Gouy wrote: On Wednesday, February 27, 2013 1:13:10 AM UTC-8, Marko Topolnik wrote: On Wednesday, February 27, 2013 5:19:20 AM UTC+1, Isaac Gouy wrote: If idiomatic Clojure was used... The problem, of course, is that: the code one-person co

Re: Clojure Performance For Expensive Algorithms

On Wednesday, February 27, 2013 9:48:15 AM UTC-8, Marko Topolnik wrote: > However, if someone comes along with *(let [m (HashMap.)] (loop > []...(recur (.put m ...)))* claiming that is in fact idomatic, he's just > being unreasonable---by everyone's agreement. > You don't think there are fas

Re: Clojure Performance For Expensive Algorithms

On Wednesday, February 27, 2013 6:28:03 PM UTC+1, Andy Fingerhut wrote: If you wanted to create a collection of idiomatic Clojure programs for > solving a particular set of problems, e.g. the Benchmarks Game problems, as > soon as more than one person submitted a program and/or reviewed a progra

Re: Clojure Performance For Expensive Algorithms

On Feb 27, 2013, at 9:07 AM, Marko Topolnik wrote: > > > On Wednesday, February 27, 2013 5:59:25 PM UTC+1, Isaac Gouy wrote: > (defn blank? [s] (every? #(Character/isWhitespace %) s)) > > Have you ever wondered about its performance? > > No. Why would I wonder about the performance of a one

Re: Clojure Performance For Expensive Algorithms

And by "with little effort" I mean "with little effort compared to porting other languages to different platforms". Given 8 hour work days a single man can hack out Clojure on almost any platform in a few months. That's quite impressive considering how hard it would be to do the same for Ruby/Pyth

Re: Clojure Performance For Expensive Algorithms

Luc makes a good point. And that's one thing that I love about Clojure. It is possible to have (more or less) the same language on different platforms with different trade-offs, with little effort. Just look at the three examples we have now: Clojure - Pretty awesome performance + interop with all

Re: Clojure Performance For Expensive Algorithms

On Wednesday, February 27, 2013 5:59:25 PM UTC+1, Isaac Gouy wrote: > > (defn blank? [s] (every? #(Character/isWhitespace %) s)) >> >> Have you ever wondered about its performance? >> > > No. Why would I wonder about the performance of a one line code snippet > that was written without concern

Re: Clojure Performance For Expensive Algorithms

On Wednesday, February 27, 2013 5:17:16 PM UTC+1, Luc wrote: > > There's no magic. You cannot win on all fronts. > You defeatist, you :) I'm just trying to represent the enthusiastic perspective where "if it *could* be better, it *must* be better". In many respects Clojure already embodies exa

Re: Clojure Performance For Expensive Algorithms

On Wednesday, February 27, 2013 1:13:10 AM UTC-8, Marko Topolnik wrote: > > On Wednesday, February 27, 2013 5:19:20 AM UTC+1, Isaac Gouy wrote: > >> >> If idiomatic Clojure was used... >>> >> >> The problem, of course, is that: the code one-person considers to be >> idiomatic; another person con

Re: Clojure Performance For Expensive Algorithms

I disagree with your last statement. If you look backward, you will find that most languages were created with one or two strong influential ideas at the start. Many of them died of not being extendable to meet new concepts (Snobol, Algol, Simula, APL, ...) It did not prevent many of them to be

Re: Clojure Performance For Expensive Algorithms

On Wednesday, February 27, 2013 12:48:13 AM UTC+1, David Nolen wrote: > > Hang out with JRuby? Seriously? > > http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=clojure&lang2=jruby > Well, all the code-size bars are above the baseline :) Let's see how it fares when they dis

Re: Clojure Performance For Expensive Algorithms

In your specific case, where you want every last inch of performance, it is acceptable that you will need to use the optimized idiom. However, if your overall code did anything else besides banging hard against your algorithm, a performance say 5 times worse than Java may soon become acceptable.

Re: Clojure Performance For Expensive Algorithms

Well then lets stop trying to twist the code further. Commenting that Clojure "looses" in these benchmarks or is pushed in the same backyard than ruby is counter productive. What I have seen so far is pulling toward extreme contorsions to achieve better performance at the expense of code readabi

Re: Clojure Performance For Expensive Algorithms

On Wed, Feb 27, 2013 at 11:20 AM, Marko Topolnik wrote: > On Wednesday, February 27, 2013 10:59:33 AM UTC+1, Christophe Grand wrote: > >> >> Now that reduce can be short-circuited, redifining every?, some and al on >> top of it would yield some interesting gains: >> >> (defn revery? [pred coll] >>

Re: Clojure Performance For Expensive Algorithms

Hi, the recur is not for optimisation but for short-circuiting so that every? kind of works like and. Stoppable reduce allows now to exploit the internal reduce for strings while still keeping the short-circuiting of every?. Kind regards Meikel -- -- You received this message because you are

Re: Clojure Performance For Expensive Algorithms

On Wednesday, February 27, 2013 10:59:33 AM UTC+1, Christophe Grand wrote: > > Now that reduce can be short-circuited, redifining every?, some and al on > top of it would yield some interesting gains: > > (defn revery? [pred coll] > (reduce (fn [t x] > (if (pred x) > t

Re: Clojure Performance For Expensive Algorithms

On Wed, Feb 27, 2013 at 10:21 AM, Marko Topolnik wrote: > > (defn blank? [s] (every? #(Character/isWhitespace %) s)) >> >> Have you ever wondered about its performance? Here you go: >> >> user> (time (dotimes [_ 1] (blank? " >> "))) >> "Elapsed time: 3887.578 msecs" >> > > To give

Re: Clojure Performance For Expensive Algorithms

> (defn blank? [s] (every? #(Character/isWhitespace %) s)) > > Have you ever wondered about its performance? Here you go: > > user> (time (dotimes [_ 1] (blank? " > "))) > "Elapsed time: 3887.578 msecs" > To give a more complete picture, this vers

Re: Clojure Performance For Expensive Algorithms

On Wednesday, February 27, 2013 5:19:20 AM UTC+1, Isaac Gouy wrote: > > If idiomatic Clojure was used... >> > > The problem, of course, is that: the code one-person considers to be > idiomatic; another person considers to be idiotic, naïve. > Not really. Take Stuart Halloway's opening example i

Re: Clojure Performance For Expensive Algorithms

On Wednesday, February 27, 2013 12:53:14 AM UTC+1, Luc wrote: > > Why insist on getting Clojure to be at par with languages that may offer a > performance > boost on narrow problems at the expense of making parallel processing and > code > in general more complex everywhere else ? > This doe

Re: Clojure Performance For Expensive Algorithms

On Tuesday, February 26, 2013 12:50:17 PM UTC-8, Marko Topolnik wrote: > > Again, only the fastest entries are shown. > True, except for the special-case included to show that programs can be made slower (and sometimes more concise) -- the shortest C++ programs. If idiomatic Clojure was used

Re: Clojure Performance For Expensive Algorithms

I you attempt to mimic Java or C in some narrow linear compute bound algorithm, I agree that the resulting code is quite ugly, not idiomatic on top of having performance issues. Lucky for us not all the problems are bounded like this. I have been following this thread from the beginning and I ca

Re: Clojure Performance For Expensive Algorithms

On Tue, Feb 26, 2013 at 3:50 PM, Marko Topolnik wrote: > Things don't look very rosy for Clojure: it turns out to be about as > verbose as Java and significantly slower (this confirms my experience; > slightly slower than *regular* Java code, significantly slower than > highly optimized Java). If

Re: Clojure Performance For Expensive Algorithms

Clojure code should in principle be possible to execute very fast when using the same data structures. Clojure is much better behaved than languages like Ruby and Javascript from a compiler perspective. See for example the Stalin scheme compiler. It runs well written Scheme at almost C speed (s

Re: Clojure Performance For Expensive Algorithms

I've got a github repo with submissions for the Benchmarks Game web site for Java and Clojure, with several different Clojure programs for most problems: https://github.com/jafingerhut/clojure-benchmarks If people would like to submit what they consider idiomatic Clojure programs for any of

Re: Clojure Performance For Expensive Algorithms

I see; didn't notice that one. Again, only the fastest entries are shown. It appears that the same is the case with Marceau's graphs; he just didn't state that explicitly. Things don't look very rosy for Clojure: it turns out to be about as verbose as Java and significantly slower (this confirm

Re: Clojure Performance For Expensive Algorithms

As Issac pointed out, here are some very recent graphs (including Clojure): http://benchmarksgame.alioth.debian.org/u32/code-used-time-used-shapes.php On 2/26/13 2:35 AM, Marko Topolnik wrote: This is a great analysis, thanks for the link; shame it's so old. On Sunday, February 24, 2013 10:45:

Re: Clojure Performance For Expensive Algorithms

This is a great analysis, thanks for the link; shame it's so old. On Sunday, February 24, 2013 10:45:33 PM UTC+1, Ben Mabey wrote: > > > Yeah, I wish the Benchmarks allowed for idiomatic submissions and finely > tuned submissions. That would allow you to get some sort of an idea how > perform

Re: Clojure Performance For Expensive Algorithms

Hi, Nice solution, but don't we need to distinguish between the array types ? (cf. inline comment below ) Cheers, B. On Monday, February 25, 2013 12:08:39 AM UTC+1, Aria Haghighi wrote: > > […] Here, I think it's a macro you'll probably use all over the place, > arr-max, which will find the

Re: Clojure Performance For Expensive Algorithms

This is pretty neat. Thanks! Yeah the swapping of prev and curr seems to be a stumbling block. On Sunday, February 24, 2013 6:08:39 PM UTC-5, Aria Haghighi wrote: > > I have a solution (gist here https://gist.github.com/aria42/5026109, key > bits pasted below). It's pretty short (15 lines) and r

Re: Clojure Performance For Expensive Algorithms

On Sunday, February 24, 2013 1:45:33 PM UTC-8, Ben Mabey wrote: > > Yeah, I wish the Benchmarks allowed for idiomatic submissions and finely > tuned submissions. > So you wish the benchmarks game website would show, for example, both pi-digits programs that use BigInteger and pi-digits progra

Re: Clojure Performance For Expensive Algorithms

On Sunday, February 24, 2013 9:33:52 AM UTC-8, Marko Topolnik wrote: > > For example, Scala beats Java by a wide margin on some benchmarks. Turns > out it's because it uses JNI to solve the problem with the C bignum > library. > Turns out the benchmarks game website shows both Scala program

Re: Clojure Performance For Expensive Algorithms

I have a solution (gist here https://gist.github.com/aria42/5026109, key bits pasted below). It's pretty short (15 lines) and readable (I think) and only 50% slower than the Java version on my machine (averaging over 25 runs of your benchmark function). Generally, I've found it's really easy w

Re: Clojure Performance For Expensive Algorithms

On 2/24/13 1:34 PM, Marko Topolnik wrote: I'm no Haskell expert, but it doesn't take much Googling to give strong evidence that the answer is "yes, you can get mutability in Haskell". Search through this Haskell program on the Benchmarks Game site for occurrences of the string "

Re: Clojure Performance For Expensive Algorithms

On Sunday, February 24, 2013 9:45:18 PM UTC+1, Marko Topolnik wrote: > > > > On Sunday, February 24, 2013 9:15:45 PM UTC+1, puzzler wrote: >> >> >> As I mentioned before, I'm generally happy with Clojure's performance, >> but the few times I've had performance problems, I ended up rewriting the

Re: Clojure Performance For Expensive Algorithms

On Sunday, February 24, 2013 9:15:45 PM UTC+1, puzzler wrote: > > > As I mentioned before, I'm generally happy with Clojure's performance, but > the few times I've had performance problems, I ended up rewriting the code > at least three different ways in order to try to find the magic combinati

Re: Clojure Performance For Expensive Algorithms

> I'm no Haskell expert, but it doesn't take much Googling to give strong > evidence that the answer is "yes, you can get mutability in Haskell". > Search through this Haskell program on the Benchmarks Game site for > occurrences of the string "unsafe". > I see; quite disgusting :) > In m

Re: Clojure Performance For Expensive Algorithms

On Sun, Feb 24, 2013 at 5:50 AM, bernardH wrote: > FWIW, I, for one, am really glad that Clojure allows us to select > precisely which nice tools we want (have to) throw away (persistent data > structures, dynamic typing, synchronized) when the need arises. Reminds me > of the "don't pay for what

Re: Clojure Performance For Expensive Algorithms

On Feb 24, 2013, at 9:33 AM, Marko Topolnik wrote: > > Take a look at any of the Common Lisp or Haskell submissions to the Computer > Language Benchmarks Game web site, and you will see some programs that are > nowhere near what people typically write in those languages, and certainly > not w

Re: Clojure Performance For Expensive Algorithms

> > from what I hear, idiomatic Haskell is a performance devil as well > > Does this mean very good, or very bad? > It means the same as in "speed devil" :) > On a related note, is there currently any way to get the Clojure compiler > to tell you where boxing is occurring, like *warn-on-re

Re: Clojure Performance For Expensive Algorithms

> Take a look at any of the Common Lisp or Haskell submissions to the > Computer Language Benchmarks Game web site, and you will see some programs > that are nowhere near what people typically write in those languages, and > certainly not what people would write if they weren't concerned with

Re: Clojure Performance For Expensive Algorithms

On Feb 24, 2013, at 8:46 AM, Marko Topolnik wrote: > On Sunday, February 24, 2013 2:50:01 PM UTC+1, bernardH wrote: > FWIW, I, for one, am really glad that Clojure allows us to select precisely > which nice tools we want (have to) throw away (persistent data structures, > dynamic typing, synchro

Re: Clojure Performance For Expensive Algorithms

On Feb 24, 2013, at 10:46 , Marko Topolnik wrote: > from what I hear, idiomatic Haskell is a performance devil as well Does this mean very good, or very bad? On a related note, is there currently any way to get the Clojure compiler to tell you where boxing is occurring, like *warn-on-reflectio

Re: Clojure Performance For Expensive Algorithms

On Sunday, February 24, 2013 4:27:34 PM UTC+1, Geo wrote: > At the moment I don't find the Clojure solution simple, but again this may > simply be to lack of exposure. Have you written a lot of performance > optimized Clojure? > Yes, that's the catch, isn't it? If we had to write Clojure in the

Re: Clojure Performance For Expensive Algorithms

On Sunday, February 24, 2013 2:50:01 PM UTC+1, bernardH wrote: > FWIW, I, for one, am really glad that Clojure allows us to select > precisely which nice tools we want (have to) throw away (persistent data > structures, dynamic typing, synchronized) when the need arises. Reminds me > of the "do

Re: Clojure Performance For Expensive Algorithms

Well I'll just say that my opinion on this matter is not well formed at the moment since this is the first time I have encountered this issue. For now I've stuck with the Java algorithm so I can move on with my project, but I do plan to revisit this at some point. In fact, it may be important fo

Re: Clojure Performance For Expensive Algorithms

On Thursday, February 21, 2013 10:27:11 PM UTC+1, Geo wrote: > > Man, this is exactly how I feel after all this tinkering! It was great for > learning Clojure a bit more in depth, but in the end I am going to stick > with the Java solution. Especially since it's so easy to mix Java and > Cloju

Re: Clojure Performance For Expensive Algorithms

am cross-posting my Clojure question from StackOverflow. I am trying >> to get an algorithm in Clojure to match Java speed and managed to get the >> performance to within one order of magnitude and wondering if more is >> possible. The full question is here: >> >> >

Re: Clojure Performance For Expensive Algorithms

get the > performance to within one order of magnitude and wondering if more is > possible. The full question is here: > > > http://stackoverflow.com/questions/14949705/clojure-performance-for-expensive-algorithms > > Thank you. > -- -- You received this message because you

Re: Clojure Performance For Expensive Algorithms

Just wanted to say I am getting a lot out of this discussion. -- -- 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 you

Re: Clojure Performance For Expensive Algorithms

Stack analysis is quite a brittle mechanism, as far as I'm aware of. As soon as you pass the object to any method, even if private, the object will not be stack-allocated. The way Clojure code is typically written, and the way it is compiled, some method call will almost certainly get involved.

Re: Clojure Performance For Expensive Algorithms

:) On the other hand, the Common Lisp movement of the '80s was brimming with the can-do attitude of achieving native performance. From Steele, Gabriel, *The Evolution of Lisp*: the two strongest voices—Steele and Gabriel—were feeling their oats over > their ability to write a powerful compiler

Re: Clojure Performance For Expensive Algorithms

Lisp programmers know the value of everything and the cost of nothing ;) On Saturday, February 23, 2013, Marko Topolnik wrote: > I tend to think clojure is in a similar position - fast enough for the >> vast majority of things (ymmv of course - depending on what your domain is) >> and if you meet

Re: Clojure Performance For Expensive Algorithms

>From my (admittedly limited) experience with Scala, yes, you can freely use reassignable local vars and write pretty much the same loops as in Java, but on the other hand there are many non-obvious performance pitfalls (like simply using the built-in *for comprehension*) and the optimized libra

Re: Clojure Performance For Expensive Algorithms

> > I tend to think clojure is in a similar position - fast enough for the > vast majority of things (ymmv of course - depending on what your domain is) > and if you meet a situation like this where optimising the clojure becomes > too ugly, you can drop down to Java (or indeed C!) > Not quite

Re: Clojure Performance For Expensive Algorithms

On Fri, Feb 22, 2013 at 7:47 PM, Korny Sietsma wrote: > Isn't that always the way, though? Build your program in a powerful, > expressive language, then profile it, find the critical parts, and optimise > them - where possible in the same language, and where that's too > ugly/painful, drop down a

Re: Clojure Performance For Expensive Algorithms

Isn't that always the way, though? Build your program in a powerful, expressive language, then profile it, find the critical parts, and optimise them - where possible in the same language, and where that's too ugly/painful, drop down a layer to a lower level language. I did lots of this in the lat

Re: Clojure Performance For Expensive Algorithms

It wouldn't be a first for me, either; I'm already accustomed to writing macros for performance. For example, unrolling writer.append loops, using "jassoc" as a Java HashMap replacement for assoc, and many similar tricks. On this particular occasion, where the performance-critical code segment

Re: Clojure Performance For Expensive Algorithms

Oh right, sorry, you don't want to pay for boxing the double. Yeah this is the case where you'd want to go with a tuple. If this really was common in my own code I would probably write a mutable tuple macro. But I totally understand why someone else might just write the Java if they just want perfo

Re: Clojure Performance For Expensive Algorithms

OK, though threading one 3 element object array into the loop with one double cast doesn't really seem that problematic or slow to me. On Fri, Feb 22, 2013 at 3:27 PM, Marko Topolnik wrote: > On Friday, February 22, 2013 8:41:15 PM UTC+1, David Nolen wrote: > >> Er re: assigning stack based loca

Re: Clojure Performance For Expensive Algorithms

On Friday, February 22, 2013 8:41:15 PM UTC+1, David Nolen wrote: > Er re: assigning stack based locals. Forget wasting time making a tuple > type, probably best to just do that with a small mutable array. This > worked ok for us when porting some Java persistent data structure code to > Clojur

Re: Clojure Performance For Expensive Algorithms

On Friday, February 22, 2013 9:04:31 PM UTC+1, David Nolen wrote: > On Friday, February 22, 2013, Marko Topolnik wrote: >> >> >> Annoying *and* slower than Java's locals, unfortunately. Most of the >> time it won't make a huge dent in the performance, but I just happen to >> have an inner loop t

Re: Clojure Performance For Expensive Algorithms

On Friday, February 22, 2013, Marko Topolnik wrote: > > > Annoying *and* slower than Java's locals, unfortunately. Most of the time > it won't make a huge dent in the performance, but I just happen to have an > inner loop that iterates between zero and three times only, zero being by > far the most

Re: Clojure Performance For Expensive Algorithms

On Friday, February 22, 2013 8:44:30 PM UTC+1, Marko Topolnik wrote: > > > >> * implement efficient tuple type which uses mutation for multiple value >> return >> > > Basically, this is the ^:unsynchronized-mutable that we just mentioned :) > This is much better, but still it's not stack-base

Re: Clojure Performance For Expensive Algorithms

On Friday, February 22, 2013 8:23:38 PM UTC+1, David Nolen wrote: > > > >> I'll give you one specific item that I keep tripping upon: the lack of >> reassignable, stack-based locals. Without them I can't efficiently get more >> than one value out of a loop. Another item is that I can get zer

Re: Clojure Performance For Expensive Algorithms

Er re: assigning stack based locals. Forget wasting time making a tuple type, probably best to just do that with a small mutable array. This worked ok for us when porting some Java persistent data structure code to ClojureScript. On Friday, February 22, 2013, David Nolen wrote: > On Fri, Feb 22,

Re: Clojure Performance For Expensive Algorithms

On Fri, Feb 22, 2013 at 2:06 PM, Marko Topolnik wrote: > > Fair enough. My point was simply that Clojure implementations have a small >> learnable subset that performs well when performance is desired - >> primitives, loops, arrays, deftypes, etc regardless of host. It's >> unfortunate that the ho

Re: Clojure Performance For Expensive Algorithms

> > It's right there in the docstring of deftype, but OK. ...followed by several sentences of big fat warnings, including that they are present only to facilitate the building of higher level constructs, such as Clojure's reference types, in Clojure itself. Other than that, you are right, it

Re: Clojure Performance For Expensive Algorithms

On Fri, Feb 22, 2013 at 3:43 AM, Marko Topolnik wrote: > > My 5-year experience with Clojure (since 0.9) hasn't helped me to see it > that way. > I've been doing Clojure for about 5 years as well. Optimizing Clojure in the early days was pretty tough stuff, and resorting to Java was pretty much n

Re: Clojure Performance For Expensive Algorithms

That would exactly be my point, too: I want to write idiomatic Clojure and have the underlying runtime make it perform; that's what I get with Java. I don't want to twist the compiler's arm into producing the bytecode that I can get from straightforward Java code. Incidentally, it happens that

Re: Clojure Performance For Expensive Algorithms

I'd look at it the other way around. It would be good if someone did this, so that it would change around in the next release, and I won't have to have any lasting insight into the performant Clojure. I wasn't the OP, BTW, although I suspect he and I share a profession. String matching algorithms

Re: Clojure Performance For Expensive Algorithms

Perhaps it's time to hit the decompiler :) AOT compile and apply javap; do the same for a comparable Java version. This will be a time-consuming and frustrating experience and it won't bring you lasting insight into performant Clojure because things will change around in the next release. On Fr

Re: Clojure Performance For Expensive Algorithms

Marko Topolnik writes: >> Christophe's version also has the advantage that it can pretty much >> compile down to efficient JavaScript via ClojureScript and probably an >> efficient ClojureCLR program as well. This may or may not matter to you. >> > Apparently even Cristophe broke quite a bit of

Re: Clojure Performance For Expensive Algorithms

On Thursday, February 21, 2013 10:49:42 PM UTC+1, David Nolen wrote: > > On Thu, Feb 21, 2013 at 4:55 AM, Marko Topolnik > > > wrote: > >> Whatever the final performance achieved, the fact remains that the >> original Java code was much cleaner, simpler, and more comprehensible than >> the big

Re: Clojure Performance For Expensive Algorithms

This thread made me realize there's quite a bit of low hanging compatibility fruit between Clojure & ClojureScript, so as of this changeset http://github.com/clojure/clojurescript/compare/4652498035...3c0fb6ef5f We can now compile Christophe's example code in ClojureScript w/ exactly 4 minor chang

Re: Clojure Performance For Expensive Algorithms

Man, this is exactly how I feel after all this tinkering! It was great for learning Clojure a bit more in depth, but in the end I am going to stick with the Java solution. Especially since it's so easy to mix Java and Clojure in the same project! I just specify :java-source-paths ["src/java"] i

Re: Clojure Performance For Expensive Algorithms

Ah, yes, thought it was wrong somewhere! Stephen Compall writes: > On Feb 20, 2013 5:55 AM, "Phillip Lord" > wrote: >> (do >>(assoc curr (inc j) 0) >>(recur (inc j) max-len))) > > Here you're discarding the result of assoc

Re: Clojure Performance For Expensive Algorithms

Whatever the final performance achieved, the fact remains that the original Java code was much cleaner, simpler, and more comprehensible than the big ball of mud the performant Clojure version is turning into. I have my own piece of performance-critical code that I used to maintain and improve

Re: Clojure Performance For Expensive Algorithms

I updated my answer on SO, with a deftype-based one that gives me an additional 30% boost. On Tue, Feb 19, 2013 at 6:38 PM, Geo wrote: > What about the call to .equals? > > > On Tuesday, February 19, 2013 12:20:28 PM UTC-5, Marko Topolnik wrote: >> >> The difference between String[] and Object[

Re: Clojure Performance For Expensive Algorithms

On Feb 20, 2013 5:55 AM, "Phillip Lord" wrote: > (do >(assoc curr (inc j) 0) >(recur (inc j) max-len))) Here you're discarding the result of assoc, a pure function, which changes the code's nature significantly. >

Re: Clojure Performance For Expensive Algorithms

re: > > http://stackoverflow.com/questions/14949705/clojure-performance-for-expensive-algorithms So, I was curious about this. So, you've done everything using java arrays. What would happen if you used clojure data structures. So I tried this instead. (defn lcs-native [n1 n2] (let [n1-le

Re: Clojure Performance For Expensive Algorithms

Cool. Thanks for the explanation. On Tuesday, February 19, 2013 12:47:05 PM UTC-5, Marko Topolnik wrote: > > Naturally, it's Object#equals. String's override of equals gets involved > without the checked downcast. > > On Tuesday, February 19, 2013 6:38:07 PM UTC+1, Geo wrote: >> >> What about the

Re: Clojure Performance For Expensive Algorithms

Naturally, it's Object#equals. String's override of equals gets involved without the checked downcast. On Tuesday, February 19, 2013 6:38:07 PM UTC+1, Geo wrote: > > What about the call to .equals? > > On Tuesday, February 19, 2013 12:20:28 PM UTC-5, Marko Topolnik wrote: >> >> The difference bet

Re: Clojure Performance For Expensive Algorithms

What about the call to .equals? On Tuesday, February 19, 2013 12:20:28 PM UTC-5, Marko Topolnik wrote: > > The difference between String[] and Object[] is that a member of the > former doesn't need a checked cast to String, but the latter does need one. > In the code under consideration, however

Re: Clojure Performance For Expensive Algorithms

The difference between String[] and Object[] is that a member of the former doesn't need a checked cast to String, but the latter does need one. In the code under consideration, however, nothing specific to String is used, so even in the Java code you can freely replace String[] with Object[] an

Re: Clojure Performance For Expensive Algorithms

Note that I'm not very confident that using long-array instead of int-array is a true improvement vs. just noise. On Tuesday, February 19, 2013 11:46:21 AM UTC-5, Geo wrote: > > Using long-array instead of int-array seems to produce a very slight but > noticeable improvement. (~2.1 sec -> ~1.8 s

Re: Clojure Performance For Expensive Algorithms

^objects is a Clojure synonym for ^"[Ljava.lang.Object;". Note that there are such synonyms for only a few Java types, not everything, e.g. there is no ^strings. What you are hinting is that a1 and a2 are Java arrays of objects. I think this might speed up (aget a1 i) expressions, since it is

Re: Clojure Performance For Expensive Algorithms

One thing I don't get is that switching the type hints from [#^"[Ljava.lang.String;" a1 #^"[Ljava.lang.String;" a2] to [^objects a1 ^objects a2] didn't seem to have any negative impact on performance. Can anyone explain why hinting ^objects is just as good as specifying that it's an array of S

Re: Clojure Performance For Expensive Algorithms

Using long-array instead of int-array seems to produce a very slight but noticeable improvement. (~2.1 sec -> ~1.8 sec) = 1.16x improvement One other thing is that loop seems to return boxed primitives, so by wrapping the inner loop with (long ) I got another slight performance gain. (~2.5 sec

Re: Clojure Performance For Expensive Algorithms

the > performance to within one order of magnitude and wondering if more is > possible. The full question is here: > > > > > http://stackoverflow.com/questions/14949705/clojure-performance-for-expensive-algorithms > > > > > Thank you. > -- -- You receive

Re: Clojure Performance For Expensive Algorithms

Another idea: try using arrays of longs, rather than ints, since that is what Clojure prefers. -- -- 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 moder

Re: Clojure Performance For Expensive Algorithms

m trying to > get an algorithm in Clojure to match Java speed and managed to get the > performance to within one order of magnitude and wondering if more is > possible. The full question is here: > > http://stackoverflow.com/questions/14949705/clojure-performance-for-expensive-algo

Clojure Performance For Expensive Algorithms

/questions/14949705/clojure-performance-for-expensive-algorithms Thank you. -- -- 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