forums.silverfrost.com

[JohnCampbell]

Paul,

While testing ALLOCATE I have come up with a few small bugs.

1) When I converted the program I posted on 29 Sep to a subroutine, I found that the arrays I allocated via the pointer array " integer*4, pointer, dimension(: ) :: ii " ( which works by de-linking the allocated arrays) are not automatically de-allocated when exiting the subroutine. Is this a bug or is it caused by the non-standard use of the pointer re-allocation ? It would be good if all allocated arrays were released when exiting the subroutine.

2) The following program exhibits 2 problems with integer*8 overflow; one with calculation of 2**32 and the other using I8 variable "i8" as an array subscript.

[PaulLaidler]

John

2**32 will be evaluated as a default integer so you will need to use 2_4**32 for the correct result.

I can see other bugs that I need to work on.

Can you post a short program that illustrates the problem about automatic de-allocation. Anything that saves me time means more bug fixes for you guys.

Paul

[JohnCampbell]

Paul,

I have tidied up the memory scan program as a subroutine, which I put in a bigger program, but unfortunately after doing the scan, I could not do much more. The routine relies on the allocated arrays in the scan loop not being released, but the routine is only useful if all allocated arrays are released when the scan_free_memory subroutine finishes. I've posted the program in 2 parts.
The Loop : "Scan if free size changes" was required for other compilers, as available memory can be dynamic. It would be interesting to put an OPEN statement in the middle of the scan and see the change.

Where does ALLOCATE obtain the available memory list from ?

John

[JohnCampbell]

The scan_free_memory subroutine

[PaulLaidler]

John

I have answered the question about ALLOCATE elsewhere on this forum quite recently. From memory I think I said that, unless you are using /CHECK, ALLOCATE leads to a call to something like GlobalAlloc. So the memory alignment and allocation is handled by Microsoft.

Your program is way too big for me to debug. I was looking for a few lines of code that illustrates the ALLOCATE problem that you mentioned.

[JohnCampbell]

Paul,

Thanks, for the info on GlobalAlloc. I will look it up on MSDN.

As for the program I sent, don't be worried about the size, as it is very straight foward.
The function get_free_memory_size uses ALLOCATE and the STAT= return to find the largest available memory for a new array.
The routine Scan_Free_Memory does up to 38 calls to this function then allocates the located memory size to the same pointer array "II"
Each time that II is allocated to a new memory area, the previous allocation is not de-allocated but left as unavailable to ALLOCATE. This action is required for the program to work.
This is the basis of a program you sent me some time ago (in 2008?).
The routine Scan_Free_Memory also sorts these allocated areas and reports them in memory order, noteing the size of the gap between allocated arrays, assumed to be memory not available to ALLOCATE.
It is an interesting map of available memory, showing the size of arrays that could be allocated and the location of what I assume is "reserved" memory.

The problem I reported yesterday is, when I exit Scan_Free_Memory, the (up to) 38 arrays that were created by ALLOCATE are not released. The Fortran 95 standard says this should happen automatically. I do not use a DEALLOCATE statement, as their identification is lost when I re-use the pointer array to point to the next ALLOCATE. I must admit I have limited experience of pointers.
Fixing this problem would depend on how FTN95 keeps track of all arrays that have been allocated in the routine, to be automatically de-allocated.

By the way, all the work I have done on trying to use more memory in my program and reduce the amount of disk I/O, has been with the aim of using a 64-bit address space. This has included improving the reporting of run time performance and disk I/O usage. However performance testing I have done on the 64-bit OS, with only a 32-bit .exe is showing far better run time improvement that any of the gains I have made with changes to the program algorithms. Statistics now show disk I/O elapsed times are minimal. The bottom line is that the 64-bit OS (with 6gb of physical memory) has much better performance for my problems that use about 2gb to 7gb of "effective" memory, using my 32-bit program. I think it is the improved disk I/O buffering available with 6gb of physical memory. More physical memory would probably be better for larger problems.

On the basis of this, if your program uses disk files of say 2 to 10 gb in size, I would certainly recommend switching to 64-bit OS, before contemplating moving to a 64-bit compiler, as there are significant performance gains available in the short term.

John

[JohnCampbell]

Paul,

A smaller example from the previous program

[silverfrost]

[PaulLaidler]

I have now fixed the INTEGER*8 bug for the next release.

Thank you for your program illustrating the behaviour of ALLOCATE for local arrays. As I recall the Fortran 95 standard provided for automatic deallocation of local arrays whilst this was not a feature of Fortran 90.

It seems that this has not been implemented in FTN95, at least not in this context. So for the time being it is necessary to include an explicit DEALLOCATE statement in your code.

In your code, you over write the address of the allocated memory with each cycle of the do loop so (even when FTN95 is fixed) the compiler will only be able to deallocate the memory for the last cycle. In other words the programmer will still need to use the standard intrinsic ALLOCATED if there is any doubt.

I will think about this but presumably the compiler is not expected to generate a runtime fault when memory is ALLOCATEd more than once to the same array without deallocation.

[PaulLaidler]

On further testing I now find that you do get automatic deallocation if you use the ALLOCATABLE rather than the POINTER attribute on the array.

This complies with the standard which does not require automatic deallocation in the case of the POINTER attribute (probably with good reason).