Parallel Programming with .NET : Release

Updated Beta 2 samples for parallel programming

toub — Mon, 07 Dec 2009 03:59:00 GMT

We've refreshed our Beta 2 samples for parallel programming with the .NET Framework 4. Thanks to the gracious assistance of the fabulous Lisa Feigenbaum and others on the Visual Basic team, in this refresh the majority of the samples are now available not only in C# but also in Visual Basic. The samples are available for download at http://code.msdn.microsoft.com/ParExtSamples.

Enjoy!

Reactive Extensions and Parallel Extensions

toub — Fri, 20 Nov 2009 02:36:27 GMT

It’s awesome to see the Reactive Extensions to .NET (Rx) live on the DevLabs site. If you haven’t checked out this exciting project, we urge you to do so. Not only is it cool and useful technology, but the download includes a back ported (and unsupported) release of Parallel Extensions for the .NET Framework 3.5 in the form of System.Threading.dll. Rx relies on this, and you can also use it to try out our new parallel programming support for .NET 4 but with your .NET 3.5 projects.

I recently sat down with Wes Dyer from the Rx team to discuss the Reactive Extensions integration with Parallel Extensions. You can view a video of that discussion at Wes Dyer and Stephen Toub: Rx and Px - Working Together.

While unsupported, the 3.5 back port does contain all of the types and constructs present in the .NET 4 supported release. In fact, using the back ported version is very similar to using the bits in .NET 4, albeit with a few known differences:

In order to use the features with .NET 3.5 applications, you will need to add a reference to the back ported standalone DLL named System.Threading.dll. This additional step is not present with .NET 4, since the parallel technology is baked into core CLR components.
The performance of the parallel types is optimized for and predicated on the .NET 4 Framework. You should not assume that an application using the .NET 3.5 version will exhibit similar performance characteristics to one using the supported .NET 4 version. Parallel Extensions extensively leverages advancements made in the .NET 4 ThreadPool and other performance optimizations present in .NET 4.
Unlike in .NET 4, the OperationCanceledException type does not have a constructor that accepts a CancellationToken, nor does the exception have a CancellationToken property. In order to throw an exception to cooperatively acknowledge cancellation within a Task, you may use the ThrowIfCancellationRequested method present on the CancellationToken type. Refer to MSDN documentation for more details.
To handle exceptions thrown due to cancellation, users should catch the OperationCanceledException. Although the exception thrown is of type OperationCancelledException2, users will not be able to catch this type as it is an internal exception derived from OperationCanceledException (necessary as part of the back port to maintain consistency).
The Parallel Task and Parallel Stack tool windows in Visual Studio 2010 will not highlight tasks from the .NET 3.5 back port. These features require .NET 4.
The concurrency visualizations in the Visual Studio 2010 profiler will not show parallel region markers for parallel loops in the .NET 3.5 back port. This is due to the .NET 3.5 version not outputting any of the ETW events output by the .NET 4 release.

Even with these limitations, we hope you enjoy the release! You can also expect further integration between Rx and Parallel Extensions in future drops on the DevLabs site.

.NET 4 Beta 2 is here!

toub — Mon, 19 Oct 2009 18:50:05 GMT

The .NET Framework 4 Beta 2 is now available!

MSDN Subscribers can download it today, and it will be generally available for download on Wednesday. More information is available at http://msdn.microsoft.com/en-us/vstudio/dd582936.aspx. Additionally, one of the really exciting things about this Beta release is that it’s “go-live”; more information on that is available at “Going live” with Visual Studio 2010 Beta 2.

As part of .NET 4 Beta 2, of course, comes improved parallelism support. In the coming days and weeks, we’ll be blogging here about some of the exciting updates and additions in this release. Stay tuned…

In the meantime, the MSDN documentation on .NET 4’s parallelism support has been updated. It’s a great place to start learning about all of the functionality available in this release.

You can also learn more about the tools in Visual Studio 2010 for parallel development in the documentation at:

Enjoy!

Concurrent, Multi-core Programming on Windows and .NET

