From owner-freebsd-stable@FreeBSD.ORG Tue Apr 13 05:53:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0444106566B for ; Tue, 13 Apr 2010 05:53:18 +0000 (UTC) (envelope-from als@modulus.org) Received: from email.octopus.com.au (email.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id A0ECC8FC15 for ; Tue, 13 Apr 2010 05:53:18 +0000 (UTC) Received: by email.octopus.com.au (Postfix, from userid 1002) id A907C5CB954; Tue, 13 Apr 2010 15:25:18 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: **** X-Spam-Status: No, score=4.4 required=10.0 tests=ALL_TRUSTED, DNS_FROM_OPENWHOIS,FH_DATE_PAST_20XX autolearn=no version=3.2.3 Received: from [10.1.50.144] (ppp121-44-113-76.lns20.syd6.internode.on.net [121.44.113.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 8A5925CB949; Tue, 13 Apr 2010 15:25:14 +1000 (EST) Message-ID: <4BC402B7.5000400@modulus.org> Date: Tue, 13 Apr 2010 15:35:51 +1000 From: Andrew Snow User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Maho NAKATA References: <20100412.131213.4959786962516027.chat95@mac.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 05:53:19 -0000 The statements about the scheduler flipping between cores is also somewhat false, ULE does the right thing now for long-running computational threads. Furthermore, I can't see how a Gflops benchmark which fits in the CPU cache has anything to do with the memory architecture of the operating system. I assume to reach these results the benchmark was multi-threaded, and so I think I'd start by looking at the scheduler. Before that I'd probably look at the libraries, how they were compiled, differences in the compiler etc. - Andrew