How hard is socket programming?
in [MFC]
|
Prev: Runtime Error does not specify program???
Next: windows 7 - imitating touch by sending wm_gesture ?
From: Hector Santos on 19 Mar 2010 13:17 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 19 Mar 2010 13:22 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 19 Mar 2010 13:49 "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 19 Mar 2010 17:17 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 19 Mar 2010 17:21
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 |