posted by felix9

The sample I like more is the nbody simulation, not only they use tasks also they make a nice and simple UI with Direct2D

posted by new2STL

posted by felix9

5 hours ago, Mr Crash wrote

arr the video was too short, whats the timetable for part 2 ?

Part 2 is less of an extension of this, but obviously related and an extension . It will ship soon. Too short, eh? Agreed.

C

posted by Charles

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

posted by new2STL

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.

posted by new2STL

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.

posted by Artur Laksberg

Intel say that your tasks should be between 10 000 and 100 000 cycles or intstructions ( i do not remember exactly) for their TBB.

And how we can measure how much cycles a piece of code has (easily)?

Splitting a code into tasks is a static operation now.

posted by stefandylgerov

posted by new2STL