incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Liviu Nicoara <nikko...@hates.ms>
Subject Re: STDCXX-1056 [was: Re: STDCXX forks]
Date Sat, 15 Sep 2012 20:53:11 GMT
On 9/15/12 1:51 PM, Stefan Teleman wrote:
> On Sat, Sep 15, 2012 at 9:01 AM, Liviu Nicoara <nikkoara@hates.ms> wrote:
>
>> That is funny. What compiler are you using? What does the following test
>> case return for you?
>
> It's the Intel compiler with the patched stdcxx for  the wrong case
> and GCC 4.7.1 + GNU libstdc++ for  the correct case.
>
> GCC + GNU libstdc++ are correct.
>
> The patched facet does not call the protected do_*() virtual functions
> from their public counterparts, as it is required to do by the
> Standard. Instead, it returns the data mebers directly (the data
> members were initialized in the constructor). That is the patch you
> proposed, which is indeed much better performing than using a mutex
> lock. Unfortunately, in doing so, overriding the virtual functions in
> a derived facet type becomes pointless.

Ahh, I see now. You are indeed right, that patch is defective. I was under the 
impression that we were discussing the (later) attachment 
stdcxx-1056-timings.tgz which contains a perfectly forwarding implementation of 
the facet public grouping method. The timings I attached there were the ones I 
thought we were discussing all along.

Now, to clear the confusion I created: the timing numbers I posted in the 
attachment stdcxx-1056-timings.tgz to STDCXX-1066 (09/11/2012) showed that a 
perfectly forwarding, no caching public interface (exemplified by a changed 
grouping) performs better than the current implementation. It was that test case 
that I hoped you could time, perhaps on SPARC, in both MT and ST builds. The 
t.cpp program is for MT, s.cpp for ST.

Please let me know if this clarifies things. I apologize for the misunderstanding.

Liviu

Mime
View raw message