Parallel programming

Sean Kelly sean at invisibleduck.org
Tue Jul 15 17:53:28 PDT 2008


== Quote from Markus Koskimies (markus at reaaliaika.net)'s article
>
> If I would asked to say what is the way of writing future programs, I
> would say it is MPS (Message Passing Systems), refer to e.g. Hewitt's
> Actor Model (1973).

I agree completely.  MP is easy to comprehend (it's how people naturally
operate) and the tech behind it is extremely well established.  I remain
skeptical that we'll see a tremendous amount of automatic parallelization
of ostensibly procedural code by the interpreter (ie. compiler or VM).  For
one thing, it complicates debugging tremendously, not to mention the
error conditions that such translation can introduce.

As an potentially relevant anecdote, after Herb Sutter's presentation on
Concur a year or two ago at SDWest I asked him what should happen if
two threads of an automatically parallelized loop both throw an exception,
given that the C++ spec dictates that having more than one in-flight
exception per thread should call terminate().  He dodged my question and
turned to talk to someone else, who interestingly enough, did make an
attempt to ensure that Herb understood what I was asking, but to no avail.
Implications about Herb aside, I do think that this suggests that there are
known problems with implicit parallelization that everyone is hoping will
just magically disappear.  How can one verify the correctness of code that
may fail if implicitly parallelized but work if not?

> Furthermore, I would predict processors to start to
> do low-level reconfigurations, e.g. RSIP (Reconfigurable Instruction Set
> Processor) -paradigm. Look google for GARP and the awesome performance
> increasements it can offer for certain tasks.

Interestingly, parallel programming is the topic covered by ACM Communications
magazine this month, and I believe there is a bit about this sort of hardware
parallelism in addition to transactional memory, etc.  The articles I've read so far
have all been well-reasoned and pretty honest about the benefits and problems
with each idea.


Sean



More information about the Digitalmars-d mailing list