Is concurrency hard?

[Thomas Lindgren]

--- Ulf Wiger <ulf@REDACTED> wrote:
> The current shift to multicore is driven
> by the apparent
> fact that we've exploited all other known
> alternative routes to high
> performance. Time then to force programmers to
> re-think. Luckily
> for Erlangers, the mental shift shouldn't be that
> traumatic.

Getting higher capacity will probably be
straightforward (as long as we have enough bandwidth
to that multicore chip, etc). Just throw more requests
at your system, as if it were a server farm.

Getting lower latency will be trickier. You can't rely
on clockspeeds to improve, obviously. Instead, you
must turn a sequential computation into a parallel
one. (Or construct a parallel one from the start.)

There are two conflicting objectives: you must break
down the work into independent portions that can be
processed in parallel (and joined together
efficiently). At the same time, you must keep the work
items large enough that threading overheads don't
swamp the system. A potentially delicate trade-off.

A simple but illustrative example is speeding up the
beam compiler on a multicore machine. A bit of
parallelization is easy: each function can be compiled
independently. (And even easier, multiple files can be
compiled in parallel, "make -j".) But after that, we
run into problems:

1. Per-function compilation is only part of the work.
Parsing the source is essentially sequential (as far
as I know), and emitting the object code may be too.
Thus, speedup will be limited by Amdahl's law. If
parsing the source and writing the object code uses
25% of the total time, we can get at most 4x speedup,
and probably less.

2. Even getting to that point may be difficult. Big
functions will take longer time to compile than small
ones, and may then become a bottleneck even in the
parallelized part of the compiler. We may then
eventually have to parallelize the compiler algorithms
as such. Last time I checked, the outlook for doing
this was pessimistic.

This is only half the problem, breaking the sequential
work into parallel parts. The other problem is to
throttle excess parallelism.

The same reasoning goes for a number of other
problems. In conclusion: for some of us, there are
interesting challenges ahead.

Best,
Thomas



		
__________________________________ 
Start your day with Yahoo! - Make it your home page! 
http://www.yahoo.com/r/hs