Re: Parallelizing (WAS: Death by pointers.)

pardo@cs.washington.edu (David Keppel) wrote:


> >[Discussion of alias analysis; parallelizing.]
>
> \begin{soapbox}


ditto.


> To summarize, it is very difficult to build a commercially-successful
> multicomputers because uniprocessors keep doing a good job with dusty
> decks, and because it's very expensive to rewrite dusty decks.
> Multicomputers will probably get a *lot* easier to sell once
> data-parallel languages are widely used BUT in order to convince
> anybody to actualy use a data-parallel language you have to sell them
> on the idea that it will help them build better uniprocessor programs,
> too -- faster code, lower development costs, more reliable software,
> simpler maintainance, and so on.


Depends on your application. In a DP environment (all that mundance
stuff likes accounts, ...) multiprocessors are an easy sell. That's
because the OS, DBMS, and TP Monitor (all programmed in C) take the
burden of multiprocessing away from the application developer, who
writes the same code (in his favorite single-threaded language) as
for a uniprocessor. What you want to achieve in this application is
minimum price for desired performance (e.g. transactions processed
per second). The choice between uni- and multi- processors is mostly
irrelevant.


Chris Reedy, Open Systems Center, Z667
The MITRE Corporation, 7525 Colshire Drive, McLean, VA 22102-3481
Email: creedy@mitre.org Phone: (703) 883-7183 FAX: (703) 883-6991
[I once read an IBM tech report that claimed that 10 slow processors give you
considerably less throughput than one 10X processor in most database
applications because of increased lock contention on "hot spot" records.
But I'm not sure that's a compiler issue. -John]


--

Return to the comp.compilers page.
Search the comp.compilers archives again.