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
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 |