Re: tweaking MemSet() performance - Mailing list pgsql-hackers

From Tom Lane
Subject Re: tweaking MemSet() performance
Date
Msg-id 27529.1030688264@sss.pgh.pa.us
Whole thread Raw
In response to Re: tweaking MemSet() performance  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: tweaking MemSet() performance  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Would you please retest this.  I have attached my email showing a
> simpler test that is less error-prone.

What did you consider less error-prone, exactly?

Neil's original test considered the case where both the value being
set and the buffer length (second and third args of MemSet) are
compile-time constants.  Your test used a compile-time-constant second
arg and a variable third arg.  It's obvious from looking at the source
of MemSet that this will make a difference in what an optimizing
compiler can do.

I believe that both cases are interesting in practice in the Postgres
sources, but I have no idea about their relative frequency of
occurrence.

FWIW, I get numbers like the following for the constant-third-arg
scenario, using "gcc -O2" with gcc 2.95.3 on HPUX 10.20, HPPA C180
processor:

bufsize        MemSet        memset
64        0m1.71s        0m4.89s
128        0m2.51s        0m5.36s
256        0m4.11s        0m7.02s
512        0m7.32s        0m10.31s
1024        0m13.74s    0m16.90s
2048        0m26.58s    0m30.08s
4096        0m52.24s    0m56.43s

So I'd go for a crossover point of *at least* 512.  IIRC, I got
similar numbers two years ago that led me to put the comment into
c.h that Neil is reacting to...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Mario Weilguni
Date:
Subject: Re: C vs. C++ contributions
Next
From: Tom Lane
Date:
Subject: Re: RULE regression test failure