>> I disagree. The & => && change inserts a conditional branch into the control
>> flow, with the potential to save a single memory access. I count ca. 2 CPU
>> cycles for a memory access and ca. 8 CPU cycles for a conditional jump,
>> therefore I would say that the change slows down the program a bit.
> 
> Surely you are not quibbling about a few extra cycles in the run-time
> of *df*.  This is no hot code path.  I suppose you're merely raising a
> theoretical counterpoint to my absolute statement.
> 
> The benefit of using "&&" over "&" in those cases is precisely to obviate
> that tedious code inspection.  That benefit far outweighs the minuscule
> (and probably not measurable) cost of a few extra CPU cycles in df.

I expect that good compilers (not GCC right now) will convert && to & if
it is profitable to remove a conditional branch (e.g. in "a = b && c"
but not necessarily in "while (b && c)").

Paolo


_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Reply via email to