X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id E7593329CDD for ; Sat, 18 Sep 2004 16:38:55 +0100 (BST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 48487-09 for ; Sat, 18 Sep 2004 15:38:51 +0000 (GMT) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3]) by svr1.postgresql.org (Postfix) with ESMTP id 9BFDA329C89 for ; Sat, 18 Sep 2004 16:38:46 +0100 (BST) Received: from [127.0.0.2] (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i8IFcbuG027122; Sat, 18 Sep 2004 17:38:38 +0200 Message-ID: <414C567C.3060503@colorfullife.com> Date: Sat, 18 Sep 2004 17:38:36 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Colosimo Cc: Tom Lane , pgsql-hackers@postgresql.org Subject: Re: tweaking MemSet() performance - 7.4.5 References: <8A6E7DA4-0654-11D9-800C-000A95A5D8B2@mitre.org> <24165.1095450900@sss.pgh.pa.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200409/550 X-Sequence-Number: 59116 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 very > low when I profile. Could you check what the OS-X memset function does internally? One trick to speed up memset it to bypass the cache and bulk-write directly from write buffers to main memory. i386 cpus support that and in microbenchmarks it's 3 times faster (or something like that). Unfortunately it's a loss in real-world tests: Typically a structure is initialized with memset and then immediately accessed. 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. > I could squeeze more out of it if I spent more time trying to > understand it (change MEMSET_LOOP_LIMIT to 32 and then add memset > after that?). I'm now working one understanding Spin Locks and > friends. Putting in a sync call (in s_lock.h) is really a time killer > and bad for performance (it takes up 35 cycles). > 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? -- Manfred