Re: The performance of all kinds of C operations

Keith Thompson wrote:
websnarf@xxxxxxxxx writes:
Nick Keighley wrote:
websnarf@xxxxxxxxx wrote:
Nick Keighley wrote:
websnarf@xxxxxxxxx wrote:
Eric Sosman wrote:
websnarf@xxxxxxxxx wrote:
spibou@xxxxxxxxx wrote:
I didn't read your whole page but had a look at the table in the
section "Strictly for beginners". Can you explain why would
"x = y << 3" be faster than "x = y * 8" ? [...]

I was using a compiler in the '80s that was smart enough to replace * 8
with << 3. Stuff like this in the source just obscures the intent.

Explain how it obscures the intent.

obviously we are not on the same wavelength. If I want to multiply by 8
I write *8. Why would I do anything else? (unless measurement showed
<<3 was faster *and* this line of code needed to be faster).

If shifting by 3 is the *same* as multiplying by 8, then how is
shifting by 8 "doing something else" other than multiplying by 8? Tell
me, why do you think C includes a << operation?

For bitwise shifting, of course. Why do you think C includes a "*"
operation? Even if they happen to be mathematically equivalent in
certain cases, they're *conceptually* very different.

Ignoring pedantry -- no they are *NOT*. This is like your belief that
a == 0 is conceptually different from 0 == a. If they are the same,
then they are the same. They don't gain a difference, conceptual or
otherwise, because they have a syntactical difference.

If I want something to be 8 times as big, I'll multiply it by 8.
(Tomorrow I might decide I want it to be 9 times as big.)

If I want to shift the bits of an object left by 3 positions I'll use
"<< 3".

So if I want to get a tan, should I sit out in the sun or should I go
to a tanning machine? Afterall its a *TAN* -- shouldn't I *USE* the
sun? But the tanning machine *ALSO* gives me a tan ... how do I
decide?

If you see this:

(x << c) * 8, or (x * 8) << c, or (x * 8) & 3

Does your decision still make as much sense?

If the tanning salon is around the corner and I live in Seattle, then
doesn't that help me decide?

Now, if I am concerned about performance, and I know that some
compilers might not catch the *8 -> << 3 transformation, then doesn't
*that* say something about the decision I make?

[...] If shifting is really what I want to do here, I might decide
tomorrow that I want to shift by 4 bits; it's unlikely I'll decide I
want to multiply by 9.

I'll use the multiplication if it expresses what I want to do. If a
shift happens to be more efficient, I'll trust the compile to generate
a shift instruction -- or not to if it can't prove that it's really
equivalent, or if a multiplication is just as fast as a shift.

What if y is negative? (Answer: undefined behavior.)

Not on a serious machine. That the standard chooses to take this
position is not surprising, but not really relevant either. Here's a
challenge for you: Name 3 platforms with a total install base > 1000
independent machines where this is an issue.

[...] What if y is floating-point? (Answer: you can't apply "<<" to floating-point
values.)

Or what if y is a string? That's pretty deep.

Finally, even assuming that y is unsigned or positive, what happens if
I replace this:
x = y * 8 + z;
by this:
x = y << 3 + z;
? The answer depends on the relative precedence of the "*", "+", and
"<<" operators. I don't know about you, but I had to look it up;

That's because you left off the parentheses. C's order of precidence
is stupid, and leaving off the parentheses should be a violation of
every coding guideline in existence. You can't use ioccc techniques to
defend your inability to see an equivalence.

[...] even
if you have all the operator precedences memorized, the next person
who reads your code probably hasn't.

Now, please explain how
x = y << 3;
is *better* than
x = y * 8;
particularly for beginners. (Answer: it isn't.)

Why would I do that? You're not about to pull a CBF here, and drag my
platform-dependent not-C language focused webpages into here and claim
I am teaching C with them are you?

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

.

Relevant Pages

  • Re: The performance of all kinds of C operations
    ... table in the section "Strictly for beginners". ... I was using a compiler in the '80s that was smart enough to ... If shifting by 3 is the *same* as multiplying by 8, ... present an future platforms on which my code might run. ...
    (comp.lang.c)
  • Re: The performance of all kinds of C operations
    ... section "Strictly for beginners". ... I was using a compiler in the '80s that was smart enough to replace * 8 ... If shifting by 3 is the *same* as multiplying by 8, ... If I want to shift the bits of an object left by 3 positions I'll use ...
    (comp.lang.c)
  • Re: The performance of all kinds of C operations
    ... I was using a compiler in the '80s that was smart enough to replace * 8 ... If shifting by 3 is the *same* as multiplying by 8, ... To left shift? ... Unnecessary optimisation is even worse than premature optimisation. ...
    (comp.lang.c)
  • Re: The performance of all kinds of C operations
    ... shifting by 8 "doing something else" other than multiplying by 8? ... If I want to shift the bits of an object left by 3 positions I'll use ... Modern processors are highly complex beasts, ... Those "optimization" are from the days ...
    (comp.lang.c)
  • Re: Most efficient and accurate mathematics?
    ... The conversion to float ... >> Or does the compiler know which order is the most smart? ... > Multiplying ULONGLONG uses a runtime function. ... > mov eax, DWORD PTR x ...
    (microsoft.public.vc.mfc)