Memory copy timings

Richard A. O'Keefe ok at goanna.cs.rmit.oz.au
Sat Aug 4 18:12:42 AEST 1990


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.

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.

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.  Which is why
MVS and VMS offer "locate" mode transput as well as "move" mode, a
distinction reflected at the PL/I language level.  This is also the
point of <fio.h>, anyone have a PD implementation of fio?

-- 
Distinguishing between a work written in Hebrew and one written in Aramaic
when we have only a Latin version made from a Greek translation is not easy.
(D.J.Harrington, discussing pseudo-Philo)



More information about the Comp.lang.c mailing list