Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!genrad!teddy!panda!talcott!harvard!seismo!brl-tgr!tgr!ron@BRL-TGR From: Ron NatalieNewsgroups: net.unix Subject: Re: info on array processors wanted Message-ID: <7459@brl-tgr.ARPA> Date: Thu, 17-Jan-85 10:47:20 EST Article-I.D.: brl-tgr.7459 Posted: Thu Jan 17 10:47:20 1985 Date-Received: Sun, 20-Jan-85 06:11:35 EST Sender: news@brl-tgr.ARPA Organization: Ballistic Research Lab Lines: 64 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