forums.silverfrost.com

[DanRRight]

or it is still in arbitrary state?

If not guaranteed being at least zeroised after allocation would be nice to have some kind of new ALLOCATE with initialization at the same time for simplicity.

[PaulLaidler]

Calls to ALLOCATE from FTN95 currently automatically zeroise the memory. This may not be portable to other compilers. The feature is not documented, however, there is no reason to think that it might change.

But if you use /UNDEF (or any option that implies /UNDEF) then the memory is initialised for "undef" checking.

[JohnCampbell]

Paul,

I would question this claim as my understanding is ALLOCATE does not actually allocate the memory pages for the array, but merely reserves memory address range for the array.

It is not until the array is used that the memory is allocated. See the example in the recent "Size of all arrays"

http://forums.silverfrost.com/viewtopic.php?t=4082&postdays=0&postorder=asc&start=0

I could modify this program to test the values of the array before it is initialised. However, I don't think it is standard conforming to use an uninitialised array.

[PaulLaidler]

John

Can you provide an example. When I trace ALLOCATE (without /UNDEF) it leads to a call to HeapAlloc using HEAP_ZERO_MEMORY. This is for 64 bits with a similar call for 32 bits. The documentation for HEAP_ZERO_MEMORY says "The allocated memory will be initialized to zero".

This is not a proof but an illustration...

[LitusSaxonicum]

John-Silver,

When /UNDEF is used, presumably the memory isn't zeroised, it is all set to a value that signifies 'undefined'.

I agree that the historic requirement that the programmer should explicitly provide an initial value for everything before first use is a good practice, and in particular, aids in transferring things to a different compiler. However, the minute you start using Clearwin+, you can't change.

As well as documentation for FTN95, there is also the matter of documenting one's programs, either with comments, or with paper. Perhaps if one wanted to take advantage of automatic zeroisation, it might be worth doing a check. Just how many locations would one need to test (based on statistics) to be confident that the array was, in fact, zeroed?

Eddie

[JohnCampbell]

Paul,

I adapted the previous allocate arrays test I referred to by:
- after allocating the arrays, counted the non-zero values.
- did the test twice, after changing memory to non-zero in first pass

The results are :
1) either initialising (previous test) or testing values results in the memory pages being allocated.
2) all arrays have been initially zero, as you indicated.

Would this only apply to ALLOCATE (heap arrays) only or also stack arrays (local, automatic) or common also ? ( I guess I should check )

Both FTN95 (/32), FTN95 /64 and gFortran perform in this way.

However, I would never use this assumption

John

The revised program:

[JohnCampbell]

program ctd ..

[JohnCampbell]

program ctd ..

[PaulLaidler]

John

Initially you doubted my statement. Is this still the case?

[JohnCampbell]

Paul,

I have changed my tune and no longer doubt you !

Now I understand that FTN95 does initialise allocated arrays.
I also found that with FTN95 /64 that large automatic arrays (that go onto the heap) are also initialised. 64-bit gFortran also appears to have this behaviour.

I tried to test local and automatic arrays for 32-bit, but got a stack overflow (and gave up on this "ugly" approach).
I am not sure what would happen for smaller arrays that do go onto the stack.

However, I have always considered it necessary to initialise an array or variable before it is used, so I will not adopt this "lazy" approach.
I am not sure if first initialising an array is standard conforming, but it should be. I think Eddie agrees with me this time ?

John

PS: the following adaptation appears to show small arrays in the stack are not initialised.

[LitusSaxonicum]

John,

As an 'old dog', the idea that anything is initialised without my express intervention is a 'new trick', and it is my habit to initialise everything.

It's brilliant if things are initialised, but think that this ought to be in response to one of the following:

(a) a compiler directive
(b) a command (that doesn't exist) in standard Fortran
or
(c) a programmed test to see if the compiler did or did not have this as a default.

IN any case, the assumption needs to be commented.

On the other hand, since I consider anyone using anything other than FTN95 as somewhat deranged, because CW+ doesn't exist properly elsewhere, then perhaps it is OK to assume that FTN95's behaviour is the norm.

It still needs a comment in the source code!

Eddie

[DanRRight]

Great that allocated arrays are zeroised. Life will be a bit easier with my 140 arrays which need allocate-check-deallocate-zeroise-allocate-check-deallocate-zeroise-allocate-check-deallocate-zeroise-allocate-check-deallocate-zeroise all the time.

Also looks like lazy allocation of sparse arrays in COMMON becomes the necessity of the past. If keeping lazy allocation is the reason of slow performance of compiler with Poly tests, then may be it should be abandoned. Or kept as a non-standard option

[JohnCampbell]

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

[LitusSaxonicum]

JohnC

[Kenneth_Smith]

Interesting post. I was recently confused when I compiled the following code in release mode!