Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!adm!bzs@bu-cs.bu.EDU
From: bzs@bu-cs.bu.EDU (Barry Shein)
Newsgroups: comp.unix.wizards
Subject: Large programs
Message-ID: <9679@brl-adm.ARPA>
Date: Wed, 7-Oct-87 16:35:41 EDT
Article-I.D.: brl-adm.9679
Posted: Wed Oct  7 16:35:41 1987
Date-Received: Sat, 10-Oct-87 10:35:54 EDT
Sender: news@brl-adm.ARPA
Lines: 28


>   Admittedly, speed in execution is one of the prices you pay for taking
>the modular approach, but things aren't all that bad.  Piped processes
>get executed concurrently. If you had a parallel processor, who knows,
>maybe each program could be executed on a different processor. The
>pipes could provide a course grain break down of the computing needed. 8-}

Maybe? Don't say maybe, definitely. On our Encores here at BU all
those wonderful habits of piping things and programs forking off
subprocesses and kindred shell scripts etc do just that, each end of
the pipe will tend to be scheduled on its own CPU (the only factor
being of course available processors.) The speed-ups can be tremendous
and it's totally transparent (so much for "gee, where we gonna get
software for parallel processors" we heard a few years ago, the users
are doing true parallel processing here and don't even know it most
of the time.)

Meanwhile the big, hairy application programs will only use one CPU
unless they're re-worked in a major way. And I bet the folks who wrote
most of them said "we can't use pipes, this is a *real* program, we
need speed...", oh well, they lose. Now that Encore, Sequent and many
others are providing this sort of transparent and effective
parallelism (and who will follow?) how many of those packages will
have rendered themselves dinosaurs in record time? I hear even the new
IBM/PC line (PS/2) was designed to have multiple CPUs. Ho hum. Looks
like another software shakeout comin' down the pike.

	-Barry Shein, Boston University