Hi Malcolm,
I think you've missed my point here. When trying to find an optimal
solution you can write code like:
if Param[I] = 0 then
...
Run it through your benchmark and see that it runs a certain speed.
Or make 'I' and 'Param' global instead of part of an object and run it
through the benchmark.
Or how about declaring I as a short and trying that.
All youi might find is that some run the same and some done but not know
exactly why.
Or you can, as you and I pointed out, use pointers. A quick look at the
assembler generated would have immediately shown one was efficient and one
was not.
Or, to use your example for testing part of the 32 bit word:
if (i mod 4) = 2 then
Result := True;
if (i and 3) = 2 then
Result := FALSE;
Compile the above into a sample application and then put in a break point
and look at the CPU disassembly.
Your approach using 'mod' generates 7 instructions and 18 bytes. My
approach to use 'and' is based on looking at what the compiler does; which
requires 8 bytes and 2 instructions.
It may well be that when the compiler uses a 'feature' of a particular
processor and does some clever techniques that what's intuitive may or may
not always work; so we have to work a bit harder to figure out why.
IMHO, the code bloat and slow speed of so many applications out there is
often due to simple things like choosing 'mod' over 'and' and array
subscripting instead of pointers. Of hiding so much inside objects that the
levels of indirection result in 95% overhead to access simple variables.
> John Dammeyer wrote:
> >The only way you are going to know which algorithm is the fastest is
> >to study the machine code.
>
> I don't agree. When the Pentium came onto the scene with many
> RISC-like
> qualities, benchmarks of many sequences of code became counter
> intuitive. Techniques that were clearly superior on 486s lost out on
> the Pentium. I would suggest that benchmarking is the only
> way to find a
> 'fastest' algorithm. The site Rob pointed us to:
>
> http://fastcode.sourceforge.net/fastcodeproject/
>
> would seem to indicate significant differences between different
> versions of Pentium even.
>
> My 2 cents.
> -malcolm
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
