mrs@packard.UUCP (MR Saltzman) (01/14/85)
Does anyone have any information on array processors that run
under UNIX? I have some modelling programs that take up too
large a chunk of available CPU time on my VAX 11/750. A VAX
11/780 just doesn't seem to provide enough extra bang for the
extra bucks, so we're looking for alternatives. We're running
System V.
Mike Ressler
Commercial Union Capital Corporation
..!pyuxvv!cucc!ressler
212-644-0920roy@phri.UUCP (Roy Smith) (01/16/85)
> Does anyone have any information on array processors that run > under UNIX? ... We're running System V. > >Mike Ressler, Commercial Union Capital Corporation, ..!pyuxvv!cucc!ressler I researched this a while ago while preparing a NSF grant application which is now pending, and this is what I discovered. Floating Point Systems makes a number of models which hook up to a Unibus. There is a company called "Apunix Computer Services" which seems to do nothing except write Unix software for the FPS Hardware (I found out about them through my FPS salesman). They supply a package including a kernel driver, C (and F77??) compiler, assembler for their special 'down to the bare metal' FPP language, a whole package of canned routines, simulator for development of FPP programs, and debugger. It all looks wonderful on paper. Aparantly, they have taken great pains to avoid the problem of needing 10mS of kernal overhead in system calls to perform 50uS of calculations on the FPP. The guy to contact is Peter Berens, Apunix Computer Services, 1380 Garnet Ave, Suite E-292, San Diego, CA 92109 (619)-452-7819, (619)-272-5155. Sorry, I can'l locate the number for FPS, but just look for their ads in most of the trade 'zines. Note, I have not actualy had any experience with any of the hard/soft-ware, this is all from the sales literature and talking with the salesman. (If any body out there >>has<< had any experience with this stuff, I'd be interested to here your opinions). For what it's worth, we asked for a FPS 5205 which we intend to hang off an 11/750, possibly springing for a second unibus adaptor if the unibus bandwidth gets to be a big problem. -- Don't blame me, I just work here.... {allegra,seismo,ihnp4}!vax135!timeinc\ cmcl2!rocky2!cubsvax >!phri!roy (Roy Smith) philabs!cubsvax/
Myra Hartwig (SECAD) <myra@BRL-AOS.ARPA> (01/17/85)
The Ballistic Research Laboratory bought an array processor from Floating Point Systems, Portland, Oregon several years ago. The specific unit we bought (FPS120-AB) to run on a V6-V7-PWB Unix system on an Dec 11/70. The unit was big, heavy, and produced alot of heat. I cannot speak about its usefulness. I understand that FPS now has units like we bought "on a board". When I was dealing with FPS, I thought they were extremely easy to talk to and obtain information from. Myra Hartwig <myra@brl-aos>
Ron Natalie <ron@BRL-TGR> (01/17/85)
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.
-RonBruce Young <young@AMES-NAS.ARPA> (01/17/85)
Developing array processors: CRAY 2 AMES will have (late FY85) a CRAY X-MP 1/2 running under UNIX. However, do not expect a commercial version of UNIX for CRAY until FY86. Using SLAM from P&A, we benchmarked two VAX 11/780's under UNIX a CRAY X-MP 2/2 and a CRAY X-MP 1/2 both running COS. The CRAYs demonstrated wall time improvements about 50 to 1. Thus a model running 4 hours on VAX loaded to factor 5.0 (using ruptime) will run on a CRAY in approximately 5 minutes. One disclaimer is any comparison of VAX to CRAY is full of assumptions about load averages, operating systems, configurations, yet we are pleased with the CRAY performance. Bruce young@AMES-NAS.ARPA
malcolm@ee.UUCP (01/22/85)
If you are interested in buying an array processor for a Unix machine by all means talk to Peter Behrens of APUnix. He can be reached at (619) 452-7819 or (619) 272-5155. He has been very good to us and I highly recomend his services! I don't know all the hardware he is supporting now but the distribution of software that we have for the FPS AP120/B is ifdef'ed for both Bezerkely and System 5. The stories about programming the beasts are partially true. Programming them in microcode would take a real wiz. APUnix has written a vector function chainer that allows basic AP subroutines and some simple loop constructs to be combined into one binary module that can run in the AP without host intervention. This is the only way to use the AP since the AP<->DEC interface is real SLOW (both hardware and software). Anyway, the vector function chainer has syntatic sugar that makes it look like either Fortran or C. Most of the algorithms for my thesis were written in C and called the AP subroutines (things like vector multiply). When they were debugged I ifdef'ed all the fancy features of the language so that all I was left was just the bare numerical code and then compiled it to run on the AP. I've even written routines (in C for the VAX) that let me simulate most of the calls I need on the VAX. This way I can use dbx to debug my programs and be pretty sure they work before I ever touch the AP. (Sure beats doing program development on the AP or the campus CYBER.) And yes our AP isn't a very nice neighbor. We got ours to work by giving the AP its own UBA and not putting anything else on the bus. Let me know if you need any more information. Malcolm Slaney Purdue EE Dept. pur-ee!malcolm malcolm@purdue.arpa