Sunday, April 15, 2012

Stop splitting Parallelism and Concurrency

There’s quite a fashion these days trying to separate “Concurrency” from “Parallelism” and saying they are not the same thing; even so far as to say that concurrency is better.  I mean, neither is new yet recently there’s been a whole re-awakening to scaling sideways at the code rather than server level.

The splitters are those who ‘get it’, who are trying to convert the other 99% of programmers who are apathetic and didn’t really care about the maligned parallelism anyway.  Its the splitters picking a fight that doesn’t need picking.

And its hurting our concurrency conversion.

Concurrency is fashionable and good

Parallelism should not be confused with concurrency. Parallelism is about efficiency, not semantics; the meaning of a program is independent of whether it is executed in parallel or not. Concurrency is about composition, not efficiency; the meaning of a concurrent program is very weakly specified so that one may compose it with other programs without altering its meaning. [Robert Harper]

I’m a big fan of languages/platforms that explicitly support CSP - aka tasks and queues aka the actor model.  I’m a big fan of built-in support in order to remove the correctness and performance risk of having to roll your own or of using a 3rd party framework that doesn’t play nice with other components you want to use and so on.

At a large-enough granularity that’s the Unix platform with processes and pipes.

At a smaller granularity its languages like Go and Erlang.  They bring that granularity down enough that it’s sufficiently fast to have much larger numbers of much smaller tasks.

And by protecting you from having to plumb your own threads and queues and such and exposing proper language primitives that the compiler knows about, we can hope that sufficiently smart compilers will keep improving and dynamically exploiting the parallelism that concurrency affords.

So I’m firmly in the CSP camp; its always central to my dream language wish-list and something I’ve thought carefully through for async message loops.

So lets stop trying to define it

The Life Of Brian, Splitters sceneAs I write this I see that I am myself falling into the trap of demarcating concurrency and parallelism and that’s exactly what I want us to all stop doing!  Stop it!

Everyone jump on the CSP band-wagon, everyone see the virtues of CSP at a language level, everyone see how some long-running servers they have to write will be better able to scale to multiple cores if they adopt CSP etc.

FWIW, I would only retroactively apply it architecturally to about 50% of the servers I’ve written in a more explicitly mixed-in multi-threading model.  Its not a magic bullet and importantly the plumbing the platform does for you is not free.  Which is why we all have C/C++ when we really really think we need it.

But stop splitting it.  Because its turning people away from the CSP crowd, its creating fanboitous and resentful anti-adopters.  Its making CSP sound inflexible and unwelcoming.

The splitters are those who ‘get it’, who are trying to convert the other 99% of programmers who are apathetic and didn’t really care about the maligned parallelism anyway.  Its the splitters picking a fight that doesn’t need picking.

Instead, talk success stories

Much better to focus on how correct yet scalable CSP is and what it can do for people.  Never claim its a silver bullet.  Claim only that its easy and good.

Notes

  1. billzhuang reblogged this from williamedwardscoder
  2. williamedwardscoder posted this

 ↓ click the "share" button below!