Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!genrad!decvax!decwrl!sun!wdl1!mas1!jda
From: jda@mas1.UUCP
Newsgroups: comp.arch,comp.lang.c
Subject: Re: Tuning your libraries for your machine
Message-ID: <146@mas1.UUCP>
Date: Mon, 6-Apr-87 16:27:31 EST
Article-I.D.: mas1.146
Posted: Mon Apr  6 16:27:31 1987
Date-Received: Fri, 10-Apr-87 04:00:50 EST
References: <15292@amdcad.UUCP> <978@ames.UUCP> <15694@sun.uucp> <1530@husc6.UUCP> <1537@husc6.UUCP>, <1959@hoptRe: Tuning your libraries foMon, 6-Apr-87 13:27:31 PST
Lines: 47
Xref: utgpu comp.arch:803 comp.lang.c:1502

In article <1959@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes:
> In article <1537@husc6.UUCP>, reiter@endor.harvard.edu (Ehud Reiter) writes:
> > 2) Simple routines like strcpy should be adjusted to perform well on a
> > particular architecture....
> 
> It only becomes reasonable to tailor a system for a particular piece of
> hardware when there are only a small number of variants that run that
> architecture....
> I worked on an APL system for the IBM 360/370 and just finding out the
> timings for the 15 or 20 models that could run the code was too much work,
> let alone figuring out which combination would be best until IBM's next
> release.  (No flames on 15..20, this was in 1973!)

A simple but common logic flaw in my opinion.  Granted that it can require
up to 15 or 20 times the effort to support 15 or 20 models, but the issue is
whether any such model is worth added support.  I can understand a statement
like "I'm not going to optimize for the Lemon III Model B since Lemon Computer
Corporation hasn't even sold one yet."  But John Gilmore seems to be saying:
"IBM was selling thousands of machines a month so the only sensible thing
was to move my product to a company whose market was so small they wouldn't
confuse me with multiple models."

Apologies to John -- the problem is likely to be with budgeting misconceptions
rather than the technical staff.

> 
> It's true that a tailored shared library could give some benefit, but
> the general problem extends to what code to generate inline, not just
> in library routines.

The user doesn't demand a general solution.  He just doesn't like his
application running 20 times slower than necessary.  The plain fact is that
major savings can result from optimizing a few routines (strcpy, ldiv being
good examples).
 
> > 3) Simple routines like strcpy should be recoded in assembler, at least to
> > the degree of having their procedure prologues simplified, and so that they
> > use registers which don't have to be restored.
> 
> These should both be done automatically by a good compiler....

"should be" but not necessarily "is".  There are some *really pathetic*
compilers out there.  From a recent poison remedy pamphlet:
	Induce vomiting.  If necessary show the subject the output
	   of Whitesmiths 68k C compiler.

James D. Allen -- opinions not necessarily necessary.