Also, how will the PPL and all of the mumbo-jumbo (i.e., Concurrency Runtime) it sits on handle parellizing code in multiple concurrent processes? Or, are we supposed to, from now on, run only a single "parallelized" process on a multi-core host?

posted by Corrector

Thanks for the comment!   I apologize that I just noticed this on the blog.  

I suppose that's part of what the industry, not just Microsoft, intends to solve...   making the expression of parallelism easier and safer for every developer.  

Of course, this demo is just introductory and not intended to address solution domain complexities in-depth.

Parallel_for is simply a mechanism to allow the programmer to express concurrency more easily.  It frees them from writing the plumbing-code that so often goes with concurrent code and maintaining it.  So yes, it does lower the barrier to writing parallel code.  We see this as a good thing.

Does that mean that some programmers will write parallel code who should not be writing that code?  Perhaps, but this is not the fault of the runtime system.  This is a skill-development-problem and falls to development teams to solve, maybe through code inspection and design guidelines, for example.  Potentially, tools can help with best practices (e.g. see the new VS2010 parallel performance profiler). 

Our other option is simply to stop developing new features in existing applications or ask the users to put up with slower applications.

The question of multi-process concurrency is interesting and there are tools and techniques that can be used to accomplish this (e.g. Windows HPC Server and the MSMPI SDK).   We recommend starting with domain decomposition and implementing execution partitioning techniques that map onto the scope of the parallel computing problem.   As you know, some computations simply can't be solved without multi-process or multi-computer parallel processing.  However, the C++ Concurrency Runtime or .NET Parallel Extensions may still be significant components of even a distributed process solution.   These technologies are specifically designed to express concurrency at the application scope and with an implementation that is highly optimized for resource management, shared state, and thread-level scalability.   Even if multi-process scheduling and synchronization designs were added, the existing mechanisms would still apply and be necessary.

- phil

posted by philpenn