Re: tweaking MemSet() performance

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-09-01 23:41:12
Message-ID: 200209012341.g81NfCp01026@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)libertyrms(dot)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(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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Giuseppe R. Papavero 2002-09-02 00:36:40 Possible ODBC Driver Bug (via VC++/MFC CRecordset)
Previous Message Bruce Momjian - CVS 2002-09-01 23:26:06 pgsql-server/ oc/src/sgml/func.sgml oc/src/sgm ...