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

From Bruce Momjian
Subject Re: tweaking MemSet() performance
Date
Msg-id 200209012341.g81NfCp01026@candle.pha.pa.us
Whole thread Raw
In response to Re: tweaking MemSet() performance  (Andrew Sullivan <andrew@libertyrms.info>)
List pgsql-hackers
OK, seems we have wildly different values for MemSet for different
machines.  I am going to up the MEMSET_LOOP_LIMIT value to 1024 because
it seems to be the best value on most machines.  We can revisit this in
7.4.

I wonder if a configure test is going to be required for this
evenutally.  I think random page size needs the same handling.

Maybe I should add to TODO:
 o compute optimal MEMSET_LOOP_LIMIT value via configure.

Is there a significant benefit?  Can someone run some query with MemSet
vs. memset and see a timing difference?  You can use the new GUC param
log_duration I just committed.

Remember, I added MemSet to eliminate the function call overhead, but at
this point, we are now seeing that MemSet beats memset() for ordinary
memory setting, and function call overhead isn't even an issue with the
larger buffer sizes.

---------------------------------------------------------------------------

Andrew Sullivan wrote:
> On Thu, Aug 29, 2002 at 11:07:03PM -0400, Bruce Momjian wrote:
> > 
> > Would you please retest this.  I have attached my email showing a
> > simpler test that is less error-prone.
> 
> Ok, here you go.  Same machine as before, 2-way UltraSPARC-II @400
> MHz, 2.5 G, gcc 2.95.3, Solaris 7.  This gcc compiles 32 bit apps.  
> 
> MemSet():
> 
> *64
> 
> real    0m1.298s
> user    0m1.290s
> sys    0m0.010s
> *128
> 
> real    0m2.251s
> user    0m2.250s
> sys    0m0.000s
> *256
> 
> real    0m3.734s
> user    0m3.720s
> sys    0m0.010s
> *512
> 
> real    0m7.041s
> user    0m7.010s
> sys    0m0.020s
> *1024
> 
> real    0m13.353s
> user    0m13.350s
> sys    0m0.000s
> *2048
> 
> real    0m26.178s
> user    0m26.040s
> sys    0m0.000s
> *4096
> 
> real    0m51.838s
> user    0m51.670s
> sys    0m0.010s
> 
> and memset()
> 
> *64
> 
> real    0m1.469s
> user    0m1.460s
> sys    0m0.000s
> *128
> 
> real    0m1.813s
> user    0m1.810s
> sys    0m0.000s
> *256
> 
> real    0m2.747s
> user    0m2.730s
> sys    0m0.010s
> *512
> 
> real    0m12.478s
> user    0m12.370s
> sys    0m0.010s
> *1024
> 
> real    0m26.128s
> user    0m26.010s
> sys    0m0.000s
> *2048
> 
> real    0m57.663s
> user    0m57.320s
> sys    0m0.010s
> *4096
> 
> real    1m53.772s
> user    1m53.290s
> sys    0m0.000s
> 
> A
> 
> -- 
> ----
> Andrew Sullivan                         204-4141 Yonge Street
> Liberty RMS                           Toronto, Ontario Canada
> <andrew@libertyrms.info>                              M2P 2A8
>                                          +1 416 646 3304 x110
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Impending freeze
Next
From: "Giuseppe R. Papavero"
Date:
Subject: Possible ODBC Driver Bug (via VC++/MFC CRecordset)