Date: Sun, 8 Jun 1997 18:24:37 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Matthew Brendan Grantz <brendan AT jove DOT acs DOT unt DOT edu>
cc: djgpp AT delorie DOT com
Subject: Re: Getting physical...
In-Reply-To: <5mpccb$onj@hermes.acs.unt.edu>
Message-ID: <Pine.SUN.3.91.970608182403.14590V-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On 31 May 1997, Matthew Brendan Grantz wrote:

> Hi. I am writing a simple function whose job it is to copy a file as
> quickly as possible. To do this for large files, I need to find out
> what the maximum ammount of physical memory I can allocate is.

I think you missed a very important issue and are thus looking in a
wrong direction.  Since DJGPP programs use DOS for file I/O, you
cannot read/write a chunk that's larger than 64K bytes in one swell
whoop: this is a DOS limitation.  Therefore, reading/writing larger
chunks will not speed up your program a bit, because low-level I/O
functions (in DJGPP library) break the reads/writes into smaller
pieces.

The optimal chunks are the size of the transfer buffer (16KB by
default).  For maximum speed you need to avoid moving data to and
from the transfer buffer (since you only want to copy it).  See the
source of the `stubify' program in djlsr201.zip, for an example of
such fast copy code.

> This
> would not necessarily be the ammount of free physical memory as given
> by the appropriate __dpmi... function, since, if I allocate a larger
> chunk, some memory currently in physical will be paged out.

No, that's incorrect.  The DPMI function that reports free physical
memory does NOT include physical memory currently occupied by some
code or data.  That's why it's called FREE physical memory.