lkml.org 
[lkml]   [2000]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Help in DSM design
Date
From
: Larry McVoy wrote:
: > OK, so that leaves us with programs that are actually sharing memory
: > because they need to do - they are communicating with each through the
: > memory rather than communicating through messages. Classic examples
: > of this are your basic simulation, where each process (thread if you
: > must) is working on some subset of the space. Let's say it is a three
: > dimensional simulation, so each process has a subcube of the larger
: > cube.
:
: Thank you. You've described the perfect application for DSM :-)

Really. I think not.

: > So contrast this model with "CPU from executing another thread while
: > it waits" statement. The only way you can keep all the CPUs busy all
: > the time is by adding other computations - it's obvious that this
: > computation will go much much slower under a DSM, isn't it?
:
: No it isn't. Once you've got computation of a single iteration
: dominating over communications latency per iteration, you only need to
: run two threads on one node to absorb the latency altogether.
:
: For a 3d simulation that's simple: use smaller cubes and run more than
: one per node.

Perhaps you'd like to try this explanation out on the same people
who taught me about this space: the various government labs who do
bomb simulations. A fairly classic application and one that probably
accounts for the vast majority of what is left of the supercomputing
market as well as a huge percentage of the clustering market.

These guys are willing to pay just about any amount of money to get the
node to node latency in a 10,000 CPU fabric down to 10usecs. I'm sure
they would be very interested in your analysis which says they don't
know what they are talking about.

I'm impressed and amazed that with all the bright minds working on this
problem space for the last 30 years, yours is the first one to come up
with a profound advance.

: You're assuming computation is a low overhead compared with
: communication. Consider: suppose the communication per iteration takes
: 1s. Ew, massive latency.
:
: Suppose the computation takes 100s. Communication doesn't look
: so horrible now does it?

That's simply bullshit. Please list 10 applications that have this
sort of CPU to communication ratio.

: Granted, it may be easier to use explicit message passing once you've
: had to think about the messy details anyway...

Ahh, the truth finally shows up to the party, late as usual...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.083 / U:0.700 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site