I wasn't even considering the higher complexities of parallelization like
associativity though this is another obstacle to attempting transparent
fine-grained parallelization.

I think you're right about the cores sharing common memory but this has
problems of its own.  At the very least there's still a non-trivial amount
of overhead for coordination.  Also, according to this article on "Common
Multi-core Programming Problems" (
http://www.automotivedesignline.com/howto/203100195;jsessionid=VWOO54SHOKKNWQSNDLQCKHSCJUNN2JVN?pgno=3),

"But on a multi-core processor, packing shared data can lead to a severe
penalty from false sharing. Generally, the solution is to pack data tightly,
give each thread its own private copy to work on, and merge results
afterwards."

So it sounds like there still could be considerable data movement.  All of
these considerations point to a high threshold of function complexity below
which the overhead swamps the gains.  This is why I continue to emphasize
that practical multi-core parallelization is a programming problem for now,
no matter how much we would like it to happen automatically with little
thought on our part.

How difficult this problem is depends on the particulars as I've illustrated
with a simple example at
http://www.jsoftware.com/jwiki/NYCJUG/2007-03-13#head-0c69d286922c2243a3e9c74bb1f06a4d9e88bbfd.
 This problem is well-suited for programmatic parallelization because
there may be a lot of non-trivial processing to be done on a very large
amount of data and the processing of each section of data is logically
independent, in part because of how the data was originally set up.

On 12/20/07, Don Guinn <[EMAIL PROTECTED]> wrote:
>
> The problems with whether or not + is associative in certain circumstances
> have been around since people started rounding numbers. These problems are
> not unique to multiprocessing.
>
> As to moving data around between various memories - I am not really clear
> on
> the architecture of multi-core systems, but don't they consist of multiple
> processors, each processor having its own cache but sharing a common main
> memory? If so, then there is not a problem of having to move blocks of
> data
> among different main memories.
>
...
-- 
Devon McCormick, CFA
^me^ at acm.
org is my
preferred e-mail
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to