Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
comp.lang.fortran
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion Global array operations: a performance hit?
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Steven G. Kargl  
View profile  
 More options Jun 17 2008, 4:41 pm
Newsgroups: comp.lang.fortran
From: ka...@troutmask.apl.washington.edu (Steven G. Kargl)
Date: Tue, 17 Jun 2008 20:41:49 +0000 (UTC)
Local: Tues, Jun 17 2008 4:41 pm
Subject: Re: Global array operations: a performance hit?
Print | View thread | Show original | Report this message | Find messages by this author
In article <9e1269be-de8c-4971-857d-e95bf639d...@i76g2000hsf.googlegroups.com>,
        Dennis Wassel <dennis.was...@googlemail.com> writes:

> On 17 Jun., 20:31, nos...@see.signature (Richard Maine) wrote:

>> 1. Compilers have had over 5 decades of time to develop techniques of
>> optimizing loops. Progress has been made in that time. There has only
>> been about a decade or two (some work preceeded the f90 standard; other
>> compilers didn't really start until later) of significant work on
>> optimizing array expressions. Things have improved and are still
>> improving, but it just is not at the level of experience of DO-loop
>> optimization.

> OK, here's my newfound corner of gcc development that I feel like
> doing, as soon as I have more time on my hands than right now. After
> all, despite my earlier ramblings about conciseness and
> maintainability, performance DOES matter in many cases that are
> relevant to me :)

For starters, you can see what gfortran does by using the
-fdump-tree-original option.  Try it with

subroutine po(x,y)
   real x(3,3), y(3,3)
   x = 1.
   y = 0.
   x = matmul(x,y)
end subroutine po

If you're really curious about the internal goop, use -fdump-tree-all.

>> 2. Array temporaries are often a big deal in whole-array expressions. A
>> naive (aka straightforward) applicaion of the rules very often involves
>> such array temporaries, which are expensive in time. The compiler has to
>> do a fair amount of work to figure out whether they can be elided. See
>> point 1. That's probably not the case for your example, but it is a
>> common one.

> The Intel compiler (10.1, maybe earlier versions as well) throws a
> warning at runtime if it finds itself needing to create an array
> temporary; I found myself changing pieces of my code due to those
> warnings.
> Gonna have a look if the gfortran guys already have a feature request
> about this...

There is currently no warning and AFAIK no request for such a feature.
gfortran has fairly decent dependency analysis, but in certain situation
it will err on the safe side and generate a temporary array even if
it isn't necessarily needed.

--
Steve
http://troutmask.apl.washington.edu/~kargl/


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2012 Google