forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Do we need to zeroise allocated array ?
Goto page Previous  1, 2
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Mon Oct 07, 2019 9:34 am    Post subject: Reply with quote

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
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Mon Oct 07, 2019 12:27 pm    Post subject: Reply with quote

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
View user's profile Send private message
Kenneth_Smith



Joined: 18 May 2012
Posts: 697
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Mon Oct 07, 2019 12:52 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Mon Oct 07, 2019 5:59 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
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