On 9/16/12 3:20 AM, Stefan Teleman wrote:
> On Sat, Sep 15, 2012 at 4:53 PM, Liviu Nicoara wrote:
>
>> 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 publ
On 9/16/12 11:21 AM, Liviu Nicoara wrote:
On 9/16/12 3:20 AM, Stefan Teleman wrote:
On Sat, Sep 15, 2012 at 4:53 PM, Liviu Nicoara wrote:
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
perf
On Sun, Sep 16, 2012 at 11:21 AM, Liviu Nicoara wrote:
> Thanks, Stefan. I looked over it and it seems very similar to, and somewhat
> more detailed than gprof profiling output.
In the experiment with our (Solaris) patch, there is total of 992 race
conditions for the duration of the program:
17
On Sat, Sep 15, 2012 at 5:47 PM, Liviu Nicoara wrote:
> I merely wanted to point out that restoring the default packing is not the
> same as restoring the packing to the previous value in effect.
>
> Given this, I thought about an alternative way of forcing this alignment,
> e.g., via a union, al
On 9/16/12 3:20 AM, Stefan Teleman wrote:
On Sat, Sep 15, 2012 at 4:53 PM, Liviu Nicoara wrote:
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 interfa
On Sat, Sep 15, 2012 at 4:53 PM, Liviu Nicoara wrote:
> 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
