Re: sub-optimal code for packed boolean arrays -- bug or inherent limitation

["Steve" <nospam_steved94@comcast.net>]

"Alinabi" <alexander.the.average@gmail.com> wrote in message 
news:1183491750.177186.154490@k29g2000hsd.googlegroups.com...
[snip]
>
> As for the proof that the hand coded version is faster, here it is:
>
> Hand coded: 2 MOV, 1 SHL, 1 XOR
> Compiler:   2 MOV, 1 SHL, 1 XOR, 1 SHR, 1 ROL, 2 AND, 1 OR
> ---------------------
> 5 extraneous instructions, Q.E.D.
>

Twenty years ago I might ave agreed with this logic, but not today.

In the good ole' days you could associate an amount of time with each 
instructions, add them up and get a total amount of execution time.  This 
hasn't been possible for a long time.  Ever heard of "instruction 
scheduling" and "concurrent execution"?

Todays CPU's contain "pipelines" that sometimes merge several operations 
into a single clock.  In some cases you will find that NOP's are added to 
increase the speed of execution based on a detailed knowledge of the 
underlying processor.

I agree with Jeff's assesment.  You must benchmark to measure and compare 
performance.

I work frequently with time intensive code where simulating more 
permutations translate to more value recovered.  These small differences in 
code generation seldom have a significant impact on the overall performance. 
Greater benefits are found by changes to algorithms or approaches to a 
problem.

Regards,
Steve
(The Duck)