3 ms·

An informative and lengthy discussion between two experts (Cliff Click of Azul Systems and Rich Hickey): http://www.azulsystems.com/blog/cliff-click/2008-05-27-

An informative and lengthy discussion between two experts (Cliff Click of Azul Systems and Rich Hickey): http://www.azulsystems.com/blog/cliff-click/2008-05-27-clojure-stms-vs-locks http://www.azulsystems.com/blog/cliff-click/2008-05-27-cloju...

cageface 16y ago
An interesting discussion but inconclusive. I agree with Rich that it would be very useful to have an established set of meaningful concurrency benchmarks. For example, I'd like to see if a Clojure solution of the benchmarks in the linked ACM paper can scale better than the solutions tested in the paper.
- swannodette 16y ago
  Except those ACM microbenchmarks are exactly the kind of fine-grained problems Rich Hickey specifically stated he's not trying to solve. For example http://dosync.posterous.com/stm-couchdb-and-pushing-5500-documentssecond http://dosync.posterous.com/stm-couchdb-and-pushing-5500-doc.... I added only 7 lines of code. Raw Aleph runs at about 20k req/s on an 8 core box. This code performs at about 14-18k req/s. So clearly some contention is at play. I could write this with locks, but I have better ways to spend my time. That's the real cost-to-benefit ratio.
  - cageface 16y ago
    Stuffing a bunch of things into a DB in parallel doesn't seem like a very interesting problem to solve to me. As discussed earlier, Clojure's concurrency primitives are only useful for a somewhat specific class of problems: computationally intensive tasks in a single shared memory space. The benchmarks in the ACM paper seem to me to have a lot more to do with the kinds of complex datastructures you're going to employ in those scenarios than batching writes to a key-value store.
- gtani 16y ago
  tehse 2 posts were useful in thinking about taxonomies/how to categorize concurrent/ threaded (and data parallel) tasks http://blog.ezyang.com/2010/07/graphs-not-grids/ http://blog.ezyang.com/2010/07/graphs-not-grids/ http://www.bluebytesoftware.com/blog/2010/07/12/ThoughtsOnImmutabilityAndConcurrency.aspx http://www.bluebytesoftware.com/blog/2010/07/12/ThoughtsOnIm...
runT1ME 16y ago
I think Cliff Click pretty much makes the best case in that argument that for complicated problems, STM doesn't offer a lot more than regular locks.

cageface 16y ago

An interesting discussion but inconclusive. I agree with Rich that it would be very useful to have an established set of meaningful concurrency benchmarks. For example, I'd like to see if a Clojure solution of the benchmarks in the linked ACM paper can scale better than the solutions tested in the paper.

swannodette 16y ago
Except those ACM microbenchmarks are exactly the kind of fine-grained problems Rich Hickey specifically stated he's not trying to solve. For example http://dosync.posterous.com/stm-couchdb-and-pushing-5500-documentssecond http://dosync.posterous.com/stm-couchdb-and-pushing-5500-doc.... I added only 7 lines of code. Raw Aleph runs at about 20k req/s on an 8 core box. This code performs at about 14-18k req/s. So clearly some contention is at play. I could write this with locks, but I have better ways to spend my time. That's the real cost-to-benefit ratio.
- cageface 16y ago
  Stuffing a bunch of things into a DB in parallel doesn't seem like a very interesting problem to solve to me. As discussed earlier, Clojure's concurrency primitives are only useful for a somewhat specific class of problems: computationally intensive tasks in a single shared memory space. The benchmarks in the ACM paper seem to me to have a lot more to do with the kinds of complex datastructures you're going to employ in those scenarios than batching writes to a key-value store.
gtani 16y ago
tehse 2 posts were useful in thinking about taxonomies/how to categorize concurrent/ threaded (and data parallel) tasks http://blog.ezyang.com/2010/07/graphs-not-grids/ http://blog.ezyang.com/2010/07/graphs-not-grids/ http://www.bluebytesoftware.com/blog/2010/07/12/ThoughtsOnImmutabilityAndConcurrency.aspx http://www.bluebytesoftware.com/blog/2010/07/12/ThoughtsOnIm...

runT1ME 16y ago

I think Cliff Click pretty much makes the best case in that argument that for complicated problems, STM doesn't offer a lot more than regular locks.