Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!decvax!ucbvax!husc6!bu-cs!bzs
From: bzs@bu-cs.BU.EDU (Barry Shein)
Newsgroups: comp.sys.encore
Subject: Re: Need user impressions of Encore Multimax
Message-ID: <20235@bu-cs.BU.EDU>
Date: 28 Feb 88 02:30:30 GMT
References: <690@hqda-ai.UUCP>
Followup-To: comp.sys.encore
Organization: Boston U. Comp. Sci.
Lines: 36
In-reply-to: merlin@hqda-ai.UUCP's message of 26 Feb 88 19:03:22 GMT



From David S. Hayes
>     HAS ANYONE ACTUALLY USED THE MULTIMAX?

We have 7 MultiMaxes at Boston University.  I'd say someone here has
used them. We're currently using them in various environments, the
majority being some form of time-sharing (3 are used for course-work,
Computer Science, Engineering, Adult Ed, others are in VLSI design
labs, a school's administrative database, a departmental general
purpose system which eventually should be supporting a bunch of Suns.)

As far as parallelizing code, the current tools require coding
explicit parallelism via the use of library calls designed for this
(tasks or threads creation and manipulation, semaphores, spinlocks
etc.) I believe there is something in the works for automatic
parallelization, you should probably call them (617-460-0500), I'm
sure they'd be happy to chat about your specific applications. They do
have some tools within the Unix environment, parallel make, grep,
things like that, but I suspect that's not what you're asking about.

I've written and benchmarked a few applications using the parallelism
of the machine (a ray-tracer and a sort routine.) I found the speed-up
to be encouraging (benchmarking the process from 1..N CPUs.) I didn't
have to do anything terribly exotic in the code but they were easily
partitioned tasks (I'm no fool), just splitting up arrays and starting
sub-processes to each do part of the job. I suspect this is the most
attractive sort of problem to attack with hand-coding, usually only
requires dividing the array by the number of CPUs you intend to use
and assigning index ranges to each sub-process. Basically a for() loop
which starts the sub-processes on each segment. The sort needs a merge
phase at the end, but all standard kinds of things.

More importantly, you never begin to understand the paradigm until
you begin using it.

	-Barry Shein, Boston University