[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

st: Re: Memory, Stata 10, and 32-bit XP

From   Sylvain Friederich <>
Subject   st: Re: Memory, Stata 10, and 32-bit XP
Date   Fri, 22 Feb 2008 16:56:56 +0000 (GMT)

Hua -- many thanks for this.

I couldn't say I understand all the details, but the
key point is that the problem can *only* be solved by
using another OS. 

This is precisely the clarification I was after and is
not the message I'd had so far from various people,
including Stata's own Tech-support.

I would argue the FAQ could be clearer about this.
Perhaps I'm being dense, but it seems to me it
contains 3 statements:

1. You will not be able to claim as much as 2.1 GB of
contiguous memory under any 32-bit version of Windows.

2. The maximum amount you can actually claim will be

3. Specifically to Stata 10, the maximum amount you
can actually claim will be smaller under XP/SP2 than
under any other OS.

Statements 1 and 3 always seem verified but not 2 (as
I found out). Moreover, the XP hotfix will make not
difference whatsoever to this. 

This is made clear in Hua's message but, I feel, not
in the FAQ.

-- Sylvain

--- Hua Peng <> wrote:

> Dear Sylvain,
> You wrote to Stata list:
>  >
>  >The peculiarity I am facing is that I can always
>  >request 1004m max, and never more.
>  >
>  >I am able to run more instances of Stata 10, and
> again
>  >claim as much as 1004m and no more. It takes about
> 7
>  >instances before the OS denies me 1004m.
>  >
>  >Therefore it doesn't look like DLLs are
> fragmenting
>  >memory quite as described in the FAQ above because
>  >that would seem to cause the amount of available
>  >to be random: "You may be surprised to find that a
>  >1.4-GB dataset loaded fine one time but failed to
> load
>  >later."
>  >
> Well, there are in fact two types of dll problems.
> There are
> a set of dlls always loaded and needed for Stata to
> function properly. They almost always have a fixed
> set of base
> memory address in any Stata instance's virtual
> address space on
> the same machine. That's why you can always request
> 1004m with
> more instances of Stata 10.
> There are some softwares which inject dll(s) into
> all
> running processes. For example, speech and the
> handwriting
> recognition features in Microsoft Office will inject
> dlls into
> all running processes including Stata 10. Depending
> where those
> dlls are injected, the amount of continues memory
> block left for
> Stata can be very random. It looks like your machine
> is not
> suffering this problem.
>  >I interpret this as caused by a process occupying
> the
>  >exact same place in the RAM every time.
> On 32bit windows, any application is working in its
> own
> 2GB virtual address space which is not the physical
> RAM.
> Same dll can be loaded into different application's
> virtual
> address space at the same time.  Since Stata
> requires
> continues virtual address block to load data, the
> address
> the dll is loaded becomes very important since poor
> choice of
> base address can fragment virtual address space. In
> this area,
> Vista is far better than XP since it has a much
> better heap space
> manager. On 32bit Vista, Stata 10 usually can access
> around 1.6GB
> memory.
>  >To identify the process causing trouble, I know I
> can
>  >pull up the list of processes in the Task Manager,
> try
>  >to kill some of them and see whether that makes a
>  >difference
> It won't make a difference.
>  >I'm told I could use a 'memory profiler' to
> analyse
>  >how RAM is used by my machine
> It won't help since your machine has plenty of RAM,
> it's a problem of
> operating system.
> If you need load 1.4GB data, I would strongly
> recommend move your
> machine's operating system to Vista.
> Please feel free to contact me if you need any
> further assistance.
> Best regards,
> Hua
> -- 

Rise to the challenge for Sport Relief with Yahoo! For Good
*   For searches and help try:

© Copyright 1996–2017 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index