From owner-freebsd-questions@FreeBSD.ORG Tue Apr 25 13:25:28 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86DAA16A409 for ; Tue, 25 Apr 2006 13:25:28 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD09443D46 for ; Tue, 25 Apr 2006 13:25:26 +0000 (GMT) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61]) by wingspan with esmtp; Tue, 25 Apr 2006 09:25:26 -0400 id 00056414.444E2346.0000921B Date: Tue, 25 Apr 2006 09:25:26 -0400 From: Bill Moran To: Derek Ragona Message-Id: <20060425092526.6fe5efa6.wmoran@collaborativefusion.com> In-Reply-To: <6.0.0.22.2.20060425075227.028aea10@mail.computinginnovations.com> References: <20060424154617.9dc28c94.wmoran@potentialtech.com> <6.0.0.22.2.20060424175443.02927f48@mail.computinginnovations.com> <20060425084752.2453c0f1.wmoran@collaborativefusion.com> <6.0.0.22.2.20060425075227.028aea10@mail.computinginnovations.com> Organization: Collaborative Fusion X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.8.12; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org Subject: Re: Purchasing the correct hardware: dual-core intel? Big cache? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 13:25:28 -0000 On Tue, 25 Apr 2006 07:56:03 -0500 Derek Ragona wrote: > Yes, dual core is on average 20% faster than hyperthreaded CPU's. But that > is general benchmark. The range of performance difference is 10% - 30% > depending on the application mix. Thanks. > If you use well optimized applications, you see the larger performance > gain. Poor optimization causes a CPU to chug along, flushing the CPU cache > often, and slowing things down considerably. I know. That's why I'm so desperately trying to find a way to determine how often the cache is being invalidated - so I can determine whether larger cache sizes (such as 8M) are worthwhile. The database server is PostgreSQL. If we find optimization problems with it, we'll definitely work with the PostgreSQL folks to get those problems addressed, but I'm not expecting a lot of poorly-written code in something as mature as PostgreSQL. So, making a (reasonable) assumption that PostgreSQL is well-optimized, I need a way to tell if adding another 6M of cache will improve performance, _before_ we pay for it. That's my question. -- Bill Moran Collaborative Fusion Inc. **************************************************************** IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ****************************************************************