From: Hector Santos on
Also, what is the MEMORY LOAD on this W7 8GB machine, before and after
loading your application?

Hector Santos wrote:

> Peter Olcott wrote:
>
>> "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message
>> news:ea82ZB4xKHA.3304(a)TK2MSFTNGP06.phx.gbl...
>>> Peter Olcott wrote:
>>>
>>>
>>>> I extended your half hour test to 10 hours and nothing was paged out
>>>> on Windows 7 with 8.0 GB RAM.
>>>
>>> How do you know? What measurement counters did you use? And what is
>>> the application doing?
>>>
>>> --
>>> HLS
>>
>> I had windows report all of its paging, and the number did not grow
>> when I re-invoked the DFA process again after ten idle hours. Also
>> (weirdly enough) the performance was a fraction of a percent faster
>> after ten hours of idleness. Execution time went from 3.75 minutes to
>> 3.73 minutes.
>
> What were the following counters?
>
> - page fault
> - context switching rate
> - working set
>
> I'm more interested in the page faults.
>



--
HLS
From: Hector Santos on
Quick code to get the memory load:

// File: V:\bin\memload.cpp
// Compile: cl memload.cpp

#include <windows.h>
#include <stdio.h>

void main(char argc, char *argv[])
{
MEMORYSTATUS ms;
ms.dwLength = sizeof(ms);
GlobalMemoryStatus(&ms);
printf("Memory Load: %d%%",ms.dwMemoryLoad);
}


Hector Santos wrote:

> Also, what is the MEMORY LOAD on this W7 8GB machine, before and after
> loading your application?
>
> Hector Santos wrote:
>
>> Peter Olcott wrote:
>>
>>> "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message
>>> news:ea82ZB4xKHA.3304(a)TK2MSFTNGP06.phx.gbl...
>>>> Peter Olcott wrote:
>>>>
>>>>
>>>>> I extended your half hour test to 10 hours and nothing was paged
>>>>> out on Windows 7 with 8.0 GB RAM.
>>>>
>>>> How do you know? What measurement counters did you use? And what is
>>>> the application doing?
>>>>
>>>> --
>>>> HLS
>>>
>>> I had windows report all of its paging, and the number did not grow
>>> when I re-invoked the DFA process again after ten idle hours. Also
>>> (weirdly enough) the performance was a fraction of a percent faster
>>> after ten hours of idleness. Execution time went from 3.75 minutes to
>>> 3.73 minutes.
>>
>> What were the following counters?
>>
>> - page fault
>> - context switching rate
>> - working set
>>
>> I'm more interested in the page faults.
>>
>
>
>



--
HLS
From: Peter Olcott on

"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message
news:%23CzP5d4xKHA.4492(a)TK2MSFTNGP05.phx.gbl...
>
> Peter Olcott wrote:
>
>> "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in
>> message news:ea82ZB4xKHA.3304(a)TK2MSFTNGP06.phx.gbl...
>>> Peter Olcott wrote:
>>>
>>>
>>>> I extended your half hour test to 10 hours and nothing
>>>> was paged out on Windows 7 with 8.0 GB RAM.
>>>
>>> How do you know? What measurement counters did you use?
>>> And what is the application doing?
>>>
>>> --
>>> HLS
>>
>> I had windows report all of its paging, and the number
>> did not grow when I re-invoked the DFA process again
>> after ten idle hours. Also (weirdly enough) the
>> performance was a fraction of a percent faster after ten
>> hours of idleness. Execution time went from 3.75 minutes
>> to 3.73 minutes.
>
> What were the following counters?
>
> - page fault
> - context switching rate
> - working set
>
> I'm more interested in the page faults.
>
> --
> HLS

Yes there were no (or minimal) page faults after I invoked
the process again after a ten hour wait. The crucial
performance measure for me is that processing time did not
increase at all after the ten hour delay. In fact it
decreased from 3.75 minutes to 3.73 minutes.


From: Joseph M. Newcomer on
The measured different is not signficant. That'saoubt 0.5%. I expect to see typical
values that different by 5% between any two measurements. 0.02 minutes out of 3.75 is not
statistically signficant. if you measure a dozen instances or more and tell me the mean
and standard deviation then you have something worth talking about.
joe
(I regularly give a lecture on how to do performance measurement, and your technique of
generalizing from two samples with minute differences is not scientifically sound)
***

On Fri, 19 Mar 2010 12:49:01 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote:

>
>"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message
>news:%23CzP5d4xKHA.4492(a)TK2MSFTNGP05.phx.gbl...
>>
>> Peter Olcott wrote:
>>
>>> "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in
>>> message news:ea82ZB4xKHA.3304(a)TK2MSFTNGP06.phx.gbl...
>>>> Peter Olcott wrote:
>>>>
>>>>
>>>>> I extended your half hour test to 10 hours and nothing
>>>>> was paged out on Windows 7 with 8.0 GB RAM.
>>>>
>>>> How do you know? What measurement counters did you use?
>>>> And what is the application doing?
>>>>
>>>> --
>>>> HLS
>>>
>>> I had windows report all of its paging, and the number
>>> did not grow when I re-invoked the DFA process again
>>> after ten idle hours. Also (weirdly enough) the
>>> performance was a fraction of a percent faster after ten
>>> hours of idleness. Execution time went from 3.75 minutes
>>> to 3.73 minutes.
>>
>> What were the following counters?
>>
>> - page fault
>> - context switching rate
>> - working set
>>
>> I'm more interested in the page faults.
>>
>> --
>> HLS
>
>Yes there were no (or minimal) page faults after I invoked
>the process again after a ten hour wait. The crucial
>performance measure for me is that processing time did not
>increase at all after the ten hour delay. In fact it
>decreased from 3.75 minutes to 3.73 minutes.
>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on
See below...
On Thu, 18 Mar 2010 11:32:55 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote:

>
>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in
>message news:44i4q51iamfnidn7cji8mvft16if8u6jdl(a)4ax.com...
>> See below...
>> On Wed, 17 Mar 2010 14:01:22 -0500, "Peter Olcott"
>> <NoSpam(a)OCR4Screen.com> wrote:
>>
>> ****
>> Yes, going back to my comment, you are running on Win64,
>> which allows 4GB of user space,
>> which has to account for your heap, all your stacks if
>> multithreaded, your code, and all
>> your support code (various DLLs). I said you can't get
>> 4GB on Win32. You can get it
>> running a Win32 app on Win64.
>> joe
>> ****
>
>Yes and it also looks like converting to 64-bit will cost
>very little system resources. I was thinking that
>std::vector elements would increase in size by four bytes.
>With further consideration this would seem to not be the
>case.
****
You would have to know the representation of your std::vector elements. An element will
add 4 bytes for every 64-bit pointer in it. If there are no pointers, the size would not
change unless you were using _PTR types for integers which are 32 bits wide in 32-bit apps
and 64-bits wide in 64-bit apps.
joe
****
>
>>>
>>>> joe
>>>> Joseph M. Newcomer [MVP]
>>>> email: newcomer(a)flounder.com
>>>> Web: http://www.flounder.com
>>>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>>>
>> Joseph M. Newcomer [MVP]
>> email: newcomer(a)flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm