Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!ukma!gatech!hubcap!wen-king
From: wen-king@cit-vax.Caltech.Edu (King Su)
Newsgroups: comp.parallel
Subject: Re: Hmm!
Keywords: HyperCube, Parallel Connection Schemes
Message-ID: <3402@hubcap.UUCP>
Date: 1 Nov 88 17:55:21 GMT
Sender: fpst@hubcap.UUCP
Lines: 33
Approved: parallel@hubcap.clemson.edu

In article <3389@hubcap.UUCP> abali@raksha.eng.ohio-state.edu (Bulent Abali) writes:
>In article <3386@hubcap.UUCP> wen-king@cit-vax.Caltech.Edu (Wen-King Su) writes:
<>
>>Hot
<>spots that are introduced by the communication pattern of the processes
>>can generally be reduced by _RANDOMIZE_ the process placement, something
<>that is un-thinkable when hop time is long.
>
<What is _RANDOMIZE_ ? Could you explain and give some references
>on causes of hot spots in a hypercube and how to avoid them.
<Thanks.
>
<Bulent Abali

I am not implying that I know of the specific cause of hot spots nor am
I refering to hypercubes only.  It is possible that under certain cost
constraints and using a certain routing method, hypercubes will not
exhibit hot spots.  All I have said is that communication hot spots
introduced as a result of communication pattern, coupled with a mapping
strategy that aims at putting interacting processes next to each
others, can usually be reduced, with wormhole routing, by ignoring the
mapping constraint entirely and place the processes randomly in the
machine.  With wormhole routing, distance effect is much less than the
store-and-forward type of routing and we may be able to reduce congestion
by increasing the distance the message must travel.



===========
  Why can't rn do my name right?  It keeps dropping my "Wen-".
-- 
/*------------------------------------------------------------------------*\
| Wen-King Su  wen-king@vlsi.caltech.edu  Caltech Corp of Cosmic Engineers |
\*------------------------------------------------------------------------*/