A bunch of separate real concerns here:
---
On the issue of STM Slowdown:
- Clojure is typically slower than Java by an interesting amount when
doing Plain Olde Java Stuff, unless great care is taken (it's possible
to take great care). Such a slowdown matters less than the ability t
On Tue, Mar 24, 2009 at 11:40 PM, Howard Lewis Ship wrote:
>
> A relevant question is: what is the relative cost of locking and
> blocking (in the pure Java approach) vs. the cost of retrying (in the
> Clojure/STM approach).
I can't think, off the top of my head, of a fair way to compare the
two
>
> I don't want to go out on a limb, having not looked at the Clojure STM
> implementation. However, I would bet that the costs are roughly equal.
> Even if Clojure was 50% slower, or 100% slower, the knowlege that you
> can spin up a large number of threads and not worry about deadlocks is
> ulti
A relevant question is: what is the relative cost of locking and
blocking (in the pure Java approach) vs. the cost of retrying (in the
Clojure/STM approach).
I don't want to go out on a limb, having not looked at the Clojure STM
implementation. However, I would bet that the costs are roughly equa
I think Cliff may mean that each STM-participating memory access is 3x
slower, but in Clojure, because of immutability, a very small
proportion of accesses are Ref accesses, whereas in C/C++ *all* memory
accesses would be.
I agree that there's lots of room for adding instrumentation to
Clojure's
On Mar 24, 5:56 am, cliffc 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 t
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 spe
As was described in a "Software Engineering Radio" podcast on
transactional memory, there are many parallels between garbage
collection and transactional memory. Some parallels that aren't in
place yet though include:
1) There are tools to measure the impact of GC on runs of an
application, but w
On Mon, 2009-03-23 at 14:49 -0500, Cosmin Stejerean wrote:
>
>
> The fact that B is tried once concurrently with A, and is then aborted
> and retried is in my opinion the same as transaction B being stuck
> waiting on a lock while A is being processed, but I can see how trying
> B concurrently
On Mon, Mar 23, 2009 at 2:36 PM, Mark Volkmann wrote:
>
> > In the case where two transactions need to modify the same Ref they
> > definitely to be serialized, either by explicitly using locks in Java, or
> by
> > letting Clojure automatically retry one of them. In either case it about
> the
> >
> that was happening? I know I could insert my own code to track that,
> but it seems like this may be a commonly needed tool for Clojure to
> detect excessive conflicts/retries in transactions. Maybe we could set
> a special variable like *track-retries* that would cause Clojure to
> produce a te
On Mon, Mar 23, 2009 at 11:19 AM, Cosmin Stejerean wrote:
>
> On Sun, Mar 22, 2009 at 9:12 PM, Mark Volkmann
> wrote:
>>
>> I'm trying to understand the degree to which Clojure's STM provides
>> more concurrency than Java's blocking approach. I know it's difficult
>> to make generalizations and
On Sun, Mar 22, 2009 at 9:12 PM, Mark Volkmann wrote:
>
> I'm trying to understand the degree to which Clojure's STM provides
> more concurrency than Java's blocking approach. I know it's difficult
> to make generalizations and that specific applications need to be
> measured, but I'll give it a g
i think it would be awesome if someone worked up a scenario . . . started
using regular old java . . . and we could walk into a few gotchas,
publicly/transparently, where a serious java guy could chime in ... and
really see what the stm buys. Then we'd have an even richer appreciation
for the STM
I'm trying to understand the degree to which Clojure's STM provides
more concurrency than Java's blocking approach. I know it's difficult
to make generalizations and that specific applications need to be
measured, but I'll give it a go anyway.
Clearly using STM (dosync with Refs) makes code easie
15 matches
Mail list logo
