# Re: Optimizing Compilers project ideas

## arun@tinton.ccur.com (Arun Kandappan)Sat, 26 Oct 1991 17:24:00 GMT

From comp.compilers

Related articles
Optimizing Compilers project ideas jliu@aludra.usc.edu (1991-10-19)
Re: Optimizing Compilers project ideas firth@sei.cmu.edu (1991-10-24)
Re: Optimizing Compilers project ideas arun@tinton.ccur.com (1991-10-26)
| List of all articles for this month |

 Newsgroups: comp.compilers From: arun@tinton.ccur.com (Arun Kandappan) Keywords: optimize, parallel Organization: Concurrent Computer Corporation, Tinton Falls, NJ References: 91-10-092 91-10-095 Date: Sat, 26 Oct 1991 17:24:00 GMT

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

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
--

Post a followup to this message