Memory copy timings

[Richard Harter]

In article <3510 at goanna.cs.rmit.oz.au>, ok at goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> In article <144 at smds.UUCP>, rh at smds.UUCP (Richard Harter) writes:
> > A number of memcpy versus "his macro" results have posted.  ...
> > None of the postings mentioned checking unaligned moves, ...
> > This is not entirely realistic.

> I don't see why.  Whatever method you are using for doing bulk
> moves (BLT instruction, TRT instruction, bcopy(), memcyp(),
> memmove(), ...) having things aligned is likely to help.  Any
> programmer who cares enough about the performance of block transfer
> to be wondering whether memcpy() is fast enough should really have
> taken care of alignment first.

Agreed -- alignment helps and anyone concerned about performance should
worry about alignment.  The point is that if one is copying a block of
characters as such, e.g. strings, one quite regularly hits unaligned
moves.  An example would be copying a substring out of an array (or into
an array).

> This also applies to fread(), fwrite(), and (on systems with a POSIX
> interface, such as DEC are promising RSN for VMS) read() and write().
> On all the UNIX systems where I've tried the comparison, I've found
> that making read/write buffers be "well" aligned (the alignment that
> malloc() guarantees is fine) was usefully faster than having them be
> misaligned.

That is almost guaranteed to be the case.  If I am not mistaken almost
all systems read fixed block sizes into internal buffers and copy
the results from the buffers to your specified destination.  (Waiting
to be told that I am wrong. :-))  There is a rumour to the effect that
your I/O will be faster if you read and write in fixed block sizes that
are integral multiples of the system block size.  Does anyone have 
opinions or information on the trade offs involved?  For example is there
a performance gain one way or another by doing one read into a buffer of
1024 bytes and then copying out a series of items versus doing a series
of reads for each item?  Does anyone have any data on this?  Does anyone
care? :-)

> Most of the time, the best way to speed up block transfer is not to
> do it at all, but to twiddle your pointers around...

Yep, no argument here.  There are cases where that doesn't apply, e.g.
the data you want is in a transient area, you're changing object size,
you're going to modify the copied data later on, etc.  Another area where
there are large potential gains is the allocation and deallocation of objects
of the same type.  One often wins big by maintaining a free list of objects.
And so on...
-- 
Richard Harter, Software Maintenance and Development Systems, Inc.
Net address: jjmhome!smds!rh Phone: 508-369-7398 
US Mail: SMDS Inc., PO Box 555, Concord MA 01742
This sentence no verb.  This sentence short.  This signature done.