November 29th, 2007

CTP Quality

Stephen Toub - MSFT
Partner Software Engineer

Community Technology Preview (CTP) releases from Microsoft typically provide early looks at the technologies a team is working on.  Frequently, CTP quality is nowhere near what folks might expect from Beta releases and the like, and that’s ok.  The idea is to give all of you in the community a look at what we’re working on, giving you enough time to provide deep feedback on the direction the technology is taking, and giving the product team working on that technology enough time to react to the feedback so that it actually has an impact.

We’re excited to have released a CTP of the Parallel Extensions to the .NET Framework today, and we’re very interested in the feedback you have on the approach, on the APIs we’re providing, and so forth.  However, it’s also important to keep in mind the quality level present in this release.

We’ve been working on PLINQ for quite a while now, and the CTP release contains relatively stable bits.  They’re certainly not reliable and robust enough to put into production (please don’t!) nor is performance anywhere near what we expect it to ultimately be by the time the technology is released in final v1 form.  However, except for a few known correctness bugs, the quality should be good enough for you to start trying out the APIs, seeing what sort of business value they’ll provide in your applications, providing correctness bug reports or feature requests to us, sending us code samples representing cool things you’ve done or things that you expected to work but didn’t, and so forth.

The Task Parallel Library has a much lower quality bar for this release.  We’ve been referring to it internally as “API evaluation quality,” meaning that while key scenarios will work with the bits, portions of the API we have in our specs have not been included in this release, there are several known and important correctness issues, and performance hasn’t been a priority thus far (it absolutely will be going forwards!).  We really need your feedback here.  We know we have correctness bugs, so while those are important to know about, we’re more interested in feedback on the design of the APIs.  Will these APIs help you to introduce enough parallelism into your applications?  Do they require any funky gyrations when solving problems that other APIs we could provide wouldn’t require?  With the Parallel class, are For/ForEach/Do the right methods to expose, or are there other common loops you’d like to see?  We’ve already started revamping the APIs slightly here and there based on internal and customer feedback, but we’ve a ways to go, so definitely let us know what’s on your mind.

(Note that several times we’ve described PLINQ as building on top of the Task Parallel Library.  If you take a look inside the System.Threading.dll, however, you’ll probably notice that PLINQ is actually using the .NET ThreadPool rather than TPL’s Task APIs.  What’s up?  Given what I’ve just said about the quality differences between PLINQ and TPL, you can probably guess.   Given that for this release we had a higher quality bar for PLINQ, we opted to have PLINQ use the ThreadPool for this release.  As we improve the correctness, performance, and reliability of TPL, expect to see this change in a future release.)

You can provide feedback to us through our Connect site.  You can also see a list of known correctness issues.

Thanks!

Author

Stephen Toub - MSFT
Partner Software Engineer

Stephen Toub is a developer on the .NET team at Microsoft.

0 comments

Discussion are closed.