Re: Parallelizing (WAS: Death by pointers.)

"John Carter" <ECE@dwaf-hri.pwv.gov.za>
Fri, 29 Sep 1995 06:29:51 GMT

          From comp.compilers

Related articles
Death by pointers. (Was: order of argument evaluation in C++, etc.) johnston@imec.be (1995-08-30)
Re: Death by pointers. jhallen@world.std.com (1995-09-05)
Re: Death by pointers. ECE@dwaf-hri.pwv.gov.za (John Carter) (1995-09-23)
Parallelizing (WAS: Death by pointers.) pardo@cs.washington.edu (1995-09-24)
Re: Parallelizing (WAS: Death by pointers.) ECE@dwaf-hri.pwv.gov.za (John Carter) (1995-09-29)
Re: Parallelizing (WAS: Death by pointers.) preston@tera.com (1995-09-29)
Re: Parallelizing (WAS: Death by pointers.) creedy@mitre.org (1995-10-02)
Re: Parallelizing (WAS: Death by pointers.) stefan.monnier@epfl.ch (Stefan Monnier) (1995-10-03)
Re: Re: Parallelizing (WAS: Death by pointers.) chase@centerline.com (1995-10-04)
Re: Parallelizing (WAS: Death by pointers.) imp@village.org (Warner Losh) (1995-10-11)
Re: Parallelizing (WAS: Death by pointers.) Martin.Jourdan@inria.fr (1995-10-18)
[11 later articles]
| List of all articles for this month |
Newsgroups: comp.compilers
From: "John Carter" <ECE@dwaf-hri.pwv.gov.za>
Keywords: parallel, optimize, comment
Organization: Dpt Water Affairs & Forestry (IWQS)
References: 95-09-030 95-09-061 95-09-120 95-09-145
Date: Fri, 29 Sep 1995 06:29:51 GMT

Greetings All,


Stefan Monnier and David Keppel(Pardo) seem to have missed my point
about simple parallelism. I initially agreed wholeheartedly with
Stef & David, year's back. I even pushed two largish purchasing
choices against parallel processors. But now watching the evolution of
the p5,p6,p7... and the changing OS environment my opinion has swung.


If your aim is, like Amdahl, to make one program run like a bat out
of hell; then odds on it is easier to design a devilishly clever
Uniprocessor. Why? Because fine time grained parallelism is a pain to
design and implement, and supreme headache to write good/reliable
compilers for etc. etc. Conversely devilishly clever uniprocessors
are (almost) equally hairy to design and (almost but not quite) as
difficult to write good compilers for.


My answer? Simple. If you only ever have one and only one program
running on your workstation, use the most devilishly clever
uniprocessor you can afford. However in the last five years I
haven't seen such a site. Whenever I say "ps -aux" I get a list as
long as my arm. Whenever I do a "make", I usually run the compiler
on 10 or more different files...


Therefore one should design and build simple processors, and package
as many of them, coupled very loosely (no shared memory or any such
hairy thing), in a box as you can. Then design simple but good
compilers. Then, one program one processor. Call it Carter's Law.
Pournelle's law was, and is a good law too, "One person, one
computer."


Carter's law is "One program, one processor". Simple processors are
cheap to design. Simple processors are dirt cheap to build, because
you get high yields per run. (Small die size)


And this where this diatribe affects this forum... Simple processors
are MUCH easier to write good compilers for. Far too much effort and
ingenuity of this community is going into rearranging things to
fit smoothly into weird pipelines. As a programmer, I don't really
give a brass fart about pipeline optimization. I really care about
reliable compilers. I really care about language design. I really
care about such things as exception handling, garbage collection etc.
etc. I heartily wish pipeline optimization would go away and let the
compiler writers head for the real issues.




John Carter
Institute for Water Quality Studies. Department of Water Affairs.
Internet : ece@dwaf-hri.pwv.gov.za Phone : 27-12-808-0374x194
Fax : 27-12-808-0338 [Host for Afwater list server]
[Workloads differ. No more polemics on this particular subtopic, please.
-John]
--


Post a followup to this message

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