Return-Path: X-Original-To: apmail-stdcxx-dev-archive@www.apache.org Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 581E5D3C4 for ; Wed, 12 Sep 2012 02:19:23 +0000 (UTC) Received: (qmail 7388 invoked by uid 500); 12 Sep 2012 02:19:23 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 7358 invoked by uid 500); 12 Sep 2012 02:19:23 -0000 Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@stdcxx.apache.org Delivered-To: mailing list dev@stdcxx.apache.org Received: (qmail 7347 invoked by uid 99); 12 Sep 2012 02:19:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Sep 2012 02:19:23 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [64.34.174.152] (HELO hates.ms) (64.34.174.152) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Sep 2012 02:19:16 +0000 Received: from [2.128.155.121] (unknown [206.197.31.227]) by hates.ms (Postfix) with ESMTPSA id 4CEB745C09A for ; Wed, 12 Sep 2012 02:18:55 +0000 (UTC) Message-ID: <504FF10E.8020506@hates.ms> Date: Tue, 11 Sep 2012 22:18:54 -0400 From: Liviu Nicoara User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: dev@stdcxx.apache.org Subject: Re: STDCXX-1056 [was: Re: STDCXX forks] References: <40394653-8FCC-4D04-A108-2C650AF8F95B@hates.ms> <50479CA6.8010306@hates.ms> <50481097.2080307@gmail.com> <50481DDC.6010906@gmail.com> <5048A224.7060402@hates.ms> <5048CC76.5060603@gmail.com> <5049016D.8000902@gmail.com>

<504E2440.1060706@gmail.com> <504FE7F9.90102@gmail.com> In-Reply-To: <504FE7F9.90102@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On 9/11/12 9:40 PM, Martin Sebor wrote: > On 09/11/2012 04:15 PM, Stefan Teleman wrote: >> On Mon, Sep 10, 2012 at 4:24 PM, Stefan Teleman >>> I think I have something which doesn't break BC - stay tuned because >>> I'm testing it now. >> >> OK. >> >> So, here's a possible implementation of __rw_get_numpunct() with >> minimal locking, which passes the MT tests and does not break ABI: >> >> s247136804.onlinehome.us/stdcxx-1056-20120911/punct.cpp >> >> And the same for include/loc/_numpunct.h: >> >> http://s247136804.onlinehome.us/stdcxx-1056-20120911/_numpunct.h >> >> In _numpunct.h, all the functions perform no checks and no lazy >> initialization. They function simply as a pass-through to >> __rw_get_numpunct(). std::numpunct's data members are now dead >> varaiables. >> >> The bad: performance is no better than with locking the mutex inside >> each of the std::numpunct::*() functions, and with lazy >> instantiation. > > I wouldn't expect this to be faster than the original. In fact, > I would expect it to be slower because each call to one of the > public, non-virtual members results in a call to the out-of-line > virtual functions (and another to __rw_get_moneypunct). Avoiding > the overhead of such calls is the main and only reason why the > caching exists. > AFAICT, there are two cases to consider: 1. Using STDCXX locale database initializes the __rw_punct_t data in the first, properly synchronized pass through __rw_get_numpunct. All subsequent calls use the __rw_punct_t data to construct returned objects. 2. Using the C library locales does the same in the first pass, via setlocale and localeconv, but setlocale synchronization is via a per-process lock. The facet data, once initialized is used just like above. I probably missed this in the previous conversation, but did you detect a race condition in the tests if the facets are simply forwarding to the private virtual interface? I.e., did you detect that the facet initialization code is unsafe? I think the facet __rw_punct_t data is safely initialized in both cases, it's the caching that is done incorrectly. > I'm afraid unoptimized timings don't tell us much. Neither does > a comparison between two compilers, even on the same OS. > > I looked at Liviu's timings today. I was puzzled by the difference > between (1) which, IIUC, is the current implementation (presumably > an optimized, thread-safe build with the same compiler and OS) and > (4), which, again IIUC, is the equivalent of your latest patch here > (again, presumably optimized, thread safe, same compiler/OS). I'm > having trouble envisioning how calling a virtual function to > retrieve the value of grouping can possibly be faster than not > calling it (and simply returning the value cached in the data > member of the facet. > The new results I attached to the issue come from a a bit clearer tests and they focus on just two cases: the current implementation vs. a non-caching one; the latter just forwards the grouping calls to the protected do_grouping, with _no_ other changes to the implementation. The timing numbers seem to show that MT builds fare far worse with the caching than without. Stefan, if you have the time, could you please infirm :) my conclusions by timing it on one of your machines? Thanks, Liviu