[vsipl++] [patch] Parallel Howto

[Jules Bergmann]

Mark Mitchell wrote:
> Jules Bergmann wrote:
> 
>> Please have a look and let me know what you think.
> 
> I'm excited to see this!  I think it's very important.  (Along with the
> rest of the tutorial.)  As we're learning from the fellow at ARL, the
> Georgia Tech User's Guide is actually worse than useless: it's examples
> apparently don't work at all.

We should work with Dan Campbell to get those fixed.  I'll take an 
action item to look that over.

> 
> Overall, I think the structure of the tutorial, and of the chapter you
> added, are good.  However, I think the words need a bit of work.  I also
> think the SAR chapter should be integrated with the chapter you wrote,
> or that they should go near each other, at least.

I agree.  Let's get the parallel howto chapter in good shape first, then 
we can start to better tie them together.

In terms of linkage, the fast convolution processing done in the 
parallel howto is very similar to the SAR azimuth processing.

> 
> Here are a few nits:
> 
> 1. Accepted practice is to use the second person for tutorials, user's
> guides, etc.  So, "You will learn how to parallelize the serial
> version", rather than "We will show how to ...".  (That applies in lots
> of places.)  That also means that you can use the imperative case:
> "Next, create data structures" instead of "Next, we need to create data
> structures".

Will do.


> 
> 3. In the section on Parallel Fast Convolution, it's not clear what the
> point of the first paragraph is.  Are you explaining what "implicit
> parallelism" is?  Or, suggesting that implicit parallelism is bad, and
> that we want to use maps instead?  Or...?

It is trying to say that implicit data-parallelism is good.  With 
implicit data-parallelism you map the data and VSIPL++ takes care of the 
rest.  With explicit data-parallelism, you need to transform the 
explicit loop from the global space to the local space.

> 
> 4. In the section on Explicit Parallelism, drop the sentence "For
> example, if our system had multiple channels, ..."  That sentence
> suggests the VSIPL++ API is missing something (versions for tensors),
> which sounds bad.  And, the next sentence gives a good motivation for
> the rest of the section anyhow.

Well, it is missing something!  It's not necessarily a defect with the 
API itself, but more of a matter of where do the API draw the line in 
terms of built-in data-parallel operations, and how do you write 
applications once they cross that line.

Dropping that sentence weakens the argument somewhat, since there are 
other ways to write the second example that are both implicitly 
data-parallel, and a good implementation might be able to perform in a 
cache friendly way.  For example, if the by-value syntax is used:

	data = inv_fftm(vmmul<row>(for_fftm(data), kernel));

The library would see the entire expression and have the opportunity to 
process by-row instead of by-operation.  We don't do that (yet).

That said, I don't mind dropping that sentence, since the second example 
is the basis for the rest of the section.

> 
> I'd like to take a whack at editing this on the plane to Orlando next
> Monday.  So, please check it in at some point before that.

OK, will do.  Thanks for the feedback.

				-- Jules



-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705