[comp.lang.c] Efficiency Question

torek@elf.ee.lbl.gov (Chris Torek) (02/26/91)

In article <4bmBqau00Uh_M0aHgb@andrew.cmu.edu> rg2c+@andrew.cmu.edu
(Robert Nelson Gasch) writes:
>The basic question I have is this: Since what you are doing (in each
>case) remains basically the same, do such contractions have an impact on
>the resulting code in terms of size and/or speed?

See the preceding discussion on `micro-optimizing loops'.

Generally, if the compiler is worth what you paid for it, source
transformations such as:

	x = x + 1		=>	x++
and
	for (x++; t[x]; x++)	=>	while (t[++x])

make no difference whatsoever, so use the one that is most readable.

Note that, to some extent, making something shorter makes it more
readable.  Taken to an extreme, however, it has the opposite effect.
Readability resides in the mind of the reader; preferences will differ.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov

ckp@grebyn.com (Checkpoint Technologies) (02/26/91)

rg2c+@andrew.cmu.edu (Robert Nelson Gasch) writes:

>Since C gives you the opportunity to condense statements, I was wondering
>what difference to the compiler these 'shortcuts' make. 
>
>   x = x + 1;           can become
>   x += 1;              which can be further condensed to
>   x++;

There's not much reason to use the first form, that I can see. Unless
you're a die-hard Fortran programmer.

The second form as it stands has no real advantage over the third.
On the other hand, consider this fragment:

#define H_WIDTH 1
   int x;                /* current horizontal position */

   /* I draw a (skinny) graphic figure of width H_WIDTH.  Then: */
   x += H_WIDTH;        /* move drawing pen by figure width */  <- versus
   x++;

The first conveys more semantics to the reader.  The second *may* be
faster.  If so, that's tough luck, I still wouldn't use it.  I might
even be willing to argue that the second is *incorrect* in this case.

In article <1991Feb25.181434.6462@ux1.cso.uiuc.edu> gordon@osiris.cso.uiuc.edu (John Gordon) writes:
>	In the above case, the last statement is definitely faster than the
>first one.  Because: in the first statement, the machine has to load 3 
>values into 3 registers and deal with them, whereas in the last statement,
>essentially only 1 register is being used.

Sorry, this has a lot to do with the machine and compiler involved.  Many will
compile all three forms to exactly the same thing (which you admit
later).

I may make a generalization, that a lot of
programmers make assumptions about what C compilers do, by observing
what a particular implementaiton does.  I prefer to assume that the C
compiler will generate code to implement the algorithm I coded, rather
than pick on it's instruction and register usage.  I have plenty of
other things to worry about.

Disclaimer: I don't write real-time code in C. This may be an environment
where nit picking is justified. I'd still rather find faster algorithms
than agonize over such tiny optimizations.
-- 
First comes the logo: C H E C K P O I N T  T E C H N O L O G I E S      / /  
                                                                    \\ / /    
Then, the disclaimer:  All expressed opinions are, indeed, opinions. \  / o
Now for the witty part:    I'm pink, therefore, I'm spam!             \/

volpe@camelback.crd.ge.com (Christopher R Volpe) (02/26/91)

In article <1991Feb26.042023.2097@grebyn.com>, ckp@grebyn.com
(Checkpoint Technologies) writes:
|>rg2c+@andrew.cmu.edu (Robert Nelson Gasch) writes:
|>
|>>Since C gives you the opportunity to condense statements, I was wondering
|>>what difference to the compiler these 'shortcuts' make. 
|>>
|>>   x = x + 1;           can become
|>>   x += 1;              which can be further condensed to
|>>   x++;

Just wanted to point out that "x += 1" cannot be condensed to "x++", but
rather to "++x".
                                                   
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com

session@uncw.UUCP (Zack C. Sessions) (02/27/91)

ckp@grebyn.com (Checkpoint Technologies) writes:

>rg2c+@andrew.cmu.edu (Robert Nelson Gasch) writes:

>>Since C gives you the opportunity to condense statements, I was wondering
>>what difference to the compiler these 'shortcuts' make. 
>>
>>   x = x + 1;           can become
>>   x += 1;              which can be further condensed to
>>   x++;

>There's not much reason to use the first form, that I can see. Unless
>you're a die-hard Fortran programmer.

Ahh, but a perfectly valid statement, nonetheless, which means
perfectly OK to use if you so desire. Therefore, the compiler
must be capable of parsing the statement and generating opject
code. Point is, does the compiler make an optimization pass
at the source level or purely at the object level (or hopefully,
both)? Depends on the compiler. The one I use on my PC doesn't
as far as I know. I would hope C compilers implemented on
university based systems would.

>The second form as it stands has no real advantage over the third.

See same comment above.

>On the other hand, consider this fragment:

>#define H_WIDTH 1
>   int x;                /* current horizontal position */

>   /* I draw a (skinny) graphic figure of width H_WIDTH.  Then: */
>   x += H_WIDTH;        /* move drawing pen by figure width */  <- versus
>   x++;

>The first conveys more semantics to the reader.  The second *may* be
>faster.  If so, that's tough luck, I still wouldn't use it.  I might
>even be willing to argue that the second is *incorrect* in this case.

Irrelavent to the original question.

Zack Sessions
...!ecsvax!uncw!session

6600tom@ucsbuxa.ucsb.edu (Thomas Kwong) (02/27/91)

In article <4bmBqau00Uh_M0aHgb@andrew.cmu.edu> rg2c+@andrew.cmu.edu (Robert Nelson Gasch) writes:

>Since C gives you the opportunity to condense statements, I was wondering
>what difference to the compiler these 'shortcuts' make. 

>For example, you can write:
>   if (x > y)
>       z = x;
>   else
>       x = y;
        ^^^^^
>The same thing can be expressed like this:
>   z = (x > y) ? x : y;

Nope.  It should be
    if (x > y)
	z = x;
    else
	z = u;

-Thomas.

============================================================
     o      |        *   -------------------------
   -----    |-       *   tomkwong@cs.ucsb.edu
     \/     |        *   6600tom@ucsbuxa.ucsb.edu 
  --------  --       *   -------------------------
     __       |      *   
    |  |   |--       *   "The more one think he knows,
    |--|   |--       *    the less he knows."
    |--|   |--       *                       -Menocchio
    |  |   |--       *   "Are you proud of being Chinese?" 
      \|   ------\   *   I say, "Sure, always!"   :-)
============================================================
--

Thomas.

============================================================

cjkuo@locus.com (Chengi Jimmy Kuo) (02/27/91)

ckp@grebyn.com (Checkpoint Technologies) writes:

>In article <1991Feb25.181434.6462@ux1.cso.uiuc.edu> gordon@osiris.cso.uiuc.edu (John Gordon) writes:
>>	In the above case, the last statement is definitely faster than the
>>first one.  Because: in the first statement, the machine has to load 3 
>>values into 3 registers and deal with them, whereas in the last statement,
>>essentially only 1 register is being used.

>Sorry, this has a lot to do with the machine and compiler involved.  Many will
>compile all three forms to exactly the same thing (which you admit
>later).

Every compiler I have seen since 1982 for 8086 based computers equates all the
original cases.  No differences.

Jimmy Kuo
-- 
cjkuo@locus.com
"The correct answer to an either/or question is both!"

wirzenius@cc.helsinki.fi (Lars Wirzenius) (02/27/91)

I won't answer your question, since that has already been answered by 
more knowledgeable people than I, but I just wanted to point out two
mistakes in your examples (at least one of which is a typo, I'm sure,
but nevertheless):

In article <4bmBqau00Uh_M0aHgb@andrew.cmu.edu>, rg2c+@andrew.cmu.edu (Robert Nelson Gasch) writes:
[code edited for brevity]
>    if (x > y) z = x;
>    else       x = y;
> The same thing can be expressed like this:
>    z = (x > y) ? x : y;

..assuming you really meant "else z = y;" in the first version.

>    x++;
>    while (array[x] < max) do_this ();
> which can be written as:
>    while (array[++x] < max) do_this ();

This is not true, since the first version of the loop doesn't increment
i at all.
-- 
Lars "Nitpicking is fun" Wirzenius    wirzenius@cc.helsinki.fi

ckp@grebyn.com (Checkpoint Technologies) (02/27/91)

In article <17112@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com (Christopher R Volpe) writes:
>Just wanted to point out that "x += 1" cannot be condensed to "x++", but
>rather to "++x".

Oh, be that way. :-) In the context you're quoting, both expressions are
equivalent, but they aren't equivalent in all contexts.  (But then, what
is?)  For example, you would be really concerned about this if you're
converting "if (x += 1)" into "if (x++)", since they're not the same.
You could however convert to "if (++x)".

The two *statements* (not expressions) "x++;" and "++x;" are
practically the same,  since they have the side effect of
incrementing x in common, and the result value is discarded.
-- 
First comes the logo: C H E C K P O I N T  T E C H N O L O G I E S      / /  
                                                                    \\ / /    
Then, the disclaimer:  All expressed opinions are, indeed, opinions. \  / o
Now for the witty part:    I'm pink, therefore, I'm spam!             \/

gwyn@smoke.brl.mil (Doug Gwyn) (02/28/91)

In article <17112@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com (Christopher R Volpe) writes:
>Just wanted to point out that "x += 1" cannot be condensed to "x++", but
>rather to "++x".

In a general expression context that is true, but in the specific example
	x++;
either form would be equivalent.

ebergman@isis.cs.du.edu (Eric Bergman-Terrell) (03/01/91)

Back when I was programming C on a PDP-11 many of those C shortcuts
(esp. pre & post increment) often did result in smaller and faster code.

I expect that as optimizing compilers improve, semantically equivalent
blocks of code will tend to result in the same sequence of machine
instructions.

Terrell

garry@ceco.ceco.com (Garry Garrett) (03/02/91)

In article <1991Mar1.014046.20503@isis.cs.du.edu>, ebergman@isis.cs.du.edu (Eric Bergman-Terrell) writes:
> 
> Back when I was programming C on a PDP-11 many of those C shortcuts
> (esp. pre & post increment) often did result in smaller and faster code.
> 
> I expect that as optimizing compilers improve, semantically equivalent
> blocks of code will tend to result in the same sequence of machine
> instructions.
> 
> Terrell


	Admittiedly, most of my shortcuts are desiged to make good use of
the registers.  It is not as important on newer machines because they have
more registers, and often the optimizer can fit several variables into 
registers for you.  There is not cut and dried best answer as some of us
out here still are programming on older machines.  (I too first learned 
C on a PDP-11, where these optimizations made a big difference.  Try programming
on a Z80 driven machine - 3 registers, including the program counter and stack
pointer.)

	All comments about speed should be taken with a grain of salt (and
presumed to have a "On my machine" appened to the front of them).