Harald Boegeholz writes in his message of 1994/10/14 23:10

GAPs memory management works in such a way that it periodically has to
collect garbage. During this process, practically all memory in GAPs
workspace gets touched. Which means that if you use GAP under _any_
operating system with virtual memory (even extended DOS is such an
operating system), you will get extremely poor results if you specify
more than your physical memory size. This is because for every garbage
collection, the swapper will have to pull the whole workspace
"through" the real memory and swap it out again causing heavy disk
I/O.

Actually it is even worse than that, because the first (mark) phase
of the garbage collection touches the storage in an almost random order.
That means that Gasman (GAP's storage manager) causes tons of page
faults if the workspace size exceeds the available real storage size.

Do as Harald suggests, use GAP's '-g' option.
This displays a single information line for every garbage collection.
This line usually helps in deciding whether you want to give GAP
more or less storage.

If GAP does thousands of garbage collections, each freeing only very
little storage, then you know that you gave GAP too little storage.
Namely GAP will extend the worspace only when it absolutely has to.
So in some computations the given workspace is barely enough,
but GAP has to do many garbage collections, each freeing only
several KByte of storage. In extreme cases GAP spends most of
its time in garbage collections, meaning that it will run *much*
faster if you give it a little bit more storage.

If GAP does few garbage collections, but each takes very long (especially
in the first phase, which takes place between the printing of '#G' and
the first numbers), then you gave GAP too much storage. Namely each
garbage collection causes many page faults, and giving GAP a little bit
less storage will make it quite a bit faster.

For single user systems (personal computers and single user workstations)
something like main memory size - 4 MByte (2 for the operating system
and 2 for the GAP executable and GAP's static data) is usually a good
rule of thumb. (This together with the fact that GAP 3.4 needs
at least 4 MByte of workspace for any serious computation means that
GAP 3.4 will not run well on 4 MByte systems; hopefully future versions
of GAP will be less demanding).

Harald continues

Maybe one of the GAP developers (Martin?) can confirm that in theory
(if you have enough physical memory), a larger workspace should by no
means slow GAP down. (I hope it is designed this way.)

The time for the basic computation is indepedent of the size of the
workspace. But a larger workspace means fewer garbage collections
and thus faster runtime.

But there are secondary effects, which counter this effect. Once you hit
virtual memory each garbage collection will take much longer (so the
total runtime increases, even if there are fewer garbage collections).
Sometimes there are also strange interactions with the cache (especially
direct mapped caches, such as the ones used on HP workstations), but they
are generally so unpredictable, that you shouldn't bother.

Martin.

-- .- .-. - .. -.  .-.. --- ...- . ...  .- -. -. .. -.- .-
Martin Sch"onert,   Martin.Schoenert@Math.RWTH-Aachen.DE,   +49 241 804551
Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, 52056 Aachen, Germany