Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mit-eddie!uw-beaver!cornell!rochester!pt.cs.cmu.edu!cadre!pitt!unix.cis.pittsburgh.edu!jcbst3
From: jcbst3@unix.cis.pittsburgh.edu (James C. Benz)
Newsgroups: comp.lang.c
Subject: Re: Yet Another Silly Question
Message-ID: <18229@unix.cis.pittsburgh.edu>
Date: 31 May 89 17:53:27 GMT
References: <6458@sdcsvax.UCSD.Edu] <2550091@hpisod2.HP.COM]
Reply-To: jcbst3@unix.cis.pittsburgh.edu (James C. Benz)
Organization: Univ. of Pittsburgh, Comp & Info Sys
Lines: 35

In article <2550091@hpisod2.HP.COM] decot@hpisod2.HP.COM (Dave Decot) writes:
]] 	int a[MAX];			int a[MAX];
]] 	int i;				int *p;
]] 	for (i=0; i<MAX; ++i)		for (p=&a[0]; p<&a[MAX]; ++p)
]] 		a[i] = 0;			*p=0;
]] 
]] 	...
]] 
]] ... On some compiler/machine combinations, this will run faster,
]] because the scaling operation and base/offset addition have been
]] eliminated; on others it may run slower, because a specific addressing
]] mode cannot be used.
]
]Note that the scaling operation has not necessarily been completely
]eliminated; it may have become hidden in "++p" because increments by 1
]may be much faster than increments by sizeof(*p).
]
Also, the scaling operation has simply been moved to the "for" line, as
far as I can tell.  The machine still has to dereference &a[MAX] on each
iteration of the loop, doesn't it?  It has to perform the test on each
iteration to see if p is < &a[MAX], and unless the optimizer is really
on top of things, it has no way of generating the comparison address
as a constant.  It really has no way of knowing that &a[MAX] won't
change during the course of the program, so it must be re-computed on
each iteration of the loop.  Seems to me that computing &a[MAX] will
take just as long and just as many arithmetic operations as computing
the address of a[i], with the minor difference between using a constant
as index as opposed to a variable.  In any situation I hope to encounter
in the kind of work I do, (database admin) I will trade off the readability
of the first example against the run time efficiency of the second, and 
choose readability every time.
-- 
Jim Benz 		     jcbst3@unix.cis.pittsburgh.edu     If a modem 
University of Pittsburgh					 answers,
UCIR			     (412) 648-5930			 hang up!