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)?

posted by sokhaty

posted by ianringrose

Cheers

Daniel

posted by Daniel Moth

Cheers

Daniel

posted by Daniel Moth

posted by jsinnott

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.

posted by LukePuplett

Cheers

Daniel

posted by Daniel Moth

Cheers

Daniel

posted by Daniel Moth

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. 

posted by sokhaty

posted by Dark_Halmut

To actually answer your question: PFor uses tasks in an intelligent manner (partitioning the range amongst a much smaller number of tasks) instead of using one task per iteration. So, of course you could code with tasks yourself an equally (or even more performant version), but look at the simplicity of the PFor API.

TIP: To get an insight into the PFor implementation place a breakpoint in the body of the for loop and look at the Parallel Tasks window.

Cheers

Daniel

posted by Daniel Moth

Although if the profiler could try P.For and normal For and suggest when you're actually degrading performance, that'd be excellent. That said, I did think that P.For uses some kind of ramping up technology so it ran synchronously for small loads - and thus, what we saw in the video shouldn't happen. P.For is so easy to use but so easy to use in the wrong place.

My problem is that most of the code I write I think is too small to be parallelised. Like arrays of 12 items. By the time I've finished I've got a huge chain of little bits of work adding up to a large amount of work, so then I start to look for logic that can run independently of each other and kick off some branch of execution on another thread and re-join/wait further down. The problem being that in the future I won't be able to find enough simultaneous work to spread across all cores!

Daniel - thanks, that'd be cool.

posted by LukePuplett

posted by RobertAMcCarter

1. The APIs ship as part of the .NET 4 framework (and the equivalent native ones as part of VC++ 10), so available in all VS editions.

2. Debugger Windows in VS Pro and higher.

3. Profiler in VS Premium and higher. It also requires Vista and higher due to dependency on ETW events.

Cheers

Daniel

posted by Daniel Moth

juts of curiosity: What is that vercy nice font that you are using in the VS code editor ?

posted by objectref

I don't think I changed the default (Consolas). Maybe the resolution is making it look nicer than usual...

Cheers

Daniel

posted by Daniel Moth

posted by Kevin Manbeck

Thanks, I uploaded the *demo* code to on my blog:

http://www.danielmoth.com/Blog/2010/02/code-for-parallelism-features-tour.html

Cheers

Daniel

posted by Daniel Moth

posted by jm