From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 14 16:50:12 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 46527811; Mon, 14 Jan 2013 16:50:12 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 331EA648; Mon, 14 Jan 2013 16:50:12 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (unknown [64.25.27.130]) by elvis.mu.org (Postfix) with ESMTPSA id 6692E1A3CDA; Mon, 14 Jan 2013 08:50:06 -0800 (PST) Message-ID: <50F4373B.5080203@mu.org> Date: Mon, 14 Jan 2013 11:50:03 -0500 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: Fast sigblock (AKA rtld speedup) References: <20130107182235.GA65279@kib.kiev.ua> <20130112053147.GH2561@kib.kiev.ua> <20130112162547.GA54954@stack.nl> <201301141106.07976.jhb@freebsd.org> In-Reply-To: <201301141106.07976.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: toolchain@freebsd.org, Jilles Tjoelker , freebsd-arch@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:50:12 -0000 On 1/14/13 11:06 AM, John Baldwin wrote: > 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). > I get frustrated when people ask me "but why are you doing that?", but I have to know... why do we/you need fast exception handling? Are you throwing a high rate of exceptions? Or is it just that your application is that sensitive to exceptions being thrown that a single slowish one has an impact? -Alfred