Re: The inaugural VB6 vs dot net test

"Ulrich Korndoerfer" <ulrich_wants_nospam@xxxxxxxxxxxx> wrote in message news:OY10nF8MIHA.5040@xxxxxxxxxxxxxxxxxxxxxxx

. . . and changed the loop direction in Invert1 back to
counting from 0 up. Counting down actually is slower.

Yep. That's why I counted up in my own code. In this particular case counting down means you are addressing the bitmap memory in a "top down" fashion as well, which kind of "goes against the grain" of the memory cache, hence slowing the code down.

Now both methods are equally fast. Invert3 respects padding
bits, but is optimized for 24bpp, Invert1 is more general
regarding the bpp, but changes padding bits.
// New test results
Compiled to native code, settings are:
"Compile for speed, use *all* extended optimizations"
Intel Core 2 Duo @ 1.86 GHz
1024 x 768 bitmap, 24 bits per pixel
1001 iterations per run, 3 runs
Invert1: 1.504, 1.508, 1.505 sec
Invert3: 1.503, 1.502, 1.504 sec

I'm getting 5.512, 5.461, 5.495 on my own AMD Athlon 3000+ (2.2 Ghz) machine, which just a bit faster than the 6.133, 6.156, 6.166 that I'm getting with my own code. There isn't much of a difference, and I expect it might be because all my code is in the Form whereas your main code is in a module, which might make a bit of difference. Might try using a module for my own code later to see if it makes a difference. Not that it really matters of course, because the speeds are pretty much the same anyway.

What /is/ interesting though is how much faster your Core 2 Duo 1.86 Ghz runs. I've been putting off getting a new machine for a long time now, thinking that they are not yet fast enough to warrant the change, but having seen your figures I think I'm going to get one pretty soon :-) If one core runs so much faster than my own machine then it should fairly fly when running stuff optimized for two cores. Or maybe I'll wait for the 256 core machines to appear ;-)

Mike





.

Loading