[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/groups?selm....uni-berlin.de

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/groups?selm....uni-berlin.de

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/groups?selm....uni-berlin.de

================ Performance tests : END ==================
==============================================
Alex Vinokur
mailto:al****@connect.to
http://mathforum.org/library/view/10978.html
==============================================

[Alan Balmer]

On Thu, 28 Aug 2003 12:07:58 GMT, pete <pf*****@mindspring.com> wrote:

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.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Mon]

This is about measurement of software, not software for measurement.....
pete <pf*****@mindspring.com> wrote in message
news:3F***********@mindspring.com...

Jack Klein wrote:

On Wed, 27 Aug 2003 18:09:00 +0300, "Alex Vinokur"
<al****@bigfoot.com> wrote in comp.lang.c:

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.

Please don't post stuff like this in comp.lang.c, it's completely
off-topic here.

I thought it was interesting and I don't think that there's
another newsgroup where the speed comparisons of
various standard C library functions on various platforms,
is on topic.
His post was language specific, C.

People are always asking "what's faster", on this newsgroup.
I don't see anything wrong with a practical demonstration that
"Precise answers to these and many similar questions depend
of course on the processor and compiler in use. If you simply
must know, you'll have to time test programs carefully."

http://www.eskimo.com/~scs/C-faq/q20.14.html

--
pete

[Joona I Palaste]

Mon <[e-mail]> scribbled the following
on comp.lang.c:

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 (pa*****@cc.helsinki.fi) ---------------------------\
| 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]

In article <bi************@ID-79865.news.uni-berlin.de>,
al****@bigfoot.com says...

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.

--
Randy Howard _o
2reply remove FOOBAR \<,
______________________()/ ()______________________________________________
SCO Spam-magnet: po********@sco.com

[Mon]

Yes, and you are double-posting to comp.software.measurement...........
Joona I Palaste <pa*****@cc.helsinki.fi> wrote in message
news:bi**********@oravannahka.helsinki.fi...

Mon <[e-mail]> scribbled the following
on comp.lang.c:

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 (pa*****@cc.helsinki.fi) ---------------------------\
| 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

[Alex Vinokur]

"Randy Howard" <ra**********@FOOmegapathdslBAR.net> wrote in message news:MP************************@news.megapathdsl.n et...
[snip]

Reply has been posted to
news:gnu.gcc.help
and
news:comp.software.measurement
=====================================
Alex Vinokur
mailto:al****@connect.to
http://mathforum.org/library/view/10978.html
=====================================