Re: 32-bit programs on Windows x64

See below...

On Fri, 4 Jul 2008 11:36:34 -0500, "Peter Olcott" <NoSpam@xxxxxxxxxxxxx> wrote:


"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in
message news:ntvq64djji32o6smjpgqj7soo397b09ilk@xxxxxxxxxx
There is no way to discover this. There are so many
processes running that if you really
need 4GB of physical memory available to hold your entire
process, you will need at least
an 8GB machine, AND EVEN THEN THERE IS NO GUARANTEE THAT
PAGING WILL NOT OCCUR. It is
essentially not under your control. You can try
::VirtualLock, but it doesn't guarantee
that you can lock things down (and you need special admin
configuration parameters to
allow it to work at all, and you have to set your working
set quota).

Any belief that Windows can sustain real-time behavior is
based on various delusional
systems. It is not real-time and any illusion that it is
real-time is just that, an
illusion.

A swapping operation takes 10-50ms depending on a variety
of parameters. But it is
impossible to process 4.2GB of data in 1/10 of a second
using ANY algorithm, even if there
is nothing going on. Therefore the only thing that
matters is the actual working set.

My system requires 4 GB to store its DFA pixel pattern
recognizer. To match any particular pixel pattern only
requires traversing a tiny subset of this 4 GB of data. The
4 GB of data is required so that millions of different pixel
patterns can be concurrently matched.
****
First, note that you are never going to get 4GB, and in fact never going to get 2GB, on a
standard Win32 installation. If you are lucky, you *might* get 1.5GB on a good day. No
promises.

If you run a Win32 app on a Win64 system, you will not get 4GB. You might get, under
ideal conditions, about 3.5, but that might be optimistic. I don't know how the basic
allocator works near that level of stress.

Concurrently matched sounds suspicious. How many threads running on how many processors
is the first question about concurrency. Every thread > total processors slows a
compute-bound computation down.

So it then boils down to how many patterns/sec you can match. Note that the L2 cache is
probably going to cost you an order of magnitude performance already.
joe
*****
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=7046848.PN.&OS=PN/7046848&RS=PN/7046848


Perhaps you really have an infeasible project.
joe


On Thu, 3 Jul 2008 14:03:01 -0700 (PDT), PeteOlcott
<PeteOlcott@xxxxxxxxx> wrote:

What part of "virtual memory is not physical memory" are
you missing. I've said this
eight or ten or a dozen times, VIRTUAL MEMORY IS NOT
PHYSICAL MEMORY.

Not only does my process require 4.0 GB of RAM, it is also
time
critical. If there is any swapping to and from VM, then
the current
project becomes infeasible. I must know how much actual
RAM is
available to my process, even though this actual RAM will
be mapped to
VM. If three is any swapping to and from disk, the current
project
becomes infeasible, my maximum response time is 1/10
second.
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.