Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucsdhub!hp-sdd!ncr-sd!ncrcae!hubcap!barmar
From: barmar@Think.COM (Barry Margolin)
Newsgroups: comp.parallel
Subject: Re: Virtual processor ratio (was Re: Paris and Programming the Connection Machine)
Message-ID: <8391@hubcap.clemson.edu>
Date: 15 Mar 90 16:04:52 GMT
Sender: fpst@hubcap.clemson.edu
Lines: 24
Approved: parallel@hubcap.clemson.edu

In article <8374@hubcap.clemson.edu> bcsaic!carroll@beaver.cs.washington.edu (Jeff Carroll) writes:
>	I've read a couple of statements now to the effect that
>efficiency improves as virtual processor ratio increases. This seems
>counterintuitive, as I would expect each virtual processor to add
>(superlinearly) to the overhead of "processor management".
>	Would someone please explain?

The efficiency gain is because there is some per-instruction overhead that
is amortized across the virtual processors.  The comparison must be made
between ways of implementing a program that operates on more data elements
than there are PEs.  If the size of your application is larger than the
number of physical processors then there are two ways you can choose to
implement it: 1) iterate in the application code, or 2) use virtual
processors (I'm ignoring CMIS for this discussion).  In the former case
each iteration involves executing front-end code, pushing PARIS
instructions down the FIFO, and decoding the PARIS into CM microcode.  With
VP's, however, these steps are done once; the iteration occurs in the CM
microcontroller after the instruction has been decoded.  At high VP ratios
this overhead amortization can really add up
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar