From owner-svn-src-all@FreeBSD.ORG Fri Jan 20 11:42:03 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07101106564A; Fri, 20 Jan 2012 11:42:03 +0000 (UTC) (envelope-from theraven@theravensnest.org) Received: from theravensnest.org (theravensnest.org [109.169.23.128]) by mx1.freebsd.org (Postfix) with ESMTP id 9283E8FC08; Fri, 20 Jan 2012 11:42:02 +0000 (UTC) Received: from [192.168.0.2] (cpc1-cwma8-2-0-cust257.7-3.cable.virginmedia.com [82.20.153.2]) (authenticated bits=0) by theravensnest.org (8.14.4/8.14.4) with ESMTP id q0KBEoLh011123 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 20 Jan 2012 11:16:02 GMT (envelope-from theraven@theravensnest.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: David Chisnall In-Reply-To: <4F18B951.6080404@gmail.com> Date: Fri, 20 Jan 2012 11:14:45 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201201160615.q0G6FE9r019542@svn.freebsd.org> <4F178CDC.3030807@gmail.com> <4F17B0DE.3060008@gmail.com> <201201191023.28426.jhb@freebsd.org> <20120120030456.O1411@besplex.bde.org> <4F18B951.6080404@gmail.com> To: davidxu@FreeBSD.org X-Mailer: Apple Mail (2.1251.1) Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, John Baldwin , Bruce Evans Subject: Re: svn commit: r230201 - head/lib/libc/gen X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 11:42:03 -0000 On 20 Jan 2012, at 00:46, David Xu wrote: > It depends on hardware, if it is a large machine with lots of cpu, > a small conflict on dual-core machine can become a large conflict > on large machine because it is possible more cpus are now > running same code which becomes a bottleneck. On a large machine > which has 1024 cores, many code need to be redesigned. You'll also find that the relative cost of atomic instructions varies a = lot between CPU models. Between Core 2 and Sandy Bridge Core i7, the = relative cost of an atomic add (full barrier) dropped by about two = thirds. The cache coherency logic has been significantly improved on = the newer chips. =20 For portable code, it's worth remembering that ARMv8 (which doesn't = entirely exist yet) contains a set of barriers that closely match the = semantics of the C[++]11 memory ordering. They do this not for = performance (directly), but for power efficiency - so using the = least-restrictive required locking will eventually result in code for = mobile devices that uses less battery power, if it's in a hot path. =20 David=