PC GAMESS/Firefly-related discussion club

Learn how to ask questions correctly

Pasquale Morvillo
pasquale.morvillo@portici.enea.it

On Tue Dec 2 '08 7:00pm, Alex Granovsky wrote
---------------------------------------------
>I think the question on maximum available memory for PC GAMESS/Firefly running under
>Windows and Linux should be finally discussed in all details to avoid any possible
>misunderstanding in the future.

>1.     The PC GAMESS/Firefly is 32-bit program which is however capable to call 64-bit code
>if running under 64-bit Windows or Linux. Formally, the virtual address space of any 32-
>bit program is naturally limited by 4 GB. The ability to call 64-bit code means the ability
>to use 64-bit addressing; however, we are unaware on any way how to map additional
>virtual memory in the address space of formally 32-bit program both under any 64-bit
>Windows and Linux. We are now investigating this problem in details and hope to find
>the solution of how to directly allocate extra memory.
>2.     Windows case: The virtual memory window of any 32-bit process under Windows can be
>limited by either lower 2 GB of address space (plain 32-bit Windows), lower 3 GB of
>address space (e.g., 32-bit Windows with /3gb switch), or 4 GB (under 64-bit Windows).
>However, this memory is not contiguous while PC GAMESS/Firefly requires that the
>memory allocated using MEMORY/MWORDS keywords forms contiguous region. This
>is important because there must be the possibility to use it as the single contiguous array.
>However, within present Windows architecture (all versions) the system DLLs are loaded
>somewhere in the middle of virtual address space of 4 GB. This is mainly because of
>compatibility reasons. Thus, the limitation under Windows is at most 2 GB of memory
>available via MWORDS. The exact map of virtual address space somewhat differs in the
>case of 32-bit and 64-bit Windows and thus 64-bit Windows allows to allocate somewhat
>more memory than 32-bit ones. It should be noted that there are additional ways how
>process can deal with extra memory under Windows, e.g., using AWE (Address
>Windowing Extensions). However, the AWE API is much like old DOS EMS standard
>by its nature and hence cannot be efficiently used in calculations (well, it can be used to
>cache files, etc...). It should be noted that if there is more than 2 GB of virtual memory
>formally available to PC GAMESS/Firefly it is still capable to use this additional amount
>for some special purposes. Note that some stupid programs like antivirus software or
>firewalls can to some degree further limit the available amount of contiguous memory for
>PC GAMESS/Firefly by mapping some additional DLLs into address space of every
>running program. Finally, MPI DLLs consumes some space as well and thus if you need
>as much memory as possible you should use mpibind.seq.dll and run pure serial
>computations.
>3.     Linux case. The virtual memory window of any 32-bit process under modern Linux can
>be limited by either lower 3 GB of address space (32-bit kernels), or 4 GB (most of 64-bit
>kernels and 32-bit kernels compiled with support of 4GB of user space). However, most
>of Linuxes are just as stupid as Windows and maps shared libraries somewhere at about
>the beginning of second GB of virtual address space. Hence, for dynamically linked PC
>GAMESS/Firefly versions, the actual limit can be either 2 GB or 3 GB (well, it is still
>close to 3.75 GB if your Linux supports 4 GB of user address space and uses more
>intelligent strategy to map shared libs). This is why the statically linked version is
>important because it does not use any shared library at all. Thus, it can allocate more
>memory - up to almost 3 GB (or even 3.75 GB if 4 GB of user address space is supported
>by particular Linux kernel). It should be noted that (exactly like Windows version), PC
>GAMESS/Firefly is still capable to use some additional amount of (fragmented by shared
>libs) memory for special purposes.
>4.     Finally, to avoid confusion, note that with PC GAMESS/Firefly 1 MWORDS of memory
>means exactly 8000000 bytes, not 8 MBytes!

>Alex Granovsky