Re: c / c++ : is it end of era ?

Andrew Sidwell a écrit :
jacob navia wrote:
<snip>

In any case it proves my point
strchr is slower by more than 30 % compared to memchr under libc/linux


dougal(~/navia) cat chr.c
#include <stdio.h>
#include <string.h>
#define MAXITER 100000000

int main(void)
{
char s[4096];
int i;

memset(&s, 'a', sizeof(s) - 1);
s[sizeof(s)-1] = 0;

for (i = 0; i < MAXITER; i++)
{
#ifdef MEMCHR
memchr(s, '1', sizeof s)
#else
strchr(s, '1')
#endif
}

return 0;
}
dougal(~/navia) gcc -O0 chr.c -o strchr
dougal(~/navia) time ./strchr
real 0m1.403s
user 0m0.990s
sys 0m0.040s
dougal(~/navia) time ./strchr
real 0m1.743s
user 0m1.000s
sys 0m0.050s
dougal(~/navia) time ./strchr
real 0m1.212s
user 0m1.000s
sys 0m0.050s

dougal(~/navia) gcc -O0 chr.c -DMEMCHR -o memchr
dougal(~/navia) time ./memchr
real 0m1.874s
user 0m1.010s
sys 0m0.020s
dougal(~/navia) time ./memchr
real 0m1.485s
user 0m1.030s
sys 0m0.030s
dougal(~/navia) time ./memchr
real 0m1.282s
user 0m0.990s
sys 0m0.020s

I can see no clear pattern in the performance of the two functions, and
believe that your claim is unsubstantiated.

/proc/cpuinfo says that the processor this was run on was a 735Hz VIA
Ezra (x86) processor, with the flags "fpu de tsc msr cx8 mtrr pge mmx
3dnow", and a 64KB cache.


Andrew Sidwell

Obviously there is something wrong since in a MUCH faster machine
for 100 million iterations I take 84/43 SECONDS and you take not even
a second...

I explicitely said that you should NOT set any optimizations, and you
compiled with O0. O0 DOES some optimizations, so this is quite dangerous
with benchmarks. I would suggest that you use this program without any
optimizations at all:

#include <stdio.h>
#include <time.h>
#include <string.h>
#define MAXITER 10000000
int main(void){
char s[4096];
int i,c=0;
time_t t,tStrchr,tMemchr;

for (i=0; i<sizeof(s)-1;i++) {
s[i] = 'a';
}
s[sizeof(s)-1] = 0;
t = time(NULL);
for (i=0; i<MAXITER;i++) {
if(strchr(s,'1'))
c++;;
}
tStrchr= time(NULL) - t;
printf("Time for strchr=%d\n",tStrchr);
t = time(NULL);
for (i=0; i<MAXITER;i++) {
if(memchr(s,'1',sizeof(s)))
c++;
}
tMemchr=time(NULL)-t;
printf("Time for memchr=%d\n",tMemchr);
return c;
}

The additions to the variable "c" disable any optimization
of the calls away. Besides, main returns that value
and this means that gcc must generate the code as told.

It is very disappointing that compilers optimize when told
not to!!!

jacob


.

Relevant Pages

  • Re: DEFAULT CFLAGS SETTING
    ... Unlike some linux distributions where using CFLAGS and CXXFLAGS are encouraged, it's discouraged here because it generates a lot more variation in having to check through errors, and many times the levels of optimization used my system users is counterproductive to the purpose of optimizing. ... int f{ ... an alias set for the node. ... since the version of gcc the base system works with isn't bleeding edge it won't support all processor types / optimizations available in later versions of gcc. ...
    (freebsd-questions)
  • Re: c / c++ : is it end of era ?
    ... #define MAXITER 10000000 ... int main ... tStrchr= time- t; ... gcc 3.3.6 ...
    (comp.lang.c)
  • Re: fopen v. open and more
    ... operations enabling construction of locking primitives' in a general ... There's a reason why 'locking overhead' is considered to be a bad ... int main { ... sys 0m0.047s ...
    (comp.unix.programmer)
  • [PATCH 10/14] score - New architecure port to SunplusCT S+CORE
    ... * Score Processor version. ... * GNU General Public License for more details. ... int err = 0; ... sys sys_execve_wrapper 0 ...
    (Linux-Kernel)
  • Re: [PATCH 10/13] score - New architecure port to SunplusCT S+CORE processor
    ... * Score Processor version. ... * GNU General Public License for more details. ... int err = 0; ... sys sys_execve_wrapper 0 ...
    (Linux-Kernel)