Message-ID: <4155E1C1.4030503@colorfullife.com>
Date: Sat, 25 Sep 2004 23:23:13 +0200
From: Manfred Spraul <manfred@colorfullife.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.7.3) Gecko/20040922
MIME-Version: 1.0
To: mcolosimo@smtp-bedford.mitre.org
Cc: Marc Colosimo <mcolosimo@mitre.org>, pgsql-hackers@postgresql.org
Subject: Re: tweaking MemSet() performance - 7.4.5
References: <22741566.1095718812574.JavaMail.ipsadmin@emiisrv>
In-Reply-To: <22741566.1095718812574.JavaMail.ipsadmin@emiisrv>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

mcolosimo@mitre.org 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 sets then reads from the structure. 
>
>  
>
Read the sources and the cpu specs. Benchmarking such problems is 
virtually impossible.
I don't have OS-X, thus I checked the Linux-kernel sources: It seems 
that the power architecture doesn't have the same problem as x86.
There is a special clear cacheline instruction for large memsets and the 
rest is done through carefully optimized store byte/halfword/word/double 
word sequences.

Thus I'd check what happens if you memset not perfectly aligned buffers. 
That's another point where over-optimized functions sometimes break 
down. If there is no slowdown, then I'd replace the postgres function 
with the OS provided function.

I'd add some __builtin_constant_p() optimizations, but I guess Tom won't 
like gcc hacks ;-)
--
    Manfred