eugene@eos.UUCP (Eugene Miya) (12/05/89)
With some regularity, I receive requests for suggested texts
on the subject of parallel computing (typically for classes
on the topic) and I regularly used to say that I knew of no single text
which was a good text.
For instance, a reasonable book was
%A William A. Wulf
%A Roy Levin
%A Samuel P. Harbison
%T HYDRA/C.mmp: An Experimental Computer System
%I McGraw-Hill
%D 1981
%K grecommended,
CMU, C.mmp, HYDRA OS,
multiprocessor architecture and operating systems
%K bsatya
But this system is quite old, and no longer existent, which evokes some
criticism. There is a similar new book on the Cm* (also disassembled).
But a common book which I see in use is:
%A Kai Hwang
%A Faye A. Briggs
%T Computer Architecture and Parallel Processing
%I McGraw-Hill
%C New York, NY
%D 1984
%K grecommended, book,
%X This text is quite weighty. It covers much about the interconnection
problem. It's a bit weak on software and algorithms.
The criticism %X it all. The book is very weak in software, and
it proposes inconnection networks without specific thought toward
algorithms. This after all is where parallel compuetrs are weak.
The term "solution looking for a problem" is frequently heard.
There are a few other minor problems as well,
but recently I got around to obtaining and reading a new book.
%A George S. Almasi
%A Allan Gottlieb
%T Highly Parallel Computing
%I Benjamin/Cummings division of Addison Wesley Inc.
%D 1989
%K ISBN # 0-8053-0177-1, book, text, Ultracomputer, grecommended,
%$ $36.95
%X This is a kinda neat book. There are special net
antecdotes which makes this interesting.
This book is HIGHLY recommended as an introductory book on
the topic. If one could influence people on the net, I suggest this text.
Unfortunately I had to special order from Comp Lit in Silcon Valley,
but Stacey's still had a few left on the shelf.
The book takes a balanced approach: a problem or application is given first,
then comes a discussion on software, and only lastly does the book disucss
hardware. The application is a weather problem, nothing classified
which tend to mark many supercomputer applications. The book shows
balance in its approach to solving problems: from dataflow to control flow
(Gottlieb is the well-known architect of the NYU Ultracomputer). A good
example application is important, and people can understand the importance
a difficulty are conveyed (a simple description of the Navier-Stokes
equations are covered).
There is even humor: excellent analogies in footnotes, and two surprises:
excerpts from "Real Programmers Don't Write Specs" adapted from "Real
Programmer's Don't Write Pascal," (p. 150) and "I Dreamed the Real World
had Adopted the Unix Philosophy." (p. 246) They both fit into excellent
contexts. The only thing this book lacks is the April 1, 1984 net spoof
from kremvax! These are real gems which must not be lost with the fleeting
nature of the Usenet. There is other humor as well (Raiders of the
Church-Rosser Theorem).
The book does has its problems: LINPACK is mispelled LINPAK [page 33] (I don't
think Dongarra has seen this book), and the book is oriented toward numeric
crunching as opposed to AND/OR-parallelism found in logic programming,
but unless these are specific needs in Guarded Horn Clauses, this book
is quite adequate for most intro classes. Nor is digital optical computing
mentioned. Don't expect neurocomputing or nanocomputing. I/O is weak.
See the comment about LISP and real programmers; there is a real fear of
scaring off CS majors with math.
I end this review with an excerpt from the above mentioned "Real Programmers.."
summary of programming languages. Why? Because I read most of this book
while in the mountains (on a dare), and because I also once reviewed
a book on compiler construction using lex and yacc reading it between
ski runs on a chair lift. 8) Also it is an officemate's personal favorite:
Real Programmers don't play tennis, or any sport that requires you to
change clothes. Mountain climbing is OK, and real programmers always
wear their climbing boots to work in case a mountain should suddenly
spring up in the middle of a machine room. (Hence rec.bc x-post 8)
What does this have to do with parallel computing? Everything. Get the
book to find out why.
Another gross generalization from
--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
resident cynic at the Rock of Ages Home for Retired Hackers:
"You trust the `reply' command with all those different mailers out there?"
"If my mail does not reach you, please accept my apology."
{ncar,decwrl,hplabs,uunet}!ames!eugene
Support the Free Software Foundation (FSF)