Thanks for identifying this incorrect link... fixed.
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.
You got me there! It's really hard to achieve 5 minute videos... We're still reaching for the goal and it pains me each time I post anything more than 10 minutes long. Maybe we should use a 5, 10, 15... minute concept logo instead?
Thanks for the comment, Josh!
You are correct... the preferred method of installing application dependencies is via install merge modules. There are numerous considerations. Consequently, we've added a "Notes On Manifests" document to the Code Gallery project associated with this topic. Viewers may find it within the "Downloads" tab of the page at http://code.msdn.microsoft.com/R2CoreApps.
Hi Slyi, Officially, all variants of SQL Server are not yet supported on Server Core installations. But, future versions of SQL Server, like a lot of other server-side products, will likely have a "Server Core" installation mode.
Sorry... Please try the image again. You may have caught me in the middle of uploading it anew.