Date: Sat, 07 Oct 2000 13:42:52 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: Eric Rudd <rudd AT cyberoptics DOT com>
Message-Id: <8011-Sat07Oct2000134251+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.5h
CC: djgpp AT delorie DOT com
In-reply-to: <39DE17F3.A88B4FD7@cyberoptics.com> (message from Eric Rudd on
	Fri, 06 Oct 2000 13:20:36 -0500)
Subject: Re: get the amount of physical memory
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1001003142803 DOT 12455B-100000 AT is> <39DA1E51 DOT D0C53931 AT cyberoptics DOT com> <3405-Wed04Oct2000191356+0300-eliz AT is DOT elta DOT co DOT il> <39DE17F3 DOT A88B4FD7 AT cyberoptics DOT com>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: Eric Rudd <rudd AT cyberoptics DOT com>
> Newsgroups: comp.os.msdos.djgpp
> Date: Fri, 06 Oct 2000 13:20:36 -0500
> 
> I agree that you still don't know whether the operation will succeed in
> advance, but in a DOS program, you can malloc the maximum physical region,
> and the program will succeed if it is possible for it to succeed (and
> complain when it finds out it can't).  In either event, you can call
> realloc() later to free up the unneeded space.  The alternative seems to be
> to place a check inside the inner loop, which slows the program down.

Why isn't the usual paradigm, of reallocing to double the storage when
the current one is exhausted, a reasonable solution in this case?  I
think the overhead of the test and realloc is quite small with this
algorithm.

> > This is impossible with most modern OSes.  Plain DOS and, sometimes,
> > Windows 9X are the only ones that report available physical memory
> > reliably (on Windows 9X, the report is only accurate if no other program
> > works at the same time consuming memory).
> 
> I count this as a deficiency in the OSes, since it means that an app can't
> predict which algorithm would be most efficient.  In my experience, an
> algorithm that expects to work with internal memory, but actually works with
> external (virtual) memory, can be *extremely* slow.

Unfortunately, this is how modern OSes work.  The OS is expected to
handle the paging in the best way possible, while the programmer is
expected to understand the limitations of paging and make memory
references as local as possible, e.g. by rearranging the loops,
changing data structures, etc.

The only alternative is to lock allocated memory, which is hardly a
good solution for large allocations.