From: Joseph M. Newcomer on
See below...
On Wed, 24 Mar 2010 15:39:26 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote:

>
>"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message
>news:ufF$nt3yKHA.928(a)TK2MSFTNGP05.phx.gbl...
>> Peter Olcott wrote:
>>
>>> "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in
>>> message
>>> news:ndgkq5lbilsibpqql11bi0d0tp6b6psl6q(a)4ax.com...
>>
>>
>>>> If you want text on a dialog box, place a static control
>>>> there and use SetWindowText to
>>>> tell it what to display.
>>>
>>> I don't think that will work because I need to specify
>>> every detail of the text, its font, foreground color, et
>>> cetera. In any case this is all moot now anyway. I am
>>> simply bitblt-ing my memory bitmap to the window.
>>>
>>>> Developing the style of writing directly to a dialog box
>>>> surface will eventually uncover a
>>>> large set of problems, none of which you want to deal
>>>> with.
>>>> joe
>>>
>>> This is only for internal testing purposes.
>>
>> Then even more the reason to just use the IDE and controls
>> as to not waste time learning something you will never use
>> anyway - like Intel Chip Caches. :)
>>
>> --
>> HLS
>
>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];
>
****
Another meaningless use of the word "crash". I have no idea what it does. Does it
generate an access fault? Or a bounds check? Duh. This is another "gee, my program
doesn't work, what did I do wrong?" question. Of course, a reasonable bug report would
say "I got an access fault in the above code when the value N is <value told here>" and
you would also have said how big Data is (how many elements in it?).. Otherwise, the bug
report is flummery, and cannot be diagnosed. Unless I run it and obtain the information
that should have been in the bug report. Only amateurs fail to give relevant information
when an error occurs.

I note that the std::Vector Data is not actually set to any value. There is no setsize()
call done to create any objects in the vector, nor any push_back calls. So it is empty.
Furthermore, the integer num is not initialized, so has an undefined value (most likely
0xcccccccc if you are running in debug mode). As written, the code should not work at
all

I am curious why QueryProformanceCounter was not used, but the low-resolution and largely
unreliable clock() function (resolution: 15ms) is used.
joe
****
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 Wed, 24 Mar 2010 18:45:50 -0400, Hector Santos <sant9442(a)nospam.gmail.com> wrote:

>Peter Olcott wrote:
>
>> 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);
>> }
>>
>
>
>All I can see is that you have an uninitialized num variable. When
>not initialized it can be an random number including one that exceeds Max.
>
>So initialize it:
>
> uint32 num = 0;
> for (uint32 N = 0; N < Max; N++)
> num = Data[num];
>
>and see if that solved it for you.
>
>Under Windows, it doesn't have a idea of "Load High" or "Load Low"
>some mainframe folks are use to where your process memory will be
>guaranteed to be non-zero (high) or zero (low). In C/C++ *natural
>or native type* variables MUST be initialized before referenced
>otherwise you will intermittent issues. It didn't happen before only
>because you lucked out the memory was still low, it wasn't dirty and
>num started at zero. But it was bound to rear its head once dirty,
>and there again, it had to be a reference out of range or into
>protected memory.
****
Not only is num uninitialized (which would have probably been evident if we had seen any
meaningful bug report) but the array is empty!

So "crash" could have mean "unhandled exception: array bounds exceeded", but since all we
got was the silly description "crash" there is no way to know what happened. We don't
even know which version of VS was beng used, and whether or not it was compiled Debug or
Release! Remarkable example of how to submit a completely useless "bug" report! ANYTHING
that might have helped us diagnose the problem is missing!
joe

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 Wed, 24 Mar 2010 19:26:04 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote:

>
>"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message
>news:uxSdCP6yKHA.5132(a)TK2MSFTNGP05.phx.gbl...
>> Peter Olcott wrote:
>>
>>> 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);
>>> }
>>>
>>
>>
>> All I can see is that you have an uninitialized num
>> variable. When not initialized it can be an random number
>> including one that exceeds Max.
>>
>> So initialize it:
>>
>> uint32 num = 0;
>> for (uint32 N = 0; N < Max; N++)
>> num = Data[num];
>>
>> and see if that solved it for you.
>>
>> Under Windows, it doesn't have a idea of "Load High" or
>> "Load Low" some mainframe folks are use to where your
>> process memory will be guaranteed to be non-zero (high) or
>> zero (low). In C/C++ *natural or native type* variables
>> MUST be initialized before referenced otherwise you will
>> intermittent issues. It didn't happen before only because
>> you lucked out the memory was still low, it wasn't dirty
>> and num started at zero. But it was bound to rear its
>> head once dirty, and there again, it had to be a reference
>> out of range or into protected memory.
>>
>>
>> --
>> HLS
>
>Of course that was it, and the compiler even warned me about
>this. The only reason that it worked is sometimes the random
>garbage fit into the allocation size.
***
So (a) why didn't you heed the warning and (b) why did you fail to mention this in your
"bug report" (if I can dignify the useless description with such an apellation)
joe

>
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 Wed, 24 Mar 2010 19:31:54 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote:

>
>"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message
>news:uxSdCP6yKHA.5132(a)TK2MSFTNGP05.phx.gbl...
>> Peter Olcott wrote:
>>
>>> void Process() {
>>> clock_t finish;
>>> clock_t start = clock();
>>> double duration;
>>> uint32 num = 0;
>>> 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);
>>> }
>>>
>>
>>
>What explains why I am only using 120 MB of the 12 GB of RAM
>bandwidth?
>Is there a way to stress test memory even more?
>
****
Maybe, just maybe....write a working program! And PUT SOMETHING IN MEMORY! I don't see
anything in memory! You are attempting to access an empty array with an uninitialized
variable.

Maybe, by "crash", you meant a "runtime error" in the 6000-series, "attempt to access
uninitialized variable". But then, if that was what had actually happened, you would have
said that instead of using the noise word (content-free noise word) "crash" when
explaining that your program didn't work!
joe
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
The notion of "load low" and "load high" is pretty irrelevant these days. All program
code loads at a low address, and the stack grows from low addresses upwards. System DLLs
have a relocation base up near the 2GB boundary, so they would, by this definition, "load
high", but ordinary DLLs "load middle" and fragment the address space. Such concepts as
"load low" and "load high" don't reallly related to Windows' model of programming, and as
such we generally ignore them.
joe

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.
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm