Re: Optimizing Compilers project ideas (Arun Kandappan)
Sat, 26 Oct 1991 17:24:00 GMT

          From comp.compilers

Related articles
Optimizing Compilers project ideas (1991-10-19)
Re: Optimizing Compilers project ideas (1991-10-24)
Re: Optimizing Compilers project ideas (1991-10-26)
| List of all articles for this month |

Newsgroups: comp.compilers
From: (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 (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
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.

#include <std_disclaimer.h>

Post a followup to this message

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