This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch to gcc/Makefile.in for fastcompare* targets [take 2]


 > From: Phil Edwards <phil@codesourcery.com>
 > 
 > On Sat, Sep 20, 2003 at 01:16:10AM -0400, Kaveh R. Ghazi wrote:
 > > 
 > > I observed that the skeleton of the "compare" shell fragments was
 > > identical among the "slow", "gnu" and my new "fast" variant.  There is
 > > no need to repeat it three times.  I merged them all into one to make
 > > it more maintainable by inserting a case stmt inside the for loops to
 > > fork off the appropriate cmp magic based on $@.
 > 
 > When I added the configure-time switching between the compare methods,
 > I thought about doing a merge along these lines, but wondered about the
 > speed impact of doing a case statement on every file.  Pity the shell
 > can't determine that the result will always be the same, and hoist the
 > case statement out.  :-)
 > 
 > I don't have approval authority for this change, but it looks good to me.

Phil - Thanks for the vote of confidence.

Regarding potential slowdown from the case-stmt, I timed "make
gnucompare" with and without the patch on sparc-solaris2.7 with a fast
local disk builddir.  From a 10-run average, yes I do get a barely
measureable slowdown of 1 tenth of a second out of a total runtime of
~6 seconds, or 1.67%.

Note this particular test will maximize the perceived slowdown as a
percent diff.  If I instead run "make slowcompare" on a local disk (or
any "compare" on an NFS partition) then the absolute slowdown amount
remains the same 0.1 second because these differences don't intereact
with the case-stmt, but the total runtime increases because of the
extra IO traffic.  In these cases, the slowdown is less than 1% as a
percentage.

I can cut the tenth of a second slowdown roughly in half by sinking
the for-stmt into each case clause (there would be six of them.)  But
that uglifies the code.

I came to the conclusion that it wasn't worth it to duplicate the
for-stmt and that the 0.1 second slowdown is okay given the removal of
code duplication between slowcompare, gnucompare and the new
fastcompare targets.

So, ok to install?  Anyone?  Bueller? :-)

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]