Alex Granovsky
gran@classic.chem.msu.su
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