Re: Optimizing Compilers project ideas

In 91-10-095 firth@sei.cmu.edu (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
bad.


e.g.
do i = 1,10 => X = 35
a(i) = i Parallel DO
X = 35 do i = 1,10
end do a(i) = i
end do


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.


Arun
#include <std_disclaimer.h>
--
arun
--

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