Memory copy timings
Richard Harter
rh at smds.UUCP
Thu Aug 2 18:01:08 AEST 1990
A number of memcpy versus "his macro" results have posted. As far
I can recall all were large block moves (5K - 20K). None of the
postings mentioned checking unaligned moves, i.e. situtations where
the destination and/or source do not lie on even word boundaries.
This is not entirely realistic. If you are going to use a memory
copy routine (and you should) you are going to use it to copy short
blocks as well as long; if you are going to copy character strings
it will often be the case that they are unaligned.
I ran an experiment on four machines a generic 386, a SUN 3/50,
a Mac II/cx running AUX, and a tekronix XD 88/10. On each of the
four machines I copied 100,000,000 bytes. I set up three cases,
(a) aligned character moves, (b) unaligned character moves, and
(c) integer moves. In all cases I used the maximum optimization
available (none of postings mentioned whether they had optimization
turned on.)
In each case I used six different blocks ranging from 10-1000.
(larger block sizes are dominated by the inner loop -- shorter
blocks have sundry overhead costs.) Block sizes for ints were
4 times larger than block sizes for characters (experiment design
flaw.)
The following tables have six lines, one for each block size.
Column 1 is the block size, columns 2 and 3 are the times for
aligned character moves for the macro and memcpy respectively,
columns 4 and 5 are the times for unaligned character moves,
and columns 6 and 7 are the times for integer moves. In each
case the times are the times to move 100,000,000 bytes. Results
and comments follow:
386 Timings -- Esix operating system
10 187 88 188 88 51 31
25 131 40 134 42 39 16
50 121 30 120 30 36 14
100 115 16 117 29 27 10
250 106 13 107 22 27 7
1000 90 9 86 19 26 6
Comments: The 386 has a hardware block move instruction. Hardware
beats software hands down. Clearly one wants to use memcpy, even
for very short copies. Enough said.
SUN 3/50 OS 3.5
10 154 199 154 219 39 62
25 115 93 115 149 29 40
50 105 60 105 127 26 33
100 99 42 99 116 25 29
250 98 38 98 110 24 28
1000 93 28 93 105 23 26
Comments: The SUN memcpy apparently checks for alignment and switches
to word moves when alignment is right; however it doesn't apparently
doesn't use loop unrolling. The macro doesn't check alignment. You
could add code to check alignment, but I don't see a clean, portable
way to do it.
Is it worth using the macro? It's debatable. If you use it for
ints, short char moves, and known unaligned moves you buy 10-40%.
On the other hand using memcpy saves thought and maintenance costs
and it will be superior when and if SUN optimizes the routine.
This is a tradeoff situtation.
MACINTOSH IICX AUX 2.0
10 134 186 130 183 33 127
25 101 137 97 134 25 114
50 92 121 89 117 23 107
100 88 113 84 110 23 107
250 84 109 80 105 21 106
1000 82 106 79 102 20 106
Comments: AUX is a young OS. One suspects that mempcy is two
lines of C. If performance is an issue, you might well consider
rolling your own copy routine.
Tektronix XD88/10 -- Greenhills C-88000 1.8.4
10 44 21 44 37 11 8
25 39 12 39 32 10 5
50 38 8 38 30 10 4
100 38 6 38 28 10 4
250 38 4 38 28 9 4
1000 37 4 37 28 9 4
Comments: Greenhills has a very good reputation; from these
timings it appears warranted. Memcpy is the winner here by
a clear margin. An interesting point here is that optimization
in a compiled language depends in part on helping the compiler
produce efficient code. The arrangement of code gives the
compiler information. The cited macro is basically a CISC
optimization; compilers for RISC machines probably need information
that the macro does not supply.
----
Conclusions: Memcpy is safe, portable (mostly), and doesn't involve
any maintenance issues. On many machines it will be faster than any
thing you can code. It should be; the systems people can do anything that
you can do plus machine-code specific optimizations that you don't
have access to. However it is clear that the quality of the implementation
of system utilities varies a great deal. If performance is an important
issue (or you have a system without memcpy or equivalent) you may want
to write your own. Enough on this topic.
--
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.
More information about the Comp.lang.c
mailing list