🚀 go-pugleaf

>>>>> On 19 Jun 91 09:18:53 GMT, tonys@pyra.co.uk (Tony Shaughnessy) said:

Tony> In article <64739@bbn.BBN.COM> slackey@BBN.COM (Stan Lackey) writes:
>
>I once worked on a machine that had instructions like x=min(y,z) in
>hardware.  Also there were vector instructions that would elementwise
>compare vectors and build a vector of logicals which could be applied
>to a subsequent vector op.  So a loop of the form
>
>  where (a(i) .lt. b(i)) c(i) = d(i) + e(i)
>
>could be done with two vector instructions and no branches (other than
>loop control, of course).
>
>-Stan

Tony> How many cycles would it take to run each of these instructions?
Tony> If it would take many cycles, then wouldn't this dominate any
Tony> expense incurred in taking a branch, or are there other reasons
Tony> for avoiding a branch?

On the Cyber 205/ETA-10, the second instruction requires one cycle per
element, whether the result is stored or not.  I think that the first
instruction also requires one cycle per element.  Then add two vector
startups to the total time required.  So the cycle count is something
like (on the Cyber 205):

	WHERE block: 140 + 2*N
	original op:  70 +   N	(No IF tests -- compute at all locations)

For long vectors, if a(i)<b(i) half of the time, then the WHERE block
above will run at 1/4 the MFLOPS rate of the basic loop.  If you get
to re-use the control vector generated by the comparison, then you can
amortize the overhead cost of the comparison over all of its uses.
(The compiler was never smart enough to do this for you, so you had to
create a bit vector manually and use it explicitly).

Since scalar code tended to be a bit slow on the Cyber 205/ETA-10
machines, the point at which the scalar and vector codes ran at the
same speed might be (for long vectors) where a(i) .lt. b(i) is true at
least 15-20% of the time.
--
John D. McCalpin			mccalpin@perelandra.cms.udel.edu
Assistant Professor			mccalpin@brahms.udel.edu
College of Marine Studies, U. Del.	J.MCCALPIN/OMNET