Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!nosc!ucsd!rutgers!phri!roy
From: roy@phri.UUCP (Roy Smith)
Newsgroups: comp.arch
Subject: Re: RISC bashing at USENIX
Message-ID: <3384@phri.UUCP>
Date: 15 Jul 88 12:53:50 GMT
References: <59798@sun.uucp> <204@baka.stan.UUCP> <603@bacchus.DEC.COM>
Reply-To: roy@phri.UUCP (Roy Smith)
Distribution: na
Organization: Public Health Research Inst. (NY, NY)
Lines: 31

alverson@decwrl.UUCP (Robert Alverson) writes:
> I tend to agree that you should use a library routine to perform such a
> low-level function as copying memory. [...] copying memory seems like
> such a fundamentally useful operation that you can expect the library
> code to be at least as good as what you can get out of the compiler.

	On the other hand, library routines can't make assumptions about
their arguments.  Bcopy(3) can handle copies of arbitrary length with
arbitrary alignment, and thus must perform assorted checks to see if it has
to copy the first few and/or last bytes "by hand".  For short blocks, the
overhead of these extra checks might be important enough that coding your own
block-copy code might be a big win if you know you're only going to be
copying blocks with "nice" alignments and lengths.

	On the other hand, every line of code you write yourself is just
another bug waiting to happen (not to mention a waste of programing time).
If you call a library routine you can be reasonably sure it works right.  For
example, of all the times I've been convinced that malloc(3) and/or free(3)
was screwing up, never once have I not been able to (eventually) trace the
fault to my own code.

	Moral: use library routines, but before you release the code do some
serious profiling on it.  As long as you don't spend much time in library
code, don't worry about possible inefficiencies therein.  If you do find
you're calling a routine with some special-case arguments and where the
generality of the library routine is slowing you down, then go ahead and
write your own replacement, but make sure it works as well as the original!
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"