Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?)

larus@primost.cs.wisc.edu (James Larus)
Thu, 7 Jun 90 01:03:49 GMT

          From comp.compilers

Related articles
[2 earlier articles]
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) MERRIMAN@ccavax.camb.com (George Merriman -- CCA/NY) (1990-06-05)
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) mike@hpfcso.hp.com (1990-06-05)
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) pardo@cs.washington.edu (1990-06-05)
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) robinson@cs.dal.ca (1990-06-05)
Unsafe Optimizations (WAS: Compiler Design in C How about it?) stewart@sdsu.edu (1990-06-05)
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) poser@csli.stanford.edu (1990-06-06)
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) larus@primost.cs.wisc.edu (1990-06-07)
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) tli@%phakt.usc.edu (1990-06-07)
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) moss@cs.umass.edu (1990-06-10)
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) cwitty@csli.Stanford.EDU (1990-06-14)
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) moss@cs.umass.edu (1990-06-14)
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) pardo@june.cs.washington.edu (1990-06-15)
| List of all articles for this month |

Newsgroups: comp.compilers
From: larus@primost.cs.wisc.edu (James Larus)
References: <1990Jun6.032145.5495@esegue.segue.boston.ma.us> <1990Jun4.044255.14857@esegue.segue.boston.ma.us> <1990Jun1.194941.5781@esegue.segue.boston.ma.us> <1990Jun4.212226.18389@esegue.segue.boston.ma.us>
Date: Thu, 7 Jun 90 01:03:49 GMT
Organization: University of Wisconsin--Madison
Keywords: optimize, parallel

OK, now that everybody is interested in this argument, let me continue it.
Previously, I contended that "unsafe optimizations" are necessary for parallel
machines because without them, a programmer cannot express parallel
algorithms. A number of people jump on me and pointed out that what is really
needed is a new language that allows a programmer to express his or her
intent. I agree entirely, however a lot of programmers are stuck using
Fortran and C and will be using these languages for a long time.


Let's make this argument more concrete. Consider the example of summing the
elements of a vector:


for i <- 1 to n do
sum <- sum + A[i]


This operation takes O(n) time. However, on a parallel computer with
sufficient processors, it can take O(lg n) time by using a parallel prefix
algorithm that builds up a tree of additions. The problem is that this
optimization requires addition to be associative. Integer and floating point
addition isn't associative. However, how many programmers have carefully
analyzed their algorithm and convinced themselves that summing the elements
from 1 to N will produce the least error? When was the last time you did
that? Most programmers simply write the above loop as the most convenient
idiom for summing the vector. Although parallel prefix may produce a different
result, which is right and which is wrong?


Of course, some languages such as Fortran 90 permit a programmer to express
his intent in a manner that gives the compiler information about when order
matters. Unfortunately, such languages are rare and only include a few common
idioms.


/Jim
[I suppose there is merit to this suggestion, but the thought of an optimizer
that second guesses the programmer and attempts to generate code for what the
program would have said if the source language was different fills me with
considerable unease. -John]
--


Post a followup to this message

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