Richard Gooch wrote:
> No. My point is that while *some* people will be aware that their
> threaded programme run on DSM will have to be re-coded to avoid lots
> of lock movement, *most* authors of threaded programmes will be
> unaware of this. DSM discourages people from thinking.
No of course it doesn't. First they try it. The lucky few find it is
adequate and they are happy. The rest find that their new $100,000
cluster really sucks with DSM and have to spend the next 6 months
recoding the application to use message passing.
They are forced to think, because they just spent $100,000 and it had
better have been worth the money :-)
> Why buy a 200 node cluster when you can get the same performance with
> a 20 CPU SMP box?
You have a 10MLOC program and you don't have 6 months or the 20
talented programmers who know how to break it up into messages. And
your mate at the institution down the road already has a 200 node
cluster which is idle on Thursday.
Choice 1: hire people (6+ months), understand and change code (6+ months)
Choice 2: turn on DSM and run it on cluster down the road (1-7 days
depend on current weekday)
> > Some people want to prototype on normal clusters, then run the
> > code on fancy hardware. If message passing is slower on the
> > fancy hardware, then prototyping with messages is stupid.
>
> Message passing can't be slower. Even with your automatic DMA
> registers (from the private email you sent), the message passing call
> can simply do a memcpy to the DMA memory area.
Message passing is generally very fast. Unfortunately it's not, with
current designs, autmatic. Unless you count DSM :-)
> Very nice. What's the latency, though? Can you ship a lock in << 100
> ns? Is there a penalty for doing two back-to-back? If you write, is
> the data broadcast to all CPUs/local memory pools? Is the MESI cache
> protocol supported?
What if even a 10ms second lock is perfectly fine? Each computational
iteration between locks might take several seconds or minutes, depending
on your problem.
-- Jamie
-
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/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:18 EST