forums.silverfrost.com

JohnCampbell · Joined: 16 Feb 2006 Posts: 2621 Location: Sydney

Sebastian,

Thanks very much for your feedback. I think I understand what you are saying. I know I can not speak for your field, but in my areas of computation there are alternatives. Out of core solutions can be done.
However, moving to in-core can result in significant speed increases offering the opportunity for larger problems or more itterations and greater accuracy.
One thing that has worried me is, if the matrix size is proportional to n^3, it does not take much scaling to run out of physical memory, even in a 64-bit solution.
Perhaps out-of-core and a 256gb SSD offers a more practical solution when scaleing up the problem.
One thing I have recently noticed that with improved disk cacheing reducing the effective disk I/O delays, my focus has returned to computational speed. Having access to the vector instructions could speed up run times, especially for dot_product and other array intrinsics.

I don't know about you, but I do not have the budget to test many options so I have to target solutions which suit a broard range of problems I am solving. I'd be interested in other experiences.

John

PaulLaidler · Posted: Wed Feb 22, 2012 4:18 pm Post subject:

I have investigated John's original query on this thread.

FTN95 allocates memory in the conventional way for /debug.
It uses its own restricted allocation approach for /check.
This means that the compiler does not limit the memory allocation for /debug.

SLINK cannot not distinguish between object code created by the compiler using /debug from that created using /check so it assumes the worst case.
If you are running SLINK directly (rather than via the compiler /LINK) then you can use /3gb on the SLINK command line when you know that /debug but not /check has been used.

I have added /3gb to the SLINK command invoked by FTN95 (with /LINK).
This means that, in the next release of FTN95, you will get the 3gb when /link is used together with /debug but without /check (otherwise 3gb is the SLINK default).

JohnCampbell · Joined: 16 Feb 2006 Posts: 2621 Location: Sydney

Paul,

Thank you for following that up. It will provide access to 4gb and a better error report for testing code.
I will update my batch files and see what happens with the next release. When running on XP_64 or Windows7_64, you actually get access to 4gb with ALLOCATE, which is more useful.

John