TextOut() to a DialogBox ???
in [MFC]
|
From: Peter Olcott on 24 Mar 2010 21:11 "Geoff" <geoff(a)invalid.invalid> wrote in message news:f39lq5d0mdhqlv6erljb2io1mgfskqom0c(a)4ax.com... > On Wed, 24 Mar 2010 19:09:23 -0400, Hector Santos > <sant9442(a)nospam.gmail.com> wrote: > >>Geoff wrote: >> >>> >>> Two bugs exist. >>> >>> 1. You never initialize num, so executing num = >>> Data[num] will access >>> a garbage address in debug mode and will attempt to read >>> Data[0] in >>> release mode since the OS will zero-fill num for you. >> >> >>Hmmmmmm, >> >>Geoff, since when did Windows load low? What version of >>Windows? Is >>it chip related? The only variables initializes as zero >>are objects. >>Otherwise all nature types in C are not initialized and >>need to be >>programmatically initialize. So unless there is something >>new in >>Windows Vista/7 I am not aware of. If so, this would be >>new to me. If >>so, I don't know if this would be good or bad since it can >>hide or >>mask a more serious programming bug, but I can understand >>Microsoft >>making the security decision today to load low process >>memory when it >>starts. Probably a safe choice overall, but I still think >>it would >>perpetuate by programming like the way Peter did there, >>probably >>assuming that Windows does indeed always starts memory at >>zero loaded. > > My version is Windows XP. Compiling in VC 6.0 in 32 bit > just to check. > > BTW, num is invariant over his loop, therefore he was > loading from the > same location Max times, hardly a test of memory access > speed, You made a false assumption based on not seeing the rest of the code. I implemented a very simple finite state machine. > wouldn't you say? In release mode a fully optimized > version ran in 0.0 > secs, the compiler deciding that it could obtain 100% core > utilization > by getting rid of the memory access altogether. :) >
From: Peter Olcott on 24 Mar 2010 21:36 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:ux99tZ7yKHA.264(a)TK2MSFTNGP05.phx.gbl... > > Geoff wrote: > >> >> My version is Windows XP. Compiling in VC 6.0 in 32 bit >> just to check. >> >> BTW, num is invariant over his loop, therefore he was >> loading from the >> same location Max times, hardly a test of memory access >> speed, >> wouldn't you say? In release mode a fully optimized >> version ran in 0.0 >> secs, the compiler deciding that it could obtain 100% >> core utilization >> by getting rid of the memory access altogether. :) > > Thats what I first thought, but he was added a randomness > to the access. > > What I had in my code was: > > DWORD num; > for(DWORD r = 0; r < nRepeat; r++) { > for (DWORD i=0; i < size; i++) { > DWORD j = i; // assume serial access > if (bUseRandomIndex) { > j = (rand()*rand())%size; > if (j >= size) continue; > } > num = data[j]; > } > } > > So I can test for a serialize indexing of the huge data > array and compare that with a random j index of access. > > He was basically do the same thing, by initialize the data > array with random index values. then starting at num=0 > (with the fix), he would basically accomplish the same > random intensive. No yours was more CPU intensive thus not maximizing the stress to RAM. > > uint32 num = 0; > for (uint32 N = 0; N < Max; N++) > num = Data[num]; > > Six and one, 1/2 dozen, I guess. But I also told him that > he can produce a scenario set of random numbers where: > > loop 0: num = 0 ---> data[0] --> 5 > loop 1: num = 5 ---> data[5] --> 0 > loop 2: num = 0 ---> data[0] --> 5 > loop 3: num = 5 ---> data[5] --> 0 > loop 4: num = 0 ---> data[0] --> 5 > loop 5: num = 5 ---> data[5] --> 0 > > etc. So in that regard, I think my method eliminates > that. > > Anyway, random jumping across the array spectrum does > indeed seem increase the access time as opposing to a > serial access. For multiple threads, it approaches a > worst case scenario. When serialize, one thread benefits > the other. I guess it would be the same idea of a hard > drive head jumping all over the place. > > What I found interesting is how a pure array is much > faster than std::vector at smaller sizes, but at some > certain size they show the same times. I plan to explore > why, probably the code overhead in the std::vector is > showing up at the small sizes, but factors out when > larger. > > -- > HLS Why am I only getting 121 MB/ Sec of the 12 GB / Sec that MemTest86 reported that I have?
From: Peter Olcott on 24 Mar 2010 21:38 "Liviu" <lab2k1(a)gmail.c0m> wrote in message news:u%23XXPg7yKHA.2552(a)TK2MSFTNGP04.phx.gbl... > "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message > news:0YmdnXNrsfoxMjfWnZ2dnUVZ_oadnZ2d(a)giganews.com... >> "Geoff" <geoff(a)invalid.invalid> wrote in message >> news:qf5lq556kt4oh22dq12c73sp161ogbgqgr(a)4ax.com... >>> On Wed, 24 Mar 2010 15:39:26 -0500, "Peter Olcott" >>> <NoSpam(a)OCR4Screen.com> wrote: >>>>Here is an interesting note that I don't understand. A >>>>slight revision (to make it a little less CPU intensive, >>>>thus more memory intensive) only actually achieves 21 MB >>>>per second >>>>of the 12 GB / second maximum RAM speed. >>>>(RAM speed reported by MemTest86). >>>> >>>>const uint32 size = 100000000; >>>>std::vector<uint32> Data; >>>>uint32 Max = 0x3fffffff; >>>> >>>>void Process() { >>>> clock_t finish; >>>> clock_t start = clock(); >>>> double duration; >>>> uint32 num; >>>> for (uint32 N = 0; N < Max; N++) >>>> num = Data[num]; >>>> finish = clock(); >>>> duration = (double)(finish - start) / CLOCKS_PER_SEC; >>>> printf("%4.2f Seconds\n", duration); >>>> } >>>> >>>>Another thing that I don't understand is that it crashes >>>>when >>>> num = Data[num]; >>>>is replaced by >>>> num = Data[N]; >>> >>> Two bugs exist. >>> >>> 1. You never initialize num [...] >>> >> Right > > Which gives a C4700 compiler warning, btw. Assuming you > somehow > overlooked, or chose to ignore that, the debugger would > have stopped > on the offending line with all the necessary clues to > figure out why. > > You _did_ run it under the debugger before asking for help > on usenet > and waiting many hours to learn the all too obvious > answer... right? > >>> 2. You never resize the vector space "Data" before you >>> attempt to >>> access it. >>> >>> Data.resize(Max); >> >> Wrong. (reserve() has almost the same effect as >> resize() ) >> >> int main() [...] > > Geoff was replying to your earlier post, which showed no > 'reserve'. > You only included the main() part and 'reserve' in the > later followup. > > Liviu > > > I had the whole thing posted yesterday. An error of false assumption is still an error, but then to err is human right?
From: Hector Santos on 24 Mar 2010 21:47 Peter Olcott wrote: > Why am I only getting 121 MB/ Sec of the 12 GB / Sec that > MemTest86 reported that I have? I don't know what data and these rates you are referring too. What is is and how it is calculated? I don't know what memtest86 is (and I don't wish to download it.) -- HLS
From: Peter Olcott on 24 Mar 2010 22:04
"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:eSd4d07yKHA.2644(a)TK2MSFTNGP04.phx.gbl... > Peter Olcott wrote: > >> Why am I only getting 121 MB/ Sec of the 12 GB / Sec that >> MemTest86 reported that I have? > > I don't know what data and these rates you are referring > too. What is is and how it is calculated? I don't know > what memtest86 is (and I don't wish to download it.) > > -- > HLS MemTest86 is a world renown little utility that provides all of your memory specs, and runs through many memory diagnostic tests. It basically will tell you if any part of your memory is not functioning correctly. It Reported all of my cache sizes and speeds and the RAM size and speed. The slowest speed that it reported was RAM Speed of 12 GB / Sec. (It actually reported 11,852 MB /Sec, I rounded a little). |