VS2010 Parallel Computing Features Tour

Posted By: Daniel Moth | Oct 19th @ 9:14 AM | 25,855 Views | 15 Comments

Author: Hi, I am Daniel Moth Smiley

 

Introduction:

In Visual Studio 2010, the Parallel Computing team has delivered APIs and tools for developers wanting to build applications that take advantage of multiple cores. This video provides a glimpse on the managed APIs, debugging windows and profiler support.

 

For more on the managed APIs, please start on the team's blog. For more on profiler start on that team's blog. For more on Parallel Tasks and Parallel Stacks please start on my blog post on Parallel Debugging.
Rating:
5
0
#Oct 19th @ 12:35 PM
sokhaty
sokhaty

Very nice.

One thing though, when matrix multiplication was executed on a small data set, sequential was actually faster than ParallelFor (@20:48). Are there any insights on estimating an overhead of setting up parallel execution machinery, so, application could attempt guessing whether to process data set sequentially or in-parallel (assuming that application knows the size of the data set)?

 

#Oct 19th @ 3:03 PM
ianringrose
ianringrose

Witch edition do I need to get access to the parallel debugging?

#Oct 19th @ 5:57 PM
Daniel Moth
Daniel Moth
Developer

We haven't published any insights. Currently, you would have to measure in yoru app and decide at what kind of workload you are getting speedup from parallelism. You could then have a conditional path that is serial for smaller workloads and a parallel path for larger workloads.

 

Cheers

Daniel

#Oct 19th @ 5:59 PM
Daniel Moth
Daniel Moth
Developer

Parallel Tasks and Parallel Stacks are available in Pro and above. Also click the parallel debugging link above to watch dedicated screencasts to those windows.

 

Cheers

Daniel

 

#Oct 20th @ 7:47 AM
jsinnott
jsinnott

Do the results change significantly if you change the order of execution?

#Oct 20th @ 7:54 AM
LukePuplett
LukePuplett
They're my own arms

As the narrator mentions, the Debug.Writeline causes the threads to queue/block on writing to the log/IDE. If this operation is significantly more costly than the work in the task (he has some simple math) then you're running essentially synchronously and the parallel code just becomes a burden.

 

Also, I always test by running the methods thousands or even millions of times and taking an average. OS noise amongst other things can severely impact a single pass of a method so you can sometimes get a misleading result.

 

 

Edit -- the tools far exceed all expectations. I'd like to see in-code-editor warnings about compiler optimisation and reordering pitfalls; for example, if I add an attribute [MultiThreaded] to a method, then (after compilation) the IDE highlights execution/reads/writes that has moved from the order it was coded.

#Oct 20th @ 10:19 AM
Daniel Moth
Daniel Moth
Developer

Not significantly. The point of the video was to show the tools and make you aware of the rich Task API and the ease of us of PFor as well as to show the pitfalls for no perf gains of directly using the ThreadPool. Even though I am microbenchmarking, if you run each approach separate to each other, multiple times and with varying workloads, I do not expect the results will vary significantly.

 

Cheers

Daniel

#Oct 20th @ 10:22 AM
Daniel Moth
Daniel Moth
Developer

Thanks. Regarding your wish list, those items are not under what we consider debugging and performance tools. We think of those as Correctness tools (or some say Analysis tools and other say Safety tools) - regardless, they are very important too and things we are thinking about for future (post-VS2010) releases.

 

Cheers

Daniel

#Oct 20th @ 12:37 PM
sokhaty
sokhaty

Luke, for the sake of correctness, Debug.Writeline call was added to the MulTask() method, which was executed after the sequential and PFor multiplication. So, PFor loop ran without any blocking on screen output, and it was slower than sequential presumably because of all the extra work associated with priming up parallel execution environment.

If 90% of the input for my app on any given day happens to be small, it's better to process those 90% sequentially and use parallel execution only when appropriate, but for that it would be nice to know, where (approximately) is that cutting point.

I can run tests and collect some stats on what overhead of firing up parallel execution is, but assuming that this work might have been already done while developing the parallel framework, it would be preferrable for me to look at the stats collected by the PF development team than spend time and efforts myself.

 

Cheers,

Seva. 

Microsoft Communities