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"