6 ms·

Concurrency's shysters

42 points by joubert 16y ago

lukev 16y ago
He's kind of tilting at windmills, here. It's true that there's a lot of hype about concurrency, etc. But take Clojure, which AFAIK is the only real system people are actually using that places STM front and center (except maybe something in Haskell land). Rich Hickey is the furthest thing possible from a shyster. For example, he never claimed that STM is faster than manual locks, just that it's an order of magnitude easier to write correct programs - which seems to be borne out in actual experience. Yes, there's a not-insignificant overhead. But for most programs it's still probably worth it. Similarly, the claim that STM isn't any good because most computational resources aren't memory is a complete red herring - STM is quite useful for memory management, and for other resources, well, find a different strategy. It doesn't stop STM from being quite useful in its domain. All in all, this sounds more of a luddite rant than a reasoned opinion. It reminds me of what I've read of the initial objections to managed memory or even high-level languages themselves. Of course a lot of the technology isn't there yet. Of course a lot of it is going to be rabbit trails that ultimately don't deliver. It still doesn't mean it's not the future.
- cageface 16y ago
  I don't think you can call one of the inventors of D-Trace a luddite, and the article was hardly a rant. If you agree that many resources that require serial access are not memory then I also don't see how STM is making your life significantly easier. Composing locks and transactions in the same system sounds much harder to me than just using locks. I think the jury is still out on the effectiveness of Clojure's concurrency model. It makes for nice short examples but I'm not aware of anything of any real complexity built on it yet.
  - lukev 16y ago
    I certainly didn't mean to insult the author of the article... I just meant that the tone of the article itself had the sort of curmudgeonly tone that a lot of really good system programmers have towards fancy new technologies in their infancy. All I mean to say is, some of those fancy new technologies do grow up to become quite useful. And STM is designed around memory access. If you're attempting to write a concurrent program, and you have heterogeneous resource types, shouldn't you use a strategy which is optimal for each one? An IO socket is a fundamentally different sort of thing than memory, and ought to be managed differently.
    - cageface 16y ago
      The ACM article he links is worth a read. It discusses the pitfalls of STM in greater depth and includes some real-world benchmarks.
  - pmjordan 16y ago
    the article was hardly a rant You'll have to admit it's extremely thin on actual arguments. There are lots of links to journal publications, but it would have helped to summarise their actual findings rather than hand-wave about "complexity". Composing locks and transactions in the same system sounds much harder to me than just using locks. I think the jury is still out on the effectiveness of Clojure's concurrency model. Actually, Clojure does address that by allowing you to compose transactions with agents. If you send messages to agents during a transaction, they will only receive the messages sent from the transaction attempt that successfully completed. This leads to a fairly natural state-change-then-I/O pattern where the agent locks the non-memory resource and operates on it.
    - cageface 16y ago
      You'll have to admit it's extremely thin on actual arguments. There are lots of links to journal publications, but it would have helped to summarise their actual findings rather than hand-wave about "complexity". It's a blog post. What do you expect? The ACM article he links to is excellent, with some very in-depth analysis and real benchmark numbers showing exactly where the overhead of STM is most onerous.
  - swannodette 16y ago
    Many of the arguments made here against STM (and in the linked papers) are nicely addressed by Clojure's specific implementation of STM. This article is from 2008, before Clojure was more widely known. More importantly, Clojure is wisely designed with several other equally useful concurrency mechanisms: atoms for serial access, promises for dataflow, pmap for divide and conquer, and agents for uncoordinated concurrent activities.
    - cageface 16y ago
      How specifically does Clojure's STM implementation avoid the pitfalls outlined in the ACM paper? How many real-world benchmarks do we have demonstrating Clojure's concurrency scaling?
      - swannodette 16y ago
        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.
- rbranson 16y ago
  Yeah, the same arguments against garbage collection. They are always leaky abstractions. It doesn't mean you can be a dumber programmer, it just means you can spend less time focused on problems ancillary to the core purpose of your software.
