🚀 go-pugleaf

dhosek@hmcvax.claremont.edu (Don Hosek) writes:

>In article <93190.164559AUBXG@ASUACAD.BITNET>, Ben Goren <AUBXG@ASUACAD.BITNET> writes:
>>>Does anyone have an X Windows based public domain PostScript
>>>previewer that runs on a Cray YMP ?    I've checked out
>>>GhostScript, but it apparently hasn't been ported to YMPs,
>>>and I'm not enough of a C hacker to do it.

>> Uh, don't you have somebody who *is* enough of a C hacker? I mean,
>> I have a hard time imagining somebody getting a Cray and not being
>> a C hacker or hiring one.

>Boy, kids today don't know the value of a dollar anymore. Has
>computing advanced so much that there are Cray cycles floating
>around for whoever wants to use them for whatever trivial purpose
>they want to? I remember days when there wasn't even an editor
>available on a cray because the CPU cycles were too valuable to
>waste on something as trivial as editing. One edited one's
>programs on a VAX or IBM, did a test compile there, and then
>moved everything to the Cray. Yes, that was probably overkill,
>but I can't imagine there being any benefit to running GS or
>somesuch on a Cray. Cray cycles have got to still be worth
>_something_, no? And surely you have something else at your site
>which GS could be run on. If people can live with it on 386s and
>the like I'm sure that a Cray is overkill (although I must admit
>that the prospect of that kind of power applied to typesetting
>does make me salivate a little ;-).

     Actually, I think it has been noted that, originally, it was
cheaper to edit on a Cray-1 than other computers of the time because the
cost/cycle was relatively good (at least that is the folklore). 

     In modern times, one may want to use a Cray for a scalar job if it
requires

a lot of memory
a lot of I/O;
has very random memory usage
it is cheaper/easier than sending it to another computer and back
[perhaps other reasons?]

What demands does a PostScript renderer place on computer?

If a site has on hand real mainframes (water cooled, non-vector ES/9000's),
enterprise-servers (AXP 7000/1000), super-workstations (HP 735) in a
transparent network, then the Cray's time could probably be better
utilized if the scalar jobs were run on the appropriate computer:

-Generally, the memory would be mainframe > enterprise-server >
super-workstation.  The job would run on any computer which had enough
memory a(virtual memory is "bad")
-If a job required heavy I/O it would run on either the ES/9000 or the
AXP 10000
-If a job accessed memory in a highly random (or any cache-defeating
pattern), it would run on the ES/9000

Now, we have to maintain a number of computers and high-speed networks
to make this work.  After you bought the Cray, you might not be able to
afford the other stuff (like the ES/9000 or the network or the people to
run the network).

     I have wondered about a design that had four types of memory --
high-speed and low-speed with and without a small processor (one of the
older/simpler RISC's).  It also had logic for vector and cache based
processors.  There would either be page-based semaphors or a
non-blocking crossbar (perhaps the the small processors on-chip could
help manage memory conflicts) so that all processors could work all the
time.  The idea is that you share memory among all the different
processors to avoid waste and improve communication.  The system would
have counters to track cache-faults, wait-states, etc.  

     Start with a cache-based processor and low-speed RAM.  Time goes
on, high-speed, processor based RAM is added.  Jobs that were running
well before, continue on the old hardware except when they need more
memory -- in which case they could compete for the higher-speed memory. 
Since the job is cache-ized, it would use the high-speed memory
reletively rarely (from the point of view of the high-speed memory).  So
free memory cycles on the high-speed memory could be utilized by a MPP
job running on the memory's processor.

     You might think of it as a cross between a Convex C-3/4 and Cray
S-MP (plus a few things).  The main problems I see with it are software
support (compiler mainly) and screwing up critical paths and such.  It
would probably not be fastest at anything.  On the other hand, perhaps
it could be multi-vendor (RISC chips from HP, vector units from Cray,
cheap memory from Korea, fast memory from IBM, etc).  You might think of
it as the network computer idea except that it is one box with shared
memory.  It seems to me that the bigger a network can be physically the
slower it will be.

     Oh well, enough off-subject stuff for now...this probably belongs
in alt.arch or /dev/null or sommething
-- 
Benjamin Z. Goldsteen