Lars Mossberg wrote:
>I have not especially made time studies on my programs since I do not
>normally run extremely large and CPU-consuming tasks.
>But I find the modern Fortran constructs so much easier to work with,
>yielding much less source code and thus less maintenance efforts. That is
>the primary reason for using modern Fortran, of course.
I wholeheartedly agree, particularly in respect of vectorising and some of
the new intrinsics like MATMUL, TRANSPOSE and DOT_PRODUCT. I agree with the
philosophy of "If it ain't broken, don't fix it". However, when I have to
modify any of my application routines, I try to take the opportunity to
vectorise. It reduces code and it is very helpful when debugging because
you are stepping one line of code rather than having to set a break after
each initialising DO loop. An added efficiency for me as a developer.
>But two occasions on efficiency regarding Fortran 77 and Fortran 90 spring
>to my mind.
>Some years ago I was ask to update a program, written in Fortran 77,
>handling Life Cycle Analysis on jet engine components. After I had put in
>the new stuff and modernized some parts I realized that the program spent
>some CPU-time in a so called "Rain-Flow-Count" subroutine. It was an easy
>matter to rewrite this small subroutine using whole array operations, array
>sections and intrinsics like PACK. Not only did the "Rain-Flow-Count" code
>become clearer but it shrunk considerably in size and now only comprises
>some 25 lines of code. But the great thing was that the overall performance
>of the program improved (this one CAN spend a lot of CPU time due to large
>amounts of data) by a factor three to six. And this is regardless of the
>compiler and computer we used (Lahey, Visual Fortran, SIG, VMS). Maybe the
>original code "rain-Flow-Count" was badly written so that the optimizer
>could not do its job. But doesn't the presence and knowledge of modern
>structures on part of the (not so knowledgeable) programmer help him/her
>avoid making such bad non-optimizable code?
I've not had experience with compilers or platforms later than F90, other
than Compaq F95 on Alpha VMS. There is now a qualifier ( a - type thing on
other platforms) which can be used to see the optimisations used for
vector/DO operations. It can make interesting reading especially in
conjunction with a few benchmarks. Possibly the same is available on CVF
and Tru64. It also reports when it cannot optimise a particular loop -- my
dislike of DO WHILE has been vindicated :-)
Earlier in this thread, there was a URL from Doug Sondak (hope that's
correct) of some intrinsic versus loop comparisons he had done. And a day
or so ago, a comment from Van Snyder regarding MATMUL. On my platform, I am
seeing "strange" behaviour with some MATMUL benchmarking and I might try to
put together a small story of what I am seeing this weekend.
>The other case is a matrix module that I have made. When I started working
>on it I used code for some of the functions from a Matrix processor that I
>made in Pascal some years ago and converted it more or less directly into
>Fortran. A matrix "compress" function was then implemented using Ifs and
>Dos. When returning to optimize it I changed into using the PACK intrinsic
>functions and whole arrays and array sections. When testing it I realized
>that I got a performance gain of about four times for this kind of
>construct. This was some years ago so I don't remember what compiler I
>used. It could have been Lahey or Visual Fortran.
>
>So there ARE cases when Fortran 90/95 is more efficient than Fortran 77.
Another interesting qualifier on Alpha VMS (again, might be in CVF and Tru64
compilers) is to compile such that a message is generated at run-time if a
temporary is created. This shows confidence to me in their pride that the
Compaq team have minimised such copy-in/copy-out. It also helps me as a
programmer to see whether I can re-structure my code to minimise this.
I would again ask Walt if, after the many responses/opinions he has had
here, whether he will make his paper available.
Regards, Paddy
Paddy O'Brien,
Transmission Development,
TransGrid,
PO Box A1000, Sydney South,
NSW 2000, Australia
(Street address, 201 Elizabeth Street)
Tel: +61 2 9284-3063
Fax: +61 2 9284-3050
Email: [log in to unmask]
Either "\'" or "\s" (to escape the apostrophe) seems to work for most
people,
but that little whizz-bang apostrophe gives me little spam.
|