From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 16:22:03 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DA8FCB25; Mon, 14 Jan 2013 16:22:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id B95D72BB; Mon, 14 Jan 2013 16:22:03 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 177FCB95B; Mon, 14 Jan 2013 11:22:03 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org, toolchain@freebsd.org Subject: Re: Fast sigblock (AKA rtld speedup) Date: Mon, 14 Jan 2013 11:06:07 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <20130107182235.GA65279@kib.kiev.ua> <20130112053147.GH2561@kib.kiev.ua> <20130112162547.GA54954@stack.nl> In-Reply-To: <20130112162547.GA54954@stack.nl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301141106.07976.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 14 Jan 2013 11:22:03 -0500 (EST) Cc: Konstantin Belousov , Jilles Tjoelker X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:22:03 -0000 On Saturday, January 12, 2013 11:25:47 am Jilles Tjoelker wrote: > With that, I think fast sigblock is too much code and complication for a > niche case. It does seem a bit complicated to me as well. > Most of the extra atomics in multi-threaded applications are conditional > on __isthreaded (or can be made so); therefore, performance loss from > linking in libthr should be negligible in most cases. Sadly, this is not true. libstdc++ turns on locking if you merely link against libthr, not based on testing __isthreaded. (It does this by testing to see if pthread_once() works during startup, and we have to intentionally sabotage the pthread_once() in libc to fail for this to work which annoys me for an entirely different set of reasons.) At work we go to great lengths to avoid linking in libthr for exactly this reason (e.g. we have a custom port of boost that builds a separate set of boost libraries that are explicitly not linked against libthr), and we also care about exception performance (one of my co-workers submitted the PR about exception performance). -- John Baldwin