Re: tweaking MemSet() performance

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Andrew Sullivan <andrew(at)libertyrms(dot)info>, Neil Conway <neilc(at)samurai(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: tweaking MemSet() performance
Date: 2002-08-30 06:17:44
Message-ID: 27529.1030688264@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-08-30 06:30:53 Re: RULE regression test failure
Previous Message Mario Weilguni 2002-08-30 05:59:40 Re: C vs. C++ contributions