Path: utzoo!attcan!uunet!wuarchive!usc!samsung!emory!hubcap!philip
From: philip@Minnie.Stanford.EDU (Philip Machanick)
Newsgroups: comp.parallel
Subject: Ease of programming (was Re: Acceptable efficiency factors)
Message-ID: <9549@hubcap.clemson.edu>
Date: 3 Jul 90 13:08:41 GMT
Sender: fpst@hubcap.clemson.edu
Lines: 51
Approved: parallel@hubcap.clemson.edu


In article <9521@hubcap.clemson.edu>, argosy!ian@decwrl.dec.com (Ian L.
Kaplan) writes:
>   Perhaps the difference in the execution efficiency between the Intel
> cube (an MIMD machine) and the CM-2 (a SIMD machine) is due to the
> fact (not doubt hotly contested) that SIMD systems are easier to
> program.  Easier to program also means easier to fit one's problem to.
> MIMD architecture and programming continues to be a hot topic in the
> computer science research community.  Some people theorize that this
> is because MIMD programming is so difficult that it provides a
> challenging research problem and a fertile field for Phd theses.
>   A term like "ease of programming" is often used without giving much
> definition, so I will try to flesh out my claims.  One definition of
> ease of programming is that much of the machine architecture is
> abstracted and the programmer can think about writing a program that
> describes the problem rather than thinking about shoehorning the
> problem onto the machine.  SIMD systems can be programmed in
> _standard_ Fortran 90.  MIMD systems can only be programmed in a
> language that contains extensions for synchronization.  The SIMD
> programmer need only consider machine architecture when it comes to
> making their program run more efficiently.  The MIMD programmer must
> consider the machine architecture or the program will not run
> deterministicly.

I have recently had an experience of porting a program originally
written for a vector architecture to a shared-memory (MIMD) architecture.
Although the original program was written in C, the general style was
that of a FORTRAN program, with the data strung out into a lot of
separate arrays, with tricks like negative numbers to represent pointers
to boundary condition data (hard to explain briefly...). My remodelled
program was written in C++, using object-oriented programming to
abstract the various aspects of the program which had previously
been scattered around in various arrays. There were two major reasons
for this approach: objects aggregated related data, which made for
better caching performance, and object-oriented programming made the
program more easily modifiable (for example, we were modeling gases,
and it would have been a relatively trivial change to introduce
subclasses to model a multiple-specie gas). Another benefit was I used
subclassing to represent boundary conditions (a cell representing a
region of space was subclassed to represent walls etc.). Sure, I had to
worry about synchronization and load balance, but I found the resulting
program much easier to understand. Synchronization bugs were trivial
compared with the problems I had with understanding details of the
original program.

If you think FORTRAN provides tools to naturally model your problem
domain, then of course SIMD programming will look good. Not all of us
fall in this category, however...

Philip Machanick
philip@pescadero.stanford.edu