noelwelsh 16y ago
I disagree. I think the author is unjustifiably extrapolating conclusions from a C/kernel development world to the rest of software development. For example, a bunch of systems use the "green threads" model. Erlang SMP is one. Erlang SMP is unarguably successful. The referenced article on STM confuses parallelism with concurrency[1]. They test on a bunch of benchmarks that are mostly 1) not concurrent and 2) for performance rely on fast numeric operations that have a vastly different level of granularity to typical business ops. [1] Parallelism = speeding things up by using multiple cores. Concurrency = modelling a system that naturally has different activities going on at once. These are not the same thing.
- kscaldef 16y ago
  Erlang SMP is successful on one axis (ease of writing correct and reliable concurrent problems), but it seems to me that the argument in the article was about the performance costs of the model. And, at least as of a year or two ago, Erlang SMP did _not_ have good performance. There was a minimum factor of 2 overhead in total CPU usage just by turning on SMP, and heavily concurrent programs could run massively slower (http://shootout.alioth.debian.org/u64q/benchmark.php?test=chameneosredux&lang=all http://shootout.alioth.debian.org/u64q/benchmark.php?test=ch...). At least part of the problem is that there's no affinity between Erlang processes and scheduler threads (and, therefore, CPU/cores), so you've got constant cache misses. There's probably other issues as well. As the author says, it's a hard problem.
  - gtani 16y ago
    stackoverflow shows recent BEAM and secret incantation (I haven't tried this yet, maybe tonite) http://stackoverflow.com/questions/1996524/optimizing-performance-on-erlang-processes/1998048#1998048 http://stackoverflow.com/questions/1996524/optimizing-perfor...
    - kscaldef 16y ago
      There was definitely a lot of discussion of these issues going on the last time I was playing around with Erlang, so it's quite possible progress has been made. My recommendation is to take my comments with a grain of salt, and comments on stackoverflow, and micro-benchmarks; and do your own testing and tweaking for your workload.
rosejn 16y ago
I found it interesting that in the post he criticizes previous discussion of lock based concurrency, while not providing anything close to the level of analysis that he apparently requires of his fellow disputant. '“Locks are not modular and do not compose, and the association between locks and data is established mostly by convention.” Again, no data, no qualifiers, no study, no rationale, no evidence of experience trying to develop such systems...' It is well known that lock based concurrent libraries do not compose, and anyone writing articles about concurrency should not require an explanation of this central issue in the discussion[1]. Of course with millions of hours of developer investment in a centrally managed codebase like Solaris it is possible to achieve incredible parallelism with locks, but that isn't practical for the vast majority of modern software, which continues to use ever more external libraries. Clojure's STM paired with immutable data structures are an especially well suited combination that are unlike most of the research systems presented in this area. Of course there are additional resources that will have to be managed, such as access to I/O, but I would argue that access to I/O is by far the easier problem to deal with in comparison to concurrent access to memory - primarily because I/O devices are typically accessed serially so you can just queue up requests. [1]: Here's one explanation with a code example of why locks don't compose: http://www.drdobbs.com/article/printableArticle.jhtml;jsessionid=SQVVQ5O0S2ACLQE1GHOSKH4ATMY32JVN?articleId=202802983&dept_url=/cpp/ http://www.drdobbs.com/article/printableArticle.jhtml;jsessi...

42 points by joubert 16y ago

lukev 16y ago

He's kind of tilting at windmills, here. It's true that there's a lot of hype about concurrency, etc. But take Clojure, which AFAIK is the only real system people are actually using that places STM front and center (except maybe something in Haskell land). Rich Hickey is the furthest thing possible from a shyster. For example, he never claimed that STM is faster than manual locks, just that it's an order of magnitude easier to write correct programs - which seems to be borne out in actual experience. Yes, there's a not-insignificant overhead. But for most programs it's still probably worth it. Similarly, the claim that STM isn't any good because most computational resources aren't memory is a complete red herring - STM is quite useful for memory management, and for other resources, well, find a different strategy. It doesn't stop STM from being quite useful in its domain. All in all, this sounds more of a luddite rant than a reasoned opinion. It reminds me of what I've read of the initial objections to managed memory or even high-level languages themselves. Of course a lot of the technology isn't there yet. Of course a lot of it is going to be rabbit trails that ultimately don't deliver. It still doesn't mean it's not the future.

cageface 16y ago
I don't think you can call one of the inventors of D-Trace a luddite, and the article was hardly a rant. If you agree that many resources that require serial access are not memory then I also don't see how STM is making your life significantly easier. Composing locks and transactions in the same system sounds much harder to me than just using locks. I think the jury is still out on the effectiveness of Clojure's concurrency model. It makes for nice short examples but I'm not aware of anything of any real complexity built on it yet.
- lukev 16y ago
  I certainly didn't mean to insult the author of the article... I just meant that the tone of the article itself had the sort of curmudgeonly tone that a lot of really good system programmers have towards fancy new technologies in their infancy. All I mean to say is, some of those fancy new technologies do grow up to become quite useful. And STM is designed around memory access. If you're attempting to write a concurrent program, and you have heterogeneous resource types, shouldn't you use a strategy which is optimal for each one? An IO socket is a fundamentally different sort of thing than memory, and ought to be managed differently.
  - cageface 16y ago
    The ACM article he links is worth a read. It discusses the pitfalls of STM in greater depth and includes some real-world benchmarks.
- pmjordan 16y ago
  the article was hardly a rant You'll have to admit it's extremely thin on actual arguments. There are lots of links to journal publications, but it would have helped to summarise their actual findings rather than hand-wave about "complexity". Composing locks and transactions in the same system sounds much harder to me than just using locks. I think the jury is still out on the effectiveness of Clojure's concurrency model. Actually, Clojure does address that by allowing you to compose transactions with agents. If you send messages to agents during a transaction, they will only receive the messages sent from the transaction attempt that successfully completed. This leads to a fairly natural state-change-then-I/O pattern where the agent locks the non-memory resource and operates on it.
  - cageface 16y ago
    You'll have to admit it's extremely thin on actual arguments. There are lots of links to journal publications, but it would have helped to summarise their actual findings rather than hand-wave about "complexity". It's a blog post. What do you expect? The ACM article he links to is excellent, with some very in-depth analysis and real benchmark numbers showing exactly where the overhead of STM is most onerous.
- swannodette 16y ago
  Many of the arguments made here against STM (and in the linked papers) are nicely addressed by Clojure's specific implementation of STM. This article is from 2008, before Clojure was more widely known. More importantly, Clojure is wisely designed with several other equally useful concurrency mechanisms: atoms for serial access, promises for dataflow, pmap for divide and conquer, and agents for uncoordinated concurrent activities.
  - cageface 16y ago
    How specifically does Clojure's STM implementation avoid the pitfalls outlined in the ACM paper? How many real-world benchmarks do we have demonstrating Clojure's concurrency scaling?
    - swannodette 16y ago
      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.
rbranson 16y ago
Yeah, the same arguments against garbage collection. They are always leaky abstractions. It doesn't mean you can be a dumber programmer, it just means you can spend less time focused on problems ancillary to the core purpose of your software.

noelwelsh 16y ago

I disagree. I think the author is unjustifiably extrapolating conclusions from a C/kernel development world to the rest of software development. For example, a bunch of systems use the "green threads" model. Erlang SMP is one. Erlang SMP is unarguably successful. The referenced article on STM confuses parallelism with concurrency[1]. They test on a bunch of benchmarks that are mostly 1) not concurrent and 2) for performance rely on fast numeric operations that have a vastly different level of granularity to typical business ops. [1] Parallelism = speeding things up by using multiple cores. Concurrency = modelling a system that naturally has different activities going on at once. These are not the same thing.

