Bruce Momjian wrote:
> MemSet was written when gcc 2.X wasn't even stable yet. Have you run
> any tests on 3.4 to see if MemSet is still a win with that compiler?
I've done a test years ago that showed that memset is usually at least
as good as MemSet:
http://archives.postgresql.org/pgsql-patch
On Sep 29, 2004, at 7:37 AM, Bruce Momjian wrote:
Karel Zak wrote:
On Sat, 2004-09-25 at 23:23 +0200, Manfred Spraul wrote:
[EMAIL PROTECTED] wrote:
If the memset
bypasses the cache then the following access will cause a cache
line
miss, which can be so slow that using the faster memset can result
Neil Conway wrote:
> On Wed, 2004-09-29 at 21:37, Bruce Momjian wrote:
> > The reason MemSet is a win is not that the C code is great but because
> > it eliminates a function call.
>
> A reasonable compiler ought to be able to implement memset() as a
> compiler intrinsic where it makes sense to do
On Wed, 2004-09-29 at 21:37, Bruce Momjian wrote:
> The reason MemSet is a win is not that the C code is great but because
> it eliminates a function call.
A reasonable compiler ought to be able to implement memset() as a
compiler intrinsic where it makes sense to do so. MSVC++ can certainly
do th
Karel Zak wrote:
> On Sat, 2004-09-25 at 23:23 +0200, Manfred Spraul wrote:
> > [EMAIL PROTECTED] wrote:
> >
> > >>If the memset
> > >>bypasses the cache then the following access will cause a cache line
> > >>miss, which can be so slow that using the faster memset can result in a
> > >>net per
On Sat, 2004-09-25 at 23:23 +0200, Manfred Spraul wrote:
> [EMAIL PROTECTED] wrote:
>
> >>If the memset
> >>bypasses the cache then the following access will cause a cache line
> >>miss, which can be so slow that using the faster memset can result in a
> >>net performance loss.
> >>
> >>
>
[EMAIL PROTECTED] wrote:
If the memset
bypasses the cache then the following access will cause a cache line
miss, which can be so slow that using the faster memset can result in a
net performance loss.
Could you suggest some structs to test? If I get your meaning, I would make a loop that
>Marc Colosimo wrote:
>
>> Oops, I used the same setting as in the old hacking message (-O2, gcc
>> 3.3). If I understand what you are saying, then it turns out yes, PG's
>> MemSet is faster for smaller blocksizes (see below, between 32 and
>> 64). I just replaced the whole MemSet with memset an
Manfred Spraul <[EMAIL PROTECTED]> writes:
> That's the price you pay for weakly ordered memory access.
> Linux on ppc uses eieio, on ppc64 lwsync is used. Could you check if
> they are faster?
I recall looking at lwsync and being concerned about portability
problems --- older assemblers will fai
Marc Colosimo wrote:
Oops, I used the same setting as in the old hacking message (-O2, gcc
3.3). If I understand what you are saying, then it turns out yes, PG's
MemSet is faster for smaller blocksizes (see below, between 32 and
64). I just replaced the whole MemSet with memset and it is not ver
On Sep 17, 2004, at 3:55 PM, Tom Lane wrote:
Marc Colosimo <[EMAIL PROTECTED]> writes:
I'm using 7.4.5 on Mac OS X (G5) and was profiling it to see why it is
SO SLOW at committing inserts and deletes into a large database. One
of the many slowdowns was from MemSet. I found an old (2002) thread
abo
Marc Colosimo <[EMAIL PROTECTED]> writes:
> I'm using 7.4.5 on Mac OS X (G5) and was profiling it to see why it is
> SO SLOW at committing inserts and deletes into a large database. One
> of the many slowdowns was from MemSet. I found an old (2002) thread
> about this and retried the tests (se
HI,
I'm using 7.4.5 on Mac OS X (G5) and was profiling it to see why it is
SO SLOW at committing inserts and deletes into a large database. One
of the many slowdowns was from MemSet. I found an old (2002) thread
about this and retried the tests (see below). The main point is that
the system m
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 thi
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.
Linux 2.4.18 (preempt) gcc
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 3
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> 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 bein
On Thu, Aug 29, 2002 at 11:07:03PM -0400, Bruce Momjian wrote:
> and that memset it faster than C MemSet. What compiler are you using?
Sorry. Should have included that.
$gcc --version
2.95.3
> Is the memset() call being inlined by the compiler? You will have to
> look at the assembler code
On Thu, Aug 29, 2002 at 07:35:13PM -0400, Bruce Momjian wrote:
> 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 som
Bruce Momjian <[EMAIL PROTECTED]> 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 (s
us (216-55-132-35.dsl.san-diego.abac.net [216.55.132.35])
by postgresql.org (Postfix) with ESMTP id F2FE34759BD
for <[EMAIL PROTECTED]>; Thu, 29 Aug 2002 15:37:29 -0400 (EDT)
Received: (from pgman@localhost)
by candle.pha.pa.us (8.11.6/8.10.1) id g7TJbQC20180;
Thu, 29 Aug 20
Larry Rosenman wrote:
> On Thu, 2002-08-29 at 18:53, Alvaro Herrera wrote:
> > En Thu, 29 Aug 2002 19:35:13 -0400 (EDT)
> > Bruce Momjian <[EMAIL PROTECTED]> escribi?:
> >
> > > In your results it seems to suggest that memset() gets slower for longer
> > > buffer lengths, and a for loop starts to
Larry Rosenman wrote:
> On Thu, 2002-08-29 at 18:53, Alvaro Herrera wrote:
> > En Thu, 29 Aug 2002 19:35:13 -0400 (EDT)
> > Bruce Momjian <[EMAIL PROTECTED]> escribi?:
> >
> > > In your results it seems to suggest that memset() gets slower for longer
> > > buffer lengths, and a for loop starts to
Alvaro Herrera wrote:
> En Thu, 29 Aug 2002 19:35:13 -0400 (EDT)
> Bruce Momjian <[EMAIL PROTECTED]> escribi?:
>
> > 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
On Thu, 2002-08-29 at 18:53, Alvaro Herrera wrote:
> En Thu, 29 Aug 2002 19:35:13 -0400 (EDT)
> Bruce Momjian <[EMAIL PROTECTED]> escribió:
>
> > 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
>
En Thu, 29 Aug 2002 19:35:13 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> escribió:
> 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 do
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,
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"
t
I consider this a very good test. As you can see from the date of my
last test, 1997/09/11, I think I may have had a dual Pentium Pro at that
point, and hardware has certainly changed since then. I did try 128 at
that time and found it to be slower, but with newer hardware, it is very
possible
In include/c.h, MemSet() is defined to be different than the stock
function memset() only when copying less than or equal to
MEMSET_LOOP_LIMIT bytes (currently 64). The comments above the macro
definition note:
* We got the 64 number by testing this against the stock memset() on
* BSD
30 matches
Mail list logo
