Intro
This is the first in a series of “thought pieces” about concurrent programming, especially as it relates to realtime applications. The motivation is for use in games, but this series is not game-specific.
The concurrent programming debate
There is a lot of interest (and griping) these days about the problems of writing efficient bug-free concurrent code (especially in the context of multicore systems). If you’re reading this, you probably already know why it has become a hot topic, so I’ll skip the explanation.
In any case, many people seem to feel the same way as guru Donald Knuth, author of the highly regarded The Art of Computer Programming series. This is what he said in a recent interview.
…I might as well flame a bit about my personal unhappiness with the current trend toward multicore architecture. To me, it looks more or less like the hardware designers have run out of ideas, and that they’re trying to pass the blame for the future demise of Moore’s Law to the software writers by giving us machines that work faster only on a few key benchmarks!
However, some people feel differently. Contrast Knuth’s statement with the following quote [from a lecture given in 1977] of another guru, John Backus, famous for being the “Backus” in BNF (Backus Normal Form, aka Backus Naur Form) formal language specification:
Surely there must be a less primitive way of making big changes in the [data] store than by pushing vast numbers of words back and forth through the von Neumann bottleneck. Not only is this tube a literal bottleneck for the data traffic of a problem, but, more importantly, it is an intellectual bottleneck that has kept us tied to word-at-a-time thinking instead of encouraging us to think in terms of the larger conceptual units of the task at hand. Thus programming is basically planning and detailing the enormous traffic of words through the von Neumann bottleneck, and much of that traffic concerns not significant data itself but where to find it.
To be fair, Backus was talking about changes in programming paradigms (specifically, proposing the use of functional programming), not parallel processing, but his point that there must be better methods of programming that transcend “word-at-a-time thinking” still seems relevant today.
Is the debate moot?
It may seem that debating concurrency is pointless. After all, we’ve started down the multicore path, and it seems like there is no turning back. That is probably true. For the foreseeable future, hardware will continue to increase in concurrency.
However, it is conceivable that software might remain procedural/imperative (e.g. if someone solves the long-standing problem of automating parallelization of sequential code). In addition, deciding how to approach the problem of concurrency depends on how we perceive the advantages and disadvantages of mimicking sequential code.
So, I do not think the debate is entirely moot. It is largely moot for hardware, but not for software, especially insofar as it affects our perception.
What’s my take on concurrency?
I agree with John Backus’s sentiment about the state of programming. A lot has changed in the 30+ years since his lecture, but even now, the status-quo of programming languages and methodologies feels limited by the intellectual “von Neumann bottleneck”.
In fact, I believe concurrent hardware will lead us to languages and methodologies which more naturally express solutions to realtime application problems. After all, realtime applications are about simulating large numbers of simultaneous activities. Simulation is naturally concurrent. All this time, we’ve been trying to simulate concurrency with sequential programs.
But, if simulation is naturally concurrent, why is concurrent programming so difficult?
The problem is that we don’t yet have adequate languages, tools, and methodologies for dealing with processor concurrency. Once those are developed, concurrency will be liberating. We will finally be able to write realtime applications the way we always wanted to (but didn’t know how).
Fortunately, the development of those languages, tools, and methodologies will be expedited by the fact that no one can ignore concurrency any longer.
[to be continued....]
