Please download the sample pack, play with the new library, push it and provide feedback to the team. They really want and need your input to insure they deliver the right things for real world usage by C++ developers. Go native!

I think this looks a lot like LWTs from OCaml (http://ocsigen.org/lwt/)... To me it seems that C++ is slowly moving to functional programming style... STL is already really in a functional style and with the arrival of Lambdas a lot more beautifull features from the functional world will appear.

@till: You guess is not wrong, a lot of new stuff come together with F# (based a lot on OCaml and Haskell) development team and the Visual Studio Team while they are in Beta and early. If you carve some old blog posts, videos and white-papers from 2008 you will find nice clues and amazing reports

"C++ is a multi-paradigm programming language, giving you many ways to express your solution" Posted November 4, 2010 by Eric Niebler

What I want to know about is a discussion of efficiency. How efficient are tasks? How free-form are they with efficiency- for example, you said that they are intended for small chunks of code. How small is small? How much of an efficiency penalty am I going to get for getting this definition wrong?

@Mark:Sure only the devs can answer your question better than me in the forum but what they want to say with 'small' is local constrained, well delimited work around data, PPL/ConcRT are for parallelization like Intel TBB and OpenMP.

The tasks behavior light, its not like a thread pool that you throw a lot of code logic with many branches like a thread for incoming TCP connections, they are light to keep the lockfree sanit, in the same way you would do on OpenMP

Here is an Intel internal article comparing ContRT, Intel TBB and OpenMP. ConcRT have near the same performance as Intel TBB.

Resuming: Task are not Threads, not in the sense of some code that use thread to act like a fork command.

It's a great question but any meaningful answer must be qualified with "compared with what?"

Tasks definitely have overhead over plain OS threads, and if the amount of work you're doing in a task is small, the overhead becomes more pronounced. Because tasks are built on top of other PPL/ConcRT constructs, they have overhead over these constructs. So one way to look at the efficiency is to try to solve the same problem using different constructs and compare the results.

To take one specific example, I can calculate a Fibonacci number (using the naïve recursive algorithm) in a parallel_for loop from 0 to 100, then do the same by spawning 100 tasks that do the same, and compare the elapsed time of both solutions. The data I get on my laptop shows that the tasks-based solution is about 5% slower than the parallel_for-based solution. I'm not too worried about this kind of overhead because a) it's small and more importantly b) you would never do this in a real-world application - parallel_for is a better solution for this problem.

Some of our other performance tests show that the overhead can be quite significant, so more optimization is in order.

Now to my main point. For problems where PPL tasks offer a more productive programming model, their performance should be "good enough" so that you don't have to fall back to a less productive programming model, such as OS threads. If we have accomplished that, we have succeeded. If you want to use PPL tasks but are forced to use some lower-level constructs to get the performance you need, we have failed.

Thanks for your replies. I'm not concerned about expending performance- CPU cycles exist to be used, and in some cases, to save the programmer time. I am, however, concerned about expending performance because I didn't understand the purpose or implications of using a specific construct.