From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Andrew Sullivan <andrew(at)libertyrms(dot)info> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: tweaking MemSet() performance |
Date: | 2002-08-29 23:35:13 |
Message-ID: | 200208292335.g7TNZDQ08775@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Sullivan wrote:
> On Thu, Aug 29, 2002 at 01:27:41AM -0400, Neil Conway wrote:
> >
> > Also, if anyone would like to contribute the results of doing the
> > benchmark on their particular system, that might provide some useful
> > additional data points.
>
> Ok, here's a run on a Sun E450, Solaris 7. I presume your "total"
> time label corresponds to my "real" time. That's what I'm including,
> anyway.
Now, these are unusual results. In the 64 case, MemSet is dramatically
slower, and it only starts to win around 512, and seems to speed up
after that.
These are strange results. The idea of MemSet was to prevent the
function call overhead for memset, but in such a case, you would think
the function call overhead would reduce as a percentage of the total
time as the buffer got longer.
In your results it seems to suggest that memset() gets slower for longer
buffer lengths, and a for loop starts to win at longer sizes. Should I
pull out my Solaris kernel source and see what memset() is doing?
---------------------------------------------------------------------------
> System Configuration: Sun Microsystems sun4u Sun Enterprise 450 (2
> X UltraSPARC-II 400MHz)
> System clock frequency: 100 MHz
> Memory size: 2560 Megabytes
>
> BUFFER_SIZE = 64
> MemSet(): 0m13.343s,12.567s,13.659s
> memset(): 0m1.255s,0m1.258s,0m1.254s
>
> BUFFER_SIZE = 128
> MemSet(): 0m21.347s,0m21.200s,0m20.541s
> memset(): 0m18.041s,0m17.963s,0m17.990s
>
> BUFFER_SIZE = 256
> MemSet(): 0m38.023s,0m37.480s,0m37.631s
> memset(): 0m25.969s,0m26.047s,0m26.012s
>
> BUFFER_SIZE = 512
> MemSet(): 1m9.226s,1m9.901s,1m10.148s
> memset(): 2m17.897s,2m18.310s,2m17.984s
>
> BUFFER_SIZE = 1024
> MemSet(): 2m13.690s,2m13.981s,2m13.206s
> memset(): 4m43.195s,4m43.405s,4m43.390s
>
> . . .at which point I gave up.
>
> A
>
> --
> ----
> Andrew Sullivan 204-4141 Yonge Street
> Liberty RMS Toronto, Ontario Canada
> <andrew(at)libertyrms(dot)info> M2P 2A8
> +1 416 646 3304 x110
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-08-29 23:40:11 | Re: SRF memory mgmt patch (was [HACKERS] Concern about memory management with SRFs) |
Previous Message | Joe Conway | 2002-08-29 23:32:55 | Re: SRF memory mgmt patch (was [HACKERS] Concern about memory management |