Variables >2GB

fanfield · ‎08-09-2006

I have an FORTRAN engineering application currently compiled with Compaq VF v6.1 on Windows 2000 Pro. The MKL is used to speed up the LU decomposition of a very large matrix. It would handle a matrix up to 2GB on a PC with 2GB RAM.

I now have a P4x64 processor with 4GB RAM but have hit the 2GB limit for the IA-32 compiler and OS and so still cannot handle a matrix larger than 2GB. If I upgrade to Windows XPx64, IVF v9.1 with Visual Studio 2005, plus MKL v8.1, will I be able to exceed the 2GB limit for variables and thus be able to fully exploit the 4GB RAM with a matrix of this size?

I realise this may be a trivial question, but I am a physicist, not a computer scientist, so I tend to glaze over when faced with all the latest jargon and I don't want to invest all that money without some assurance it will work.

TimP · ‎08-09-2006

If your big array is ALLOCATABLE, xp64 will allow you to increase its size well beyond 2GB. XP64 and ifort 9.1 should be a worth while upgrade anyway.

Steven_L_Intel1 · ‎08-09-2006

As Tim says, if you run Windows x64 and use the "Intel EM64T" 64-bit compiler, you can have ALLOCATABLE arrays larger than 2GB. Even on Windows x64, static arrays (declared as local variables or in COMMON) are limited to 2GB - that is a Windows restriction.

For example, instead of this:

real bigarray(4000000000)

you would have this:

real, allocatable :: bigarray(:)
...
allocate (bigarray(4000000000))

The rest of the code would not need to change. If the big array is in COMMON, you'll need to change to using modules and make the array a module variable. Let us know if you need help with that.

fanfield · ‎08-11-2006

Thanks Tim and Steve for the replies. At the moment, the variables are declared COMPLEX and are COMMON. I guess they would have to be made allocatable and passed via subroutine calls. This is an old electromagnetics modelling program, which was originally written for mainframe FORTRAN IV in the late 1970s. As we were then, we are still pushing the boundaries of computing limits to tackle ever more complex models.

I guess the first thing I need to do is upgrade the OS and compiler etc, see if I can get it to work and perhaps then call for more help if I need it.

I need to get a few things straight over the tools I need. Is the Intel EM64T 64-bit compiler you refer to Visual Fortan 9.1 and does the MKL 8.1 work with 64-bit? Do I need any special add-ons? I do need the MKL for the LU decomposition routines (which are 3 to 5 times faster than the code in the program for solving the matrix) to keep the run times within reasonable bounds (i.e. several hours).

Also, all the blurb on IVF says I need MS Visual Studio .NET 2002 or 2003. I take it 2005 is also okay (as the earlier versions seem impossible to obtain). At the moment, I only have the one that comes with CVF 6.1 and MS Visual Basic 6.0.

Regards,
Paul

Steven_L_Intel1 · ‎08-11-2006

Yes, we are referring to "Intel Visual Fortran Compiler 9.1 for Intel EM64T-based Applications", which is one of the three compilers you get when you buy Intel Visual Fortran. Visual Studio 2005 is fine and is indicated on our web pages for system requirements. Note that Microsoft dropped .NET from the name for 2005. If you will be doing development for Intel EM64T (now called Intel 64), VS2005 is preferable as you can use it to do development for that platform where you can't do it in VS.NET 2002 or 2003 - you have to use command line tools only.

If you get VS2005, you don't need anything additional, but do read the compiler installation guide carefully to avoid problems. Yes, MKL 8.1 supports Intel 64.

fanfield · ‎08-15-2006

Many thanks Steve, for this information.

I will now set about finding the funds for the new tools - Xmas is coming, so I may be lucky!

Regards,

Paul Carlier

fanfield · ‎03-09-2007

Well, I am picking up this thread again as I have recently acquired XP x64, VS 2005, IVF and MKL. Having removed the large array fromcommon and made it allocatable in a module, I have managed to successfully build and run my program (learning a few things the hard way en-route).

My one remaining issue is really a Windows one, but I have searched elsewhere and can't find a definite answer, so I was hoping you clever lads might know. I have a P4 630 processor on an ASUS P5RD1-V motherboard with 4GB DDR. The System Properties in XP x64 reports only 3.25GB RAM. The question is, is there anyway I can make some more of the 4GB physical RAM available to my program? One or two discussions I have seen on the web suggest it may be a motherboard chipset issue, but I am not sure.

TimP · ‎03-09-2007

If part of your RAM is reserved for hardware devices (most likely, thedisplay adaptor), the only way for Fortran to use that memory would be to reconfigure that device to use less. If it is an on-board device, the remark about the chipset would be reasonably close to target. Look up suspects in Device Manager, see whatresources they reserve,and Google on their model numbers. If they are Intel devices, try the search box at the top of this screen.

As you are running the 64-bit OS, you have the option to install more RAM if your application needs it. You already have more available to your application than you would in 32-bit Windows.

fanfield · ‎03-09-2007

Thanks for the reply Tim. I have a Radeon X300 graphics card in a PCI slot, which takes up 128MB of the system RAM, but apart from that, the only onboard stuff is the usual sound card, network port etc. It seems a bit unreasonable for this to be taking up another 625MB or so.

I am well pleased with the improvement in going to 64 bit anyway, as even with the 3.25GB, I cansolve larger problemsand the increase in speed is remarkable. If I run a smallerproblem that I can run on a 2GB 32 bit PC, in runs in half the time on64 bit. That makes quite a difference, as solving a 20,000 x 20,000 matrix now takes me only 50 minutes. To be able to increase the matrix size a little more would be the icing on the cake. Unfortunately the motherboard on this machine will only support up to 4GB RAM.

Paul

jimdempseyatthecove · ‎03-09-2007

Paul,

In an earlier post you stated "I guess they would have to be made allocatable and passed via subroutine calls."

If the allocatable array (or pointer) is in a module then simply include a USE (that module) in the preamble of the function or subroutine. In this manner the array is directly accessible (as opposed to passing as a argument).

That being said, there are some advantages to using pass by argument. Of particular interest is then the major level routines, (the ones that used to reference the array in COMMON), become non-Hard Wired to a given data structure. When the major level routines are coded with using argument passing then it becomes trivial to use OpenMP to make the major routines run in parallel. i.e. instead of processing one very large array, process two half large arrays at the same time, or quarter size,... then reconcile the data if the data needs to be reconciled. I did read that you are not a programmer, but if you are aware of this, then you know it would be reasonable to seek assistance in this area.

As for the missing 750MB of RAM. Check the BIOS settings for your motherboard and video card. The memory mapped I/O space may by default be located within the low 4GB (to provide for 32-bit O/S support). However, you may have selectable options to map the (or portions of the) I/O space to higher addresses. Jumpers on the motherboard may also control the I/O address space.

The other thing to do in this area is if your motherboard has on board video, disable it, add an extra video card if needed. For about $60, for something like an e-GeForce MX 4000 DDR 128MB PCI. Onboard video used system RAM for video RAM. You can reclaim this RAM by disabling the on-board video. The added benefit for using video card is the performance of your system is not interfered with by video refresh comming through your system memory.

On my 4-core (2 x Opteron 270) Tyan K8SR disabling the onboard video and adding a $60 card not only reclaimed some memory, but more importantly the graphics intensive tasks reclaimed 25% processing capacity (100% of one core consumed by some graphic intensity tasks). Using the video card, the video intensive activities consume < 1% processing capacity. I use two of these video cards in my system, I don't have room in my box for a 3rd (I would have 3 if it could).

Jim Dempsey