[vsipl++] [patch] Parallel Howto

[Jules Bergmann]

Toon Knapen wrote:
> Mark Mitchell wrote:
>> 2. I've started saying "uni-processor" and "multi-processor" instead of
>> "serial" and "parallel".  What do you think about adopting that
>> convention?  The problem is that uniprocessors can be parallel (SIMD
>> units, or Cell).

Mark,

I need to look at my usage of serial vs parallel before committing to 
this.  I'm sure there are some cases where it would be more clear to say 
"uni-processor" and "multi-processor" instead.  However, in contexts 
where "parallel" refers to data-parallelism may be exploited in multiple 
ways (multiple processors doing FFTs in parallel, single processor doing 
multiple FFTs in parallel with SIMD, etc), that might be the most 
appropriate word.

As I edit this to clean up the first-person, I'll take a look at how 
parallel/serial is used.

> 
> We recently have been looking at the wording in our tutorials too and I 
> think it might be confusing to use terms like 'uni-processor' or 
> 'multi-processor'. The main reason is that MPI and multi-threading is 
> about processes, not processors. On what processor these processes will 
> be scheduled is up to the OS (generally). My experience is that the 
> scheduling of processes on processors is something very confusing for 
> users and using these terms might add to that confusion. And indeed, 
> once users are dealing with multi-core processors, this will be even 
> more confusing.

That is a source of potential confusion, especially with MPI; nodes, 
processors, thread, and now cores.

The VSIPL++ spec has an intentionally vague definition of a "processor" 
that we can fall back on here.  The mapping from a VSIPL++ processor to 
actual hardware parallelism is up to the implementation.  The intent is 
that VSIPL++ processes represent parallelism that could be exploited by 
MPI processes, threads, etc.  If we did use the term "multi-processor" 
in the VSIPL++ tutorial it would be well-defined in that sense.

Of course, if you guys have come up with more clear wording, we'd be 
interested!

				-- Jules

> 
> Toon Knapen
> 
> PS: Hope you don't mind me chipping in this conversation.

Not at all!  That's why the list is public.  Its good to hear from you. 
-- Jules

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