|Optimizing Compilers project ideas email@example.com (1991-10-19)|
|Re: Optimizing Compilers project ideas firstname.lastname@example.org (1991-10-24)|
|Re: Optimizing Compilers project ideas email@example.com (1991-10-26)|
|From:||firstname.lastname@example.org (Arun Kandappan)|
|Organization:||Concurrent Computer Corporation, Tinton Falls, NJ|
|Date:||Sat, 26 Oct 1991 17:24:00 GMT|
In 91-10-095 email@example.com (Robert Firth) writes:
>... In addition, you could look at the way these
>optimisations interact. For example, on a uniprocessor it is a good idea
>to move loop-invariant expressions out of loops, since the code is then
>executed once rather than many times. Even there, compilers make mistakes
>by doing this to loops that are executed zero or one times.
>But on a multiprocessor, if you can fully parallelize the loop, you don't
>necessarily want to move invariant expressions out of it, since that could
>lengthen the longest thread and so delay the overall computation.
Why not ? As I understand it, the loop is parallelized and thus the
loop-invariant code that is moved out of the loop is executed by the main
thread. The parallel execution of the loop starts after this code. Thus I
think the moving of the loop-invariant code out of a PARALLEL loop is not
do i = 1,10 => X = 35
a(i) = i Parallel DO
X = 35 do i = 1,10
end do a(i) = i
In the above example, since the Parallel DO applies to the loop all
iterations would be equally shortened by the execution (X=35). Thus, IMHO,
it does not seem too bad to move the code X=35 out of the loop.
However, I do agree that scheduling the processes to balance the load
is indeed a very important issue.
Return to the
Search the comp.compilers archives again.