Path: utzoo!attcan!lsuc!eci386!clewis
From: clewis@eci386.uucp (Chris Lewis)
Newsgroups: comp.unix.wizards
Subject: Re: fastest way to copy hunks of memory
Message-ID: <1990May2.200732.11851@eci386.uucp>
Date: 2 May 90 20:07:32 GMT
References: <5531@helios.ee.lbl.gov>
Reply-To: clewis@eci386.UUCP (Chris Lewis)
Organization: Elegant Communications Inc., Toronto, Canada
Lines: 60

In article <5531@helios.ee.lbl.gov> tierney@ux1.lbl.gov (Brian Tierney) writes:
 
> Which method is fastest?

It depends.  What kind of processor are you?  How good is your compiler?
Does your vendor program in assembler?  How long is the string?  Are the
operands word aligned?  What's the phase of the moon?  etc.

Perhaps 

    while(size--)
	*p1++ = *p2++;

would be faster.

Yes, library routines are usually slower than in-line code because
of the subroutine call overhead.  But, what if the subroutine is
written in assembler and uses a block move instruction?  Or, the
compiler automatically in-lines small functions?  etc.  Or, the
library routine writer does fancy things in C (eg: "Duff's device")?

There are many fancy short-cuts that can be used even in something as
simple as a block move.

[I'll let someone else describe Duff's device, a topic that comes
up every couple of weeks ;-)]

Generally, it's not really worth bothering about the performance of
simple pieces of code such as block moves and so on.  Use whatever's
easiest to code and support.  Only get fancy when you program is *not*
fast enough and it's spending a significant amount of its time there - 
and you find that out later...

There's nothing worse than finding really obfuscated C code in something, 
where the obfuscation was just to gain a cycle or two out of millions.  
Especially when your compiler's optimizer is so good that it doesn't
matter how "dumb" you code it.

Well, there is one thing worse, puzzle-coded hyper-speed programs that
get the wrong answer.

> In general, system calls are slower, right? (ie, 1 faster that 2 and 3)

Very generally, *function* calls are slower than in-line code.  But chances
are your in-line code would be slower than a vendor's library routine.
You'll never know until you build the program and measure it....
 
> BTW, what's the difference between bcopy and memcpy anyway??

Who wrote it....  memcpy is a Unix System V routine (introduced in SIII
I think), and bcopy is a routine that first appeared as a generally
available function in BSD (it may have been in V7, I disremember), but
since that time, most newer versions of UNIX have both....  (bcopy is 
guaranteed to work even if the source and target overlap, whereas
memcpy isn't.  That's the main difference other than the source and
target operands being backwards)
-- 
Chris Lewis, Elegant Communications Inc, {uunet!attcan,utzoo}!lsuc!eci386!clewis
Ferret mailing list: eci386!ferret-list, psroff mailing list: eci386!psroff-list