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
 |
Newsgroups: comp.lang.fortran
From: Dennis Wassel <dennis.was...@googlemail.com>
Date: Tue, 17 Jun 2008 13:05:47 -0700 (PDT)
Local: Tues, Jun 17 2008 4:05 pm
Subject: Re: Global array operations: a performance hit?
On 17 Jun., 20:31, nos...@see.signature (Richard Maine) wrote:
> [snipety-snip] > In answer to Dennis, by the way, it is *VERY* common for whole array After all, when using array operations you have additional information either readily available, or you are able to extract it fairly easy, which is not always the case in DO loops. Talk about aliasing, strides, contingent memory locations etc. But then again, "See point 1". I actually find this hard to believe, but given that I'm rather new to the delightful post-77 Fortran world and haven't really done any serious benchmarking on array operations vs DO loops, I'll gladly trust your judgement on this. Thanks for enlightening us! > 1. Compilers have had over 5 decades of time to develop techniques of OK, here's my newfound corner of gcc development that I feel like > 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. 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 :) > 2. Array temporaries are often a big deal in whole-array expressions. A The Intel compiler (10.1, maybe earlier versions as well) throws 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. 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... > 3. Your example illustrates the problem of "loop fusion". The naive
> (again aka straightforward) application of the rules for your code > example *DOES* imply separate loop for each array operation (complete > with all loop overhead). That's how the operations are defined. It is an > optimization for the compiler to recognize when it can usefully fuse > these multiple loops. See point 1. > -- 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.
| |||||||||||||