[Comparative performance] str-functions vs. mem-functions

[Alex Vinokur]

Here are results of comparative performance tests carried out
using the same compiler (gcc 3.2)
in different environments (CYGWIN, MINGW, DJGPP)
on Windows 2000 Professional.


The following C-functions were tested :
* strcpy
* memcpy
* memmove
* memset

The summary results are below.


#################################################################

str-functions vs. mem-functions (C-language)
============================================

C/C++ Performance Tests
=======================
Using C/C++ Program Perfometer
http://sourceforge.net/projects/cpp-perfometer
http://alexvn.freeservers.com/s1/perfometer.html



Environment
-----------
Windows 2000 Professional
* CYGWIN_NT-5.0 1.3.22(0.78/3/2)
* MINGW 2.0.0.-2
* DJGPP 2.03
Intel(R) Celeron(R) CPU 1.70 GHz
GNU g++/gpp 3.2
Compilation : No optimization



================ Performance tests : BEGIN ================



#==========================================================
# Comparison : str-functions vs. mem-functions (C)
#----------------------------------------------------------
# Resource Name : user time used (via rusage)
# Resource Cost Unit : milliseconds (unsigned long long)
# Resource State Unit : timeval
#==========================================================



Summary test results
CYGWIN_NT-5.0 1.3.22(0.78/3/2)
gcc/g++ version 3.2 20020927 (prerelease)
============================
----------------------------------------
| | | User time used for |
| N | Function | string size |
| | |-----------------------|
| | | 10 | 100 | 1000 |
|--------------------------------------|
| 1 | strcpy | 46 | 165 | 1088 |
| 2 | memcpy | 166 | 223 | 1069 |
| 3 | memmove | 215 | 274 | 1124 |
| 4 | memset | 133 | 213 | 540 |
----------------------------------------
Note C1. memcpy is slower than strcpy
for relatively short strings
Note C2. memmove is slower than memcpy
Raw Log : http://groups.google.com/[email protected]



Summary test results
MINGW 2.0.0-2
gcc/g++ version 3.2 (mingw special 20020817-1)
============================
----------------------------------------
| | | User time used for |
| N | Function | string size |
| | |-----------------------|
| | | 10 | 100 | 1000 |
|--------------------------------------|
| 1 | strcpy | 50 | 250 | 1982 |
| 2 | memcpy | 51 | 180 | 1150 |
| 3 | memmove | 50 | 180 | 1161 |
| 4 | memset | 110 | 160 | 607 |
----------------------------------------
Note M1. Actually memcpy is faster than strcpy
Note M2. memmove & memcpy have the same performance
Raw Log : http://groups.google.com/[email protected]



Summary test results
DJGPP 2.03
gcc/gpp version 3.2.1
============================
----------------------------------------
| | | User time used for |
| N | Function | string size |
| | |-----------------------|
| | | 10 | 100 | 1000 |
|--------------------------------------|
| 1 | strcpy | 63 | 567 | 5329 |
| 2 | memcpy | 173 | 329 | 1492 |
| 3 | memmove | 274 | 384 | 1098 |
| 4 | memset | 191 | 292 | 695 |
----------------------------------------
Note D1. For very short strings
memcpy is slower than strcpy,
for other strings
memcpy is faster than strcpy,
Note D2. strcpy seems to work too slow
(relative to CYGWIN, MINGW)
Raw Log : http://groups.google.com/[email protected]



================ Performance tests : END ==================


==============================================
Alex Vinokur
mailto:[email protected]
http://mathforum.org/library/view/10978.html
==============================================

 

[Alan Balmer]

People are always asking "what's faster", on this newsgroup.

And people are always being told that such questions are both
off-topic and meaningless to standard C.

 

[Mon]

This is about measurement of software, not software for measurement.....

 

[Joona I Palaste]

Mon <[email protected]> scribbled the following

This is about measurement of software, not software for measurement.....

Yes, and? Strictly speaking, software is off-topic on comp.lang.c.
That is, software whose source code (written in C) is not being
discussed.

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"I am not very happy acting pleased whenever prominent scientists overmagnify
intellectual enlightenment."
- Anon

 

[Randy Howard]

The following C-functions were tested :
* strcpy
* memcpy
* memmove
* memset
# Resource Name : user time used (via rusage)

Note that "user time" may not be an appropriate way to measure such
things. "Wall clock time" (on an unloaded system of course) is a
far more appropriate method. Not to mention that rusage info is
not portable.

I also noticed that you posted this to c.l.c, yet the source in
the measurement package you referenced is C++. This effectively
renders the results of little or no value for c.l.c readers
interesting in Standard C library performance using the C language
on compilers being used as C compilers, not C++ compilers.

| | | User time used for |
| N | Function | string size |
| | |-----------------------|
| | | 10 | 100 | 1000 |

If this is meant to be useful, the values used should include
larger sizes. Modern systems move strings (some) and memory (often)
of much larger block lengths. Additionally, you don't state whether
or not these values are from a single run or multiple runs.

If from multiple runs, are they the value from the best pass, worst
pass, average of the passes, etc.? Also, if multiple runs, are the
source and destination addresses the same for each iteration? If so,
cache warming could be artificially skewing the results as well.

I didn't dig into the C++ code to see the details as they pertain to
the above.

 

[Mon]

Yes, and you are double-posting to comp.software.measurement...........

 

[Alex Vinokur]

[snip]

Reply has been posted to
and


=====================================
Alex Vinokur
mailto:[email protected]
http://mathforum.org/library/view/10978.html
=====================================