philip@Minnie.Stanford.EDU (Philip Machanick) (07/03/90)
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
rjc@cs.ucla.edu (Robert Collins) (07/04/90)
In article <9549@hubcap.clemson.edu> philip@Minnie.Stanford.EDU (Philip Machanick) writes: > >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. [...] >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, [editted] . My remodelled >program was written in C++, using object-oriented programming [editted] > 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. Philip, you say lots about the advantages of programming in C++ vs. FORTRAN, but nothing about programming MIMD vs. SIMD. Ian is right, SIMD is very much easier to program. Imagine what would happen if you programmed a SIMD computer from C++! I have been doing this for a couple of years now, and never want to go back to C, and never want to write a MIMD program. If I ever have to write a program for a MIMD machine, I hope I can do it in a data parallel language. (I have become convinced that the best method for programming in many situations is a data parallel model, built on top of MIMD hardware. This gives us the best of both worlds: ease of programming, and fast execution of conditionals.) rob collins -- ------------------------------------------------------------------------------- rjc@cs.ucla.edu CM++ on the CM2: The only way to fly. -------------------------------------------------------------------------------