Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!shelby!csli!poser
From: poser@csli.Stanford.EDU (Bill Poser)
Newsgroups: comp.lang.c
Subject: Re: What looks efficient may not be
Summary: Other compilers seem to get this right
Keywords: efficiency, increment operator
Message-ID: <9146@csli.Stanford.EDU>
Date: 29 May 89 04:08:54 GMT
References: <7703@saturn.ucsc.edu>
Sender: poser@csli.Stanford.EDU (Bill Poser)
Distribution: usa
Organization: Center for the Study of Language and Information, Stanford U.
Lines: 38

In article <7703@saturn.ucsc.edu>, ray@saturn.ucsc.edu (Ray Swartz) writes:
> I recently was surprised to discover that 
> 
>      while (i < 500000)
> 	 ++i;
> 
> ran much faster than
> 
>      while (i < 500000))
> 	  i++;
> 
> The test ran on a 68020 based machine.  This test was run without using
> the optimizer.  Here is yet another example that shows that optimizing
> from a higher level language may backfire.

I don't see what this shows about optimizing from a higher level language.
Shouldn't we expect a compiler that doesn't generate identical code for these
two loops to generate faster code for the ++i case because the question of
saving a copy of the unincremented variable does not arise? That is,
presumably what is happening is that the compiler is generating 
(pseudo-assembler) something like:

	addl2 $1 i

for the pre-increment but

	movl i foo		# save unincremented value
	addl2 $1 i
	
for the post-increment.

Of course, a smart compiler will recognize that in these examples
the value of i is never used and will not bother with the save.

I tried these examples on an HP 9000/350 (68020-based) running HPUX 5.22
and a VAX 11/750 running 4.2BSD and got identical assembler output for the
pre- and post-increments (without the optimizer), so it looks like
the compiler on Ray Swartz' machine isn't very smart.