forums.silverfrost.com

[KennyT]

I'm getting a failure using GET_STORAGE@ when I try to grab just over 100MB in one go. I'm on windows7-64 bit and there seems to be plenty of space left at the time the error occurs (system memory is about 50% so there should be about 4Gb available of my assigned swap space).

I'm wondering if the 100Mb is a coincidence or whether there's a system (or SLINK?) limit I can change?

K

[KennyT]

Some more info.

The same app running against the same datafile on an XP machine doesn't fail!

K

[LitusSaxonicum]

It would be interesting to know which of the FTN77 storage allocation routines still work (in FTN95), and what their limitations are.

E

[KennyT]

Interestingly, I've got access to "malloc" through a 3rd party library and that fails at exactly the same point!

K

[KennyT]

I've just tried it on a w7-32bit machine without error.

I'm going to defrag and reboot my 64 bit machine overnight just to be certain.

K

[JohnCampbell]

Is it possible to use ALLOCATE. If you compile everything without /DEBUG or more checking, then you should get access to 4gb with ALLOCATE. I have not used GET_STORAGE@ to know if it gets access to above 2gb.

John

[PaulLaidler]

GET_STORAGE@ and ALLOCATE (not /CHECKed) use the same storage allocation. Basically a call to GlobalAlloc.

[KennyT]

I have now defragged and rebooted and the problem remains under w7-64. It's OK under w7-32 and XP32. From browsing the web, it seems I'm not alone so I suspect this is a MS problem, rather than one that can be solved here!

I've seen a mention of a /LARGEADDRESSAWARE switch for C++ compilation and linking. Is there an equivalent in FTN?

K

[JohnCampbell]

K,

I've been using ALLOCATE on Win7-64 and finding it's performance very robust.
If you do not use /check or /debug, then you should get access to nearly 4gb of memory, which I have successfully used.
I have experimented with mapping the available free memory to identify what should be possible. There appears to be a lot of memory defragmentation with SLINK.
A good rule is to allocate the big arrays first, then the smaller ones can go in the remaining spaces. There is always a problem with stack conflict, which can be managed by minimising the use of large local arrays.
I have not used get_storage@ as I am not familiar with a clean way of using the address. To use the address, do you transfer to a
"call interface_routine (core4(addr))"
then use this array in the normal form or is there a simpler way to use the address ? Repeated use of CORE4 is very non-standard fortran.

John

[KennyT]

Hi John,

This is "old code" and the programmer responsible is semi-retired so changing it is not a trivial change but yes the returned address is passed around using core4/ccore as you said. We don't, in this particular case, have control over the order of the allocation as it's determined by the industry standard datafile structure. That datafile essentially says "I've got xxxxMb of data coming up, I'll tell you how it's laid out later!".

All the above doesn't alter the fact that it works perfectly well on 32-bit versions of Windows, but fails under w7-64 on a higher spec machine.

I don't know whether the failure occurs because of the particular size of the block being allocated or the total memory that has been requested to date.

K

edit: I tried, as a test, adding an ALLOCATABLE character buffer but when it tries to grab the 112972564 bytes, I get an "Error 408: ALLOCATE was unable to obtain sufficient storage". So I tried adding a "first time only" ALLOCATE of the same size and that succeeded. So it's not the size of the buffer at the time that's the problem, it must be the total memory requested at that time. I'll do some more tests...

[PaulLaidler]

/LARGEADDRESSAWARE will probably the same as what you get with the SLINK switch /3gb. For details search for 3gb in the current FTN95.chm.

[KennyT]

Thanks Paul! That seems to have fixed it!!!!

K

edit: Interestingly, the app had only requested a total of 350Mb at the time it used to fail!

[JohnCampbell]

K

Is allocation of storage in a loop? There may be missing RETURN_STORAGE@ calls. Failing for 350 mb does not appear to be the explaination, although it would depend on other storage demands.

John

[KennyT]

There might be some small amounts of "leakage", (one can never be certain about these things!!!) but all the major amounts of memory are released once they're finished with.

K

[JohnCampbell]

K,

Look at the load map (.map) and see how much memory is used by static allocation.
In a recent post, I showed that different OS versions have different memory maps of free memory. This free memory is not contguous, so the mix of available array sizes differs between XP and Win7.

However, I would have expected Win7 to be better (??)
With win7-64, you can get access to above 2gb, if you don't use any checking compilation options, this should help.

(Paul, can we get beta access to the /DEBUG fix?)

John