info on array processors wanted

[Ron Natalie]

Four years ago, we bought an FPS AP-120B array processor.  First I'll discuss
why using an outboard array processor on a machine like a VAX or PDP-11 isn't
so easy and then I'll go on to bitch about Fly-By-Night Convolvers.

1.  While the array processor is fast, the bandwidth of it's interface between
the processor and the main-CPU is not.  Unless you have something that you can
program to run in the processor for a long time and spit it's answer out at the
end, you are going to waste a lot of time shuffling intermediate results accross
the interface.

2.  Most array processors are really difficult to program.  It's not like you
can write a C program (or even Fortran) that will run in the array processor.
You end up having to learn the microcode for the array processor, things like
how long after something happens does the results pop out the other side.
Turns out if there was already something in the library that did what you
wanted, it was OK, but we gave up on writing our own code, even after sending
two of our brightest programmers to Oregon to learn from the manufacturer.

3.  The thing is inherently single-user.

Now the problems with FPS.

1.  The AP-120B was delivered, installed, but not tested.  It turns out that
    the UNIBUS interface had a design error in it that caused any other bus
    operation to be messed up while the AP-120 was in operation.  In addition,
    the delivered memory was defective.  We didn't realize this until I got
    the Bus interface fixed.

2.  FPS was of negative utility in getting the problem fixed.  They admitted
    that they had ECO's on the interface to fix the problem (turns out that
    they had never tested the interface out on any machine with a faster UNIBUS
    than a 34, and there was some slop in their timing).  FPS told me I could
    either pay $900 for a new interface or pay one of their technicians by
    the hour, plus travel time to install them for me.

3.  It doesn't come with UNIX support.  This turns out to be the least of the
    problems since some guys at Stanford did a very nice UNIX implementation of
    the host software.  It was also from these guys that I got the ECO's to
    fix problem 2.

So, what to do.
	1.  There are any number of minicomputer manufacturers who make
	    normal UNIX CPU's that run for 4-10 times a 780 for about
	    the same price.

	2.  There are companies that apply micro-parallelism (i.e. a whole
	    slew of 68000's) to a problem.  The main problem is that this
	    is fine if you want to run a bunch of processes at the speed
	    of 1 68000 each, but they lack the capability of handling the
	    parallelism of a single task well.

	3.  Some companies like ELXSI attack problem #2 with their own
	    processors, but suffer the same drawbacks.

	4.  There are some companies that are taking the supercomputer
	    approach (vector, parallelism, and fancy interlocking and
	    compilers to make use of it) with mini and micro technology.
	    ALLIANT computers is one of these.  While I'm bound by a
	    non-disclosure agreement about the details of the implementation,
	    I'll tell you that it is a substantial performance gain
	    for scientific applications than any current mini at a price
	    that is comparable with the current minis.

-Ron