forums.silverfrost.com

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

Dan,

Thank you for the feedback, although I find your comments somewhat extreme.
"For me 32bit is dead 15-20 years ago". That's 1988-1993. I certainly was not contemplating vitrual disk space of >2gb back then and 3gb came out with XP.

It is good to see that there are a lot of 64-bit pc's being sold now, although where I work is still committed to 32bit architecture.

"With 64bit compiler you will get not factor 1.5-2 but many orders of magnitude more". Hard to believe, but I would like to know any comparison of run-time performance. You would need to differentiate between compute only performance and applications that involved significant disk accessing to run on 32-bit machines.

However, the disk I/O is what is causing me to consider 64-bit. The sample problem I am trying to target, can run on existing 32-bit machines, but when it requires "disk buffering" with blocks of about 1gb in size, there is a lot of time to think wouldn't it be good if this info could stay in memory, especially when you see the price of extra memory.

FTN95-64 would be a great thing to have. To me, certainly much better than FTN95.net. Unfortunately .net appears to have downsized a number of fortran venders. There are a number of new features in fortran 95 + that I am still yet to use (or need), without yet contemplating the benefits of .net. It's a shame that .net has changed the fortran landscape so much.

I am certainly going to investigate what is available in XP64 computing.

Thanks again Dan for your thoughts.

John

PaulLaidler · Posted: Mon Oct 13, 2008 12:27 pm Post subject:

John

I have had a look at your program big_array.f95 which gives the error report "<Program> is not a valid Win32 program".

I suspect that this is a result of the amount of memory being allocated directly in the code.

If you allocate the memory dynamically (you will also have to avoid using COMMON for the arrays) then the dynamic allocation also fails because the chunks are too large.

As before, the point is that you can get more that 2GB in total but you will be limited in chunck size by the existing usage.

I will try to get a more informed opinion about this but it may take time.

Paul

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

Paul,

Can we identify all the reserved parts of memory and shift them in Slink, to provide fewer bigger chunks of memory to allocate ?
There is the heap and the stack. What others ?
Where is the code of all the routines in salflibc.dll ? Is this in the OS above 3gb ?

John

PaulLaidler · Posted: Mon Oct 13, 2008 10:13 pm Post subject:

As far as I know there is no way to do this. The system can move "movable" memory as it deems fit but other programs can allocate fixed memory that no-one can move.

As I keep saying, I am not an expert on this matter and I will try to get a more informed opinion.

PaulLaidler · Posted: Sat Oct 25, 2008 11:57 am Post subject:

I now have a better understanding of the issues involved in memory management.

When an executable starts up, it initially has access to the full address space that is available and it does not matter if other executables are already running. The full address space (not used by the operating system) is normally 2GB but this can be increased to 3GB.

However, when the executable loads up it will invoke DLLs, e.g. salflibc.dll and Microsoft DLLs, and there is no way for SLINK to control how the memory used by the DLLs is allocated. The result is that the programmer has to make do with whatever the operating system can provide.

Regarding your program (big_array.f95), this allocates memory for a large array directly (i.e. at compile time rather than via ALLOCATE at run time). The direct memory allocation is also in the main program which means that the array effectively has the SAVE attribute. SAVEd memory is allocated on a stack that can be increased via a SLINK command. The critical value is the stack reserve that has a default size of 50MB. You can increase this but you will be limited in how far you can push this value for essentially the same reasons that you can only go so far with dynamic memory allocation at runtime.

For your purposes it would be simpler to use dynamic memory allocation (via ALLOCATE) since this would give you a better control and feel for what is happening.

The error message that you get (Program is not a valid Win32 program) is simply a result of the stack being too small. This is a message from the operating system so it is not under our control.

I hope that this helps. I know that this may not solve your problems but I will have to leave it to others with more experience in these matters to advise you further.

LitusSaxonicum · Posted: Sun Oct 26, 2008 11:33 am Post subject:

John,

How about setting up a ramdisk? This technology has been around a long time. http://www.superspeed.com/desktop/ramdisk.php has one that they claim can use unmanaged space (i.e. above 4Gb in XP/Vista 32). You are still going to have to transfer huge chunks of RAM contents, and you need a lot of RAM, but you should see some improvement in run times.

Eddie

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

Paul,
Thanks for your update. I will need to think about it for a while.

Eddie,
I shall follow up what you have said. The idea of a 8gb virtual disk sounds great. I'm not sure of the reality of it all.

John