toub — Tue, 28 Oct 2008 08:51:00 GMT

Thanks to everyone who attended our PDC pre-conference session yesterday on parallelism and concurrency! We had a wonderful turnout at the event, and David, Joe, and I all had a terrific time. Attached to this post are the slides we presented.

(It turns out that the PDC site does allow you to submit an evaluation for a precon. If you attended, we'd love your feedback.)

Released! Parallel Extensions to the .NET Framework June 2008 CTP

essey — Mon, 02 Jun 2008 17:00:00 GMT

We’re very excited to announce our 2^nd Community Technology Preview (CTP) for Parallel Extensions to the .NET Framework 3.5. We released the Dec07 CTP on 11/29/2007, and from that we have received a lot of feedback from the community and customers. While you have been using our bits, participating in our forums, sharing your insights and experiences, and following along on our blog, we have been hard at work preparing this CTP, incorporating your feedback into it.

Download the Parallel Extensions June 08 CTP (UPDATE 11/30/09: The June 2008 CTP is no longer available. For an unsupported release of Parallel Extensions compatible with the .NET Framework 3.5 SP1, please see the Reactive Extensions release on DevLabs at http://msdn.microsoft.com/en-us/devlabs/ee794896.aspx.)

There are some large changes in there that should provide a lot of benefits. First off, we have begun to add the third major API component, the Coordination Data Structures, to the technology package. As we build PLINQ and the Task Parallel Library, we use a lot of components under the covers to handle synchronization, coordination, and scale to contain data reads and writes from multiple procs. We see these as widely useful, so we’re sharing them here with you.

We incorporated a brand-new user-mode, work-stealing, run-time scheduler (those modifiers essentially mean that it’s light, fast, and flexible) to the system, completely over-hauling the infrastructure. This is a very important piece of technology for making the most of the resources available on your machines. This has been in research and incubation for a long time, and it will allow for improved performance and future-proof scalability (e.g. cache consciousness) as we stabilize and improve it. Expect to hear us talk a lot more about this in the future. There are still likely to be some growing pains in this release, so please pass along that feedback and expect this to improve. Additionally, The Task Parallel Library is now built directly on top of this scheduler. And to add to the excitement, PLINQ is in the first stages of building on top of the Task Parallel Library.

There are a number of other changes that we have made, some notables include: new ordering implementation for PLINQ, change of Parallel.Do to Parallel.Invoke, continuations in Tasks. A much more detailed list of updates is coming soon.

Subscribe to the feed or come back to this blog often as we release a flurry of posts regarding the new and exciting work surrounding this CTP.

Known Issues in the June 2008 CTP of Parallel Extensions

essey — Mon, 02 Jun 2008 12:01:00 GMT

The Jun08 CTP is still an early pre-release version that is not ready for production usage. In addition to on-going feature additions and performance work, there are some known issues that we plan to address in future releases. Of course, there are always things that we missed and we would love your feedback on them either as comments to this post or in the forum.

Task Parallel Library

1. New scheduler threads are not injected if a task blocks, possibly leading to an inability to run additional tasks. When there are dependencies between running tasks and to-be-scheduled tasks, this can lead to deadlock. To make this less likely to happen in practice, TaskManager automatically doubles the number of threads used by default just for this CTP. This is inconsistent with the documentation which says we will default to a min of 1 processor, an ideal of Environment.ProcessourCount processors, and an ideal of 1 thread per processor. If you do not like this behavior, or if you still experience deadlocks, you may override the setting by providing your own TaskManagerPolicy with a certain ideal threads per processor count.

2. Instances of TaskManager, including the default TaskManager instance, do not shutdown cleanly when run in VsTestHost (the host application used to run unit tests from Visual Studio). This problem may occur whenever TPL threads are aborted, as is used by the CLR in AppDomain unloads. If you’re using PLINQ or TPL in unit tests in Visual Studio, you can work around this problem by avoiding use of the default TaskManager instance and by explicitly disposing of any used TaskManager instances before exiting your unit tests. See http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3380311&SiteID=1 for an example.

3. Parallel.For may overflow and execute extra loop iterations if the toExclusive argument is very close to Int32.MaxValue. This problem is more likely to occur on systems with 8 or more processors.

4. Some stress scenarios with multiple TaskManagers may cause crashes or data loss due to an implementation bug. This will be fixed in a future release.

5. The concurrent workstation GC is used by the CLR by default on multi-processor machines. While the concurrent GC does perform some scanning in parallel, collections themselves are run sequentially. If your parallel program allocates a fair bit of garbage, these collections may substantially impact the kinds of speedups you will witness. As an alternative, you may turn on the server GC by using an application config file: <configuration><runtime><gcServer enabled=”true”/></runtime></configuration>. This ensures parallel collections are performed, utilizing all available processors. Note that this can lead to a poor experience on machines running lots of active processes—such as Terminal Server scenarios—because the GC requires that all processors are used for the collection to complete.

6. Large numbers of Tasks may underperform the Dec07 CTP in some applications.

PLINQ

7. In this CTP, PLINQ is implemented on top of the Task Parallel Library, which does not yet have thread injection in this CTP (see the related above issue #1). Some PLINQ queries require more concurrently-running tasks than the number of threads that Task Parallel Library creates, so you may observe deadlocks. Specifically, binary operators like SelectMany and Join that use the output of another PLINQ query as the second data source are likely to hit this. We have provided a workaround for this CTP: the previous implementation, which runs on top of the .NET ThreadPool, is still available. Just set the PLINQ_USE_THREADPOOL environment variable to a non-empty value and PLINQ will revert back to the ThreadPool. This setting will go away in subsequent releases.

8. PLINQ with order preservation on is noticeably slower than PLINQ without order preservation. A natural tension exists between ordering and performance. For the sake of performance, by default, PLINQ does not maintain query result order (this can be switched by adding the AsOrdered method directly onto the AsParallel method. This is, in some sense, a built-in part of PLINQ’s design but we are hopeful that sizeable performance improvements can still be made.

9. Some operators always produce output in an undefined order, even if the user explicitly requested ordering. Specifically, this affects the following operators: Distinct, GroupBy, Join, Except, Intersect, and Union.

10. Documentation addendum: Some operators may not do what you expect when order-preservation is not turned on. Because the ordering among elements will be non-deterministic, SequenceEquals, Take, TakeWhile, Skip, and SkipWhile, for example, will effectively be performed on a randomly ordered input. As a specific example, Take(N) will take N elements, but not the “first” N elements as you may be expecting. Reverse is simply a no-op since it inherently relies on ordering. We are still evaluating how best to surface this possibly-confusing aspect of the programming model more clearly.

Coordination Data Structures

11. ConcurrentQueue<T> has known scalability work to be done. Specifically, the implementation uses a linked list internally which increases the amount of memory allocations and garbage when compared to a simple Queue<T> data structure. It also leads to more interlocked operations being executed to maintain lock-freedom when compared to a simpler fine-grained locking approach. We are actively experimenting with alternative approaches.

Samples

12. The samples install into %PROGRAMFILES%, which by default is a privileged location that requires administrative privileges to write to; this includes the writes that must occur during compilation. In order to compile the samples, you’ll either need to copy the samples to another location or start Visual Studio with administrator privileges.

13. The ImageColorizer sample relies on Microsoft.ink.dll, a DLL that’s included with Windows Vista and other Tablet-enabled operating systems as well as in the relevant SDKs (link to SDK). Certain functionality in ImageColorizer relies on this DLL. While you won’t need the DLL to run the application (the relevant functionality will be disabled if the DLL isn’t present), you will need to acquire the DLL in order to compile the sample. On a Windows Vista install, the DLL is likely available in a location like %PROGRAMFILES%\Reference Assemblies\Microsoft\Tablet PC.

14. The project file for the F# Raytracer sample contains a hardcoded path to System.Core.dll, which presumes that it resides at "C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll". If this is not the case, you will need to modify the path in the property pages.