On Mar 24, 5:56 am, cliffc <cli...@acm.org> wrote:
> Some generic STM bits of wisdom:
>
> - STMs in "standard" languages (e.g. C, C++) suffer from having to
> track all memory references. THis overhead means the STM code
> typically starts 3x to 10x slower than non-STM code, which is a pretty
> stiff penalty to recover from. If you're only getting a 3x speedup on
> your 4-core machine, but you're starting 3x down then you're not
> ahead.
> - Abort/retry rates can commonly exceed 90% (e.g. 1-in-10 attempts
> succeeds)
> - There are very few languages w/real TM support, so "good" TM writing
> styles are still being figured out
> - THere are very few TM implementations, so "good" STM implementations
> are still being figured out - even the "good" feature set isn't really
> well known.
>
> - Clojure dodges several of these bullets (no need to track
> everything; already paying a high abstraction penalty (commonly), so
> the STM slowdown isn't really interestingly large (e.g. it's 3x over
> some base speed, not 3x on top of Clojure)
I don't think I quite understand the abstraction penalty here. Are
you saying that Clojure is on the order of 3x slower than Java & the
STM contributes little to that? Of the overhead, which parts do you
think are the most significant (ie, dynamic typing, forced
immutability, etc)?
>
> - I DO have a Clojure program where the retry/fail rate approaches
> 99.99%
Would you mind describing the scenario a little for this? I guess it
must be a highly contended transaction, but is the transaction large?
Is it possible to optimize it, or are you at the stage where 99% retry
is the best you can get?
I also wanted to comment on the inefficiencies of retrying a
transaction: If you have more hardware threads than logical threads,
retrying is probably free (memory contention might make the whole
system slow down though, so maybe not). If you have more logical
threads than hardware threads, then the work you lose from having to
retry may not be free - if you were to block instead of retry another
logical thread would be allowed to run. I can imagine if I were
tuning transactions I'd like the ability to mark a transaction as
exclusive - ie if I had a heavily contended large transaction & lots
of logical threads that were wanting to run, it might be better to
explicitly lock that guy, or perhaps only allow a couple of active
threads in the transaction.
Cheers,
Brad
--~--~---------~--~----~------------~-------~--~----~
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 to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
