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 8A360329E8B for ; Mon, 20 Sep 2004 23:20:23 +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 38633-08 for ; Mon, 20 Sep 2004 22:20:15 +0000 (GMT) Received: from smtp-bedford.mitre.org (smtpproxy1.mitre.org [192.160.51.76]) by svr1.postgresql.org (Postfix) with ESMTP id 7C236329EA6 for ; Mon, 20 Sep 2004 23:20:16 +0100 (BST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with SMTP id i8KMKG120604 for ; Mon, 20 Sep 2004 18:20:16 -0400 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 731BCBF7D for ; Mon, 20 Sep 2004 18:20:16 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with ESMTP id i8KMKFj20499; Mon, 20 Sep 2004 18:20:15 -0400 Received: from emiisrv.mitre.org (129.83.12.253) by mailhub2.mitre.org with SMTP id 4777813; Mon, 20 Sep 2004 18:20:11 -0400 Message-ID: <22741566.1095718812574.JavaMail.ipsadmin@emiisrv> Date: Mon, 20 Sep 2004 18:20:12 -0400 (EDT) From: mcolosimo@mitre.org Reply-To: mcolosimo@smtp-bedford.mitre.org To: Manfred Spraul , Marc Colosimo Subject: Re: tweaking MemSet() performance - 7.4.5 Cc: Tom Lane , pgsql-hackers@postgresql.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: NetMail Lite X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.3 tagged_above=0.0 required=5.0 tests=NO_REAL_NAME X-Spam-Level: X-Archive-Number: 200409/753 X-Sequence-Number: 59319 >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. > Could you suggest some structs to test? If I get your meaning, I would make a loop that sets then reads from the structure. >> 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? > I found the reason why "sync" was put in , but it is odd why it works. Why syncing one processor prevents the other from doing something is interesting. What type of shared memory is being used on OS X? I'm confused about the two types of semaphores, sysV or POSIX. It seems the POSIX is the way to go on OS X. Marc