|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Mon Oct 07, 2019 9:34 am Post subject: |
|
|
There is no point to testing /undef as we know that /undef DOES initialise the arrays, but not with zero.
Regarding FTN95 and performance: FTN95 /64 has been including more /opt features and the work mecej4 has done to help verify them is for all our benefit.
There are a couple of areas where other compilers do (/did?) perform better than FTN95 (another list :-( )
1) vector instructions and loop unrolling
Implementing vector instructions in inner loops can help a lot.
Loop unrolling is done by most compilers, which can combine with vector instructions. Performance benefits of 2x to 4x can be achieved by this improvement.
2) array sections
This was a problem area in FTN95, but I don't know how much this has been improved. A performance problem with array sections as arguments to routines is creating a copy of the section on the stack, then updating the values when returning.
The performance benefits of recognising unnecessary copying can be dramatic, depending on the size of the section.
This can be improved when recognising that the section may already be contiguous or if there is intent (in) or intent (out) in the called routine, so that some copying is not required, although I am a bit lazy when it comes to using "INTENT(...)". Not sure what INTENT is provided for. Should /opt respond to this ?
3) recognition of repeated code
Compilers can do this better than programmers, but this is an area where programmers should be doing better and where a lot of time can be wasted doing code refining, especially when /opt can do it all better.
I agree with John S in this case, as documentation of the 64+ optimisation options could be helpful to understand what is and isn't available.
John |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2391 Location: Yateley, Hants, UK
|
Posted: Mon Oct 07, 2019 12:27 pm Post subject: |
|
|
JohnC
Quote: | There is no point to testing /undef as we know that /undef DOES initialise the arrays, but not with zero. |
Well obviously. The point is that if you move code from compiler to compiler, you can't assume that the allocated memory is set to zero. My suggestion was to test that. Of course, there is conditional compilation, which I don't use either.
Eddie |
|
Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012 Posts: 697 Location: Hamilton, Lanarkshire, Scotland.
|
Posted: Mon Oct 07, 2019 12:52 pm Post subject: |
|
|
Interesting post. I was recently confused when I compiled the following code in release mode!
Code: | module data_mod
implicit none
type something
integer :: no
real*8 :: val
character(len=10) :: name
logical :: inservice
end type something
type(something), allocatable :: datalist(:)
contains
integer function setup()
integer i
allocate(datalist(1:10))
do i = 1, 10
print*, datalist(i)
end do
end function setup
end module data_mod
program main
use data_mod
integer i
i = setup()
end program main |
So derived types are initialised as well!
Ken |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Mon Oct 07, 2019 5:59 pm Post subject: |
|
|
Interesting how Intel sets allocatable arrays. They keep their compiler as fast as possible to show to the public advantages of their processors in performance. Despite zeroising arrays is more convenient there could be cases when not the whole array is needed and in this case zeroising entire array will bring some performance penalty. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|