kscaldef 16y ago
Erlang SMP is successful on one axis (ease of writing correct and reliable concurrent problems), but it seems to me that the argument in the article was about the performance costs of the model. And, at least as of a year or two ago, Erlang SMP did _not_ have good performance. There was a minimum factor of 2 overhead in total CPU usage just by turning on SMP, and heavily concurrent programs could run massively slower (http://shootout.alioth.debian.org/u64q/benchmark.php?test=chameneosredux&lang=all http://shootout.alioth.debian.org/u64q/benchmark.php?test=ch...). At least part of the problem is that there's no affinity between Erlang processes and scheduler threads (and, therefore, CPU/cores), so you've got constant cache misses. There's probably other issues as well. As the author says, it's a hard problem.
- gtani 16y ago
  stackoverflow shows recent BEAM and secret incantation (I haven't tried this yet, maybe tonite) http://stackoverflow.com/questions/1996524/optimizing-performance-on-erlang-processes/1998048#1998048 http://stackoverflow.com/questions/1996524/optimizing-perfor...
  - kscaldef 16y ago
    There was definitely a lot of discussion of these issues going on the last time I was playing around with Erlang, so it's quite possible progress has been made. My recommendation is to take my comments with a grain of salt, and comments on stackoverflow, and micro-benchmarks; and do your own testing and tweaking for your workload.

rosejn 16y ago

I found it interesting that in the post he criticizes previous discussion of lock based concurrency, while not providing anything close to the level of analysis that he apparently requires of his fellow disputant. '“Locks are not modular and do not compose, and the association between locks and data is established mostly by convention.” Again, no data, no qualifiers, no study, no rationale, no evidence of experience trying to develop such systems...' It is well known that lock based concurrent libraries do not compose, and anyone writing articles about concurrency should not require an explanation of this central issue in the discussion[1]. Of course with millions of hours of developer investment in a centrally managed codebase like Solaris it is possible to achieve incredible parallelism with locks, but that isn't practical for the vast majority of modern software, which continues to use ever more external libraries. Clojure's STM paired with immutable data structures are an especially well suited combination that are unlike most of the research systems presented in this area. Of course there are additional resources that will have to be managed, such as access to I/O, but I would argue that access to I/O is by far the easier problem to deal with in comparison to concurrent access to memory - primarily because I/O devices are typically accessed serially so you can just queue up requests. [1]: Here's one explanation with a code example of why locks don't compose: http://www.drdobbs.com/article/printableArticle.jhtml;jsessionid=SQVVQ5O0S2ACLQE1GHOSKH4ATMY32JVN?articleId=202802983&dept_url=/cpp/ http://www.drdobbs.com/article/printableArticle.jhtml;jsessi...