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, 2013 at 2:06 PM, Marko Topolnik
> <marko.topol...@gmail.com<javascript:_e({}, 'cvml',
> 'marko.topol...@gmail.com');>
> > 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 host, in this case the JVM, requires quite a bit of
>>> thinking about type hints and casts. I think most of the challenges around
>>> are writing fast Clojure JVM code lie here. I note these issues are not
>>> present in ClojureScript ;)
>>>
>>
>> OK, but does that mean that at the end of the day, optimized
>> ClojureScript performance is head-to-head with optimized JVM Clojure in a
>> desktop/server side application?
>>
>
> I don't think we can ever really be head-to-head and performance varies
> between JS engines. V8 is particularly good - not surprising since it's
> from the same folks who worked on HotSpot.
>
> That, we try to get the performance of ClojureScript on V8 as close to
> Clojure on the JVM as we can without sacrificing performance on the other
> engines. I think we're doing OK and we're improving constantly.
>
>
>> 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 zero primitive
>> values out of a loop. How do you cope with those?
>>
>
> Some ideas for the first point:
>
> * atoms
> * implement efficient tuple type which uses mutation for multiple value
> return
>
> I suspect the second option will be pretty fast. Annoying, but that's a
> tradeoff with Clojure's mostly functional design.
>
> Second point, I think 1.5.0 addresses that to some degree thanks to
> Christophe.
>
>
>> When on the subject, the times are getting ripe for a full-length book
>> not about how handsome and elegant and FP-y Clojure is (we have plenty of
>> those), but a "terrorist's handbook" on writing performant Clojure. Can you
>> recommend any current material in that direction?
>>
>> -Marko
>>
>
> Heh, I always point out test.benchmark -
> http://github.com/clojure/test.benchmark. There's some horrifying stuff
> in there ;)
>
> David
>
--
--
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 group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
