Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #70555 > unrolled thread

What cache-archtectures ...

Back to article view | Back to comp.lang.c++

Contents

  What cache-archtectures ... Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-18 16:07 +0100
    Re: What cache-archtectures ... Vir Campestris <vir.campestris@invalid.invalid> - 2019-12-20 21:20 +0000
      Re: What cache-archtectures ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-20 14:04 -0800
        Re: What cache-archtectures ... Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-21 08:18 +0100
          Re: What cache-archtectures ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-22 17:24 -0800
            Re: What cache-archtectures ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-22 17:35 -0800
            Re: What cache-archtectures ... Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-24 13:18 +0100
              Re: What cache-archtectures ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-24 13:39 -0800
              Re: What cache-archtectures ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-24 13:41 -0800
                Re: What cache-archtectures ... Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-25 02:30 +0100
                  Re: What cache-archtectures ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-27 23:52 -0800
                    Re: What cache-archtectures ... Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-28 08:54 +0100
                      Re: What cache-archtectures ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-27 23:57 -0800
                        Re: What cache-archtectures ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-27 23:59 -0800
                          Re: What cache-archtectures ... Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-28 09:53 +0100
                            Re: What cache-archtectures ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-28 15:56 -0800

#70555 — What cache-archtectures ...

... could make std::hardware_destructive_interference_size
and std::hardware_constructive_interference_size different?

[toc] | [next] | [standalone]

#70594

On 18/12/2019 15:07, Bonita Montero wrote:
> .... could make std::hardware_destructive_interference_size
> and std::hardware_constructive_interference_size different?

Multi-level caches perhaps?

Andy

[toc] | [prev] | [next] | [standalone]

#70595

On 12/20/2019 1:20 PM, Vir Campestris wrote:
> On 18/12/2019 15:07, Bonita Montero wrote:
>> .... could make std::hardware_destructive_interference_size
>> and std::hardware_constructive_interference_size different?
> 
> Multi-level caches perhaps?
> 

Yeah. Was thinking that std::hardware_destructive_interference_size can 
be L1, and std::hardware_constructive_interference_size different can be 
L2. However, this is completely up to the implementation.

Iirc, back on early hyperthreading 128-byte would be split into two 
64-byte halves. Iirc, two adjacent 64-bit cache lines can interfere.

https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf

They recommend to pad and align things on 128-byte boundaries. The two 
64-byte halves can contend. Section 3.7.3, Hardware Prefetching for 
Second-Level Cache.

[toc] | [prev] | [next] | [standalone]

#70596

> Yeah. Was thinking that std::hardware_destructive_interference_size can 
> be L1, and std::hardware_constructive_interference_size different can be 
> L2. However, this is completely up to the implementation.

If L2 has a larger cacheline-size than L1 and L2 is shared,
then both values should be at least >= the L2 cacheline-size.

> Iirc, back on early hyperthreading 128-byte would be split into two 
> 64-byte halves. Iirc, two adjacent 64-bit cache lines can interfere.
> https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf 
> They recommend to pad and align things on 128-byte boundaries. The two 
> 64-byte halves can contend. Section 3.7.3, Hardware Prefetching for 
> Second-Level Cache.


There were multicore NetBurst-CPUs, not even NetBurst-based Xeons.
So there wasn't any opportunity for false sharing.

[toc] | [prev] | [next] | [standalone]

#70615

On 12/20/2019 11:18 PM, Bonita Montero wrote:
>> Yeah. Was thinking that std::hardware_destructive_interference_size 
>> can be L1, and std::hardware_constructive_interference_size different 
>> can be L2. However, this is completely up to the implementation.
> 
> If L2 has a larger cacheline-size than L1 and L2 is shared,
> then both values should be at least >= the L2 cacheline-size.
> 
>> Iirc, back on early hyperthreading 128-byte would be split into two 
>> 64-byte halves. Iirc, two adjacent 64-bit cache lines can interfere.
>> https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf 
>> They recommend to pad and align things on 128-byte boundaries. The two 
>> 64-byte halves can contend. Section 3.7.3, Hardware Prefetching for 
>> Second-Level Cache.
> 
> 
> There were multicore NetBurst-CPUs, not even NetBurst-based Xeons.
> So there wasn't any opportunity for false sharing.
>
Iirc, back when hyperthreading first came out, there was/is still an 
issue, with two concurrent threads heavily working on their respective 
contiguous 64-byte structures. They can interfere with one another wrt 
using lock'ed rmw. Therefore, its is recommended to align _and_ pad 
things on a 128-byte boundary. Something like the following structures, 
just some pseudo-code:
_____________________
struct cache_buf
{
     char buf[128];
};

struct cache_half
{
     char buf[64];
};

struct cache_line
{
     cache_half low;
     cache_half high;
};

union cache_line_buf
{
     cache_line line;
     cache_buf buf;
};
_____________________

a cache_line_buf needs to be aligned in memory on a sizeof(cache_buf) 
boundary. Its already padded.

[toc] | [prev] | [next] | [standalone]

#70616

On 12/22/2019 5:24 PM, Chris M. Thomasson wrote:
> On 12/20/2019 11:18 PM, Bonita Montero wrote:
[...]

> Something like the following structures, 
> just some pseudo-code:
> _____________________
> struct cache_buf
> {
>      char buf[128];
> };
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Ummm... Damn it! Heck, this should at least be unsigned char. Or, 
uint8_t. Sorry Bonita. ;^o

[toc] | [prev] | [next] | [standalone]

#70631

> Iirc, back when hyperthreading first came out, there was/is still an 
> issue, with two concurrent threads heavily working on their respective 
> contiguous 64-byte structures. They can interfere with one another wrt 
> using lock'ed rmw. Therefore, its is recommended to align _and_ pad 
> things on a 128-byte boundary. ...

Not true. The L1-cache of NetBurst-CPUs had 64 byte lines and the
L2-cache 128 byte lines with partitial invalidation of the lower
or upper half through the L1-cache.
What you say might have been true for Net-Burst based dual-socket
Xeons.

[toc] | [prev] | [next] | [standalone]

#70632

On 12/24/2019 4:18 AM, Bonita Montero wrote:
>> Iirc, back when hyperthreading first came out, there was/is still an 
>> issue, with two concurrent threads heavily working on their respective 
>> contiguous 64-byte structures. They can interfere with one another wrt 
>> using lock'ed rmw. Therefore, its is recommended to align _and_ pad 
>> things on a 128-byte boundary. ...
> 
> Not true. The L1-cache of NetBurst-CPUs had 64 byte lines and the
> L2-cache 128 byte lines with partitial invalidation of the lower
> or upper half through the L1-cache.
> What you say might have been true for Net-Burst based dual-socket
> Xeons.

Fair enough. So, this is fixed. Thanks for the info. :^)

[toc] | [prev] | [next] | [standalone]

#70633

On 12/24/2019 4:18 AM, Bonita Montero wrote:
>> Iirc, back when hyperthreading first came out, there was/is still an 
>> issue, with two concurrent threads heavily working on their respective 
>> contiguous 64-byte structures. They can interfere with one another wrt 
>> using lock'ed rmw. Therefore, its is recommended to align _and_ pad 
>> things on a 128-byte boundary. ...
> 
> Not true. The L1-cache of NetBurst-CPUs had 64 byte lines and the
> L2-cache 128 byte lines with partitial invalidation of the lower
> or upper half through the L1-cache.
> What you say might have been true for Net-Burst based dual-socket
> Xeons.

https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf

Section 3.7.3, Hardware Prefetching for Second-Level Cache.

[toc] | [prev] | [next] | [standalone]

#70639

>> Not true. The L1-cache of NetBurst-CPUs had 64 byte lines and the
>> L2-cache 128 byte lines with partitial invalidation of the lower
>> or upper half through the L1-cache.
>> What you say might have been true for Net-Burst based dual-socket
>> Xeons.

> https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf 
> Section 3.7.3, Hardware Prefetching for Second-Level Cache.

Alignment of prefetches is a totally different topic.

[toc] | [prev] | [next] | [standalone]

#70721

On 12/24/2019 5:30 PM, Bonita Montero wrote:
>>> Not true. The L1-cache of NetBurst-CPUs had 64 byte lines and the
>>> L2-cache 128 byte lines with partitial invalidation of the lower
>>> or upper half through the L1-cache.
>>> What you say might have been true for Net-Burst based dual-socket
>>> Xeons.
> 
>> https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf 
>> Section 3.7.3, Hardware Prefetching for Second-Level Cache.
> 
> Alignment of prefetches is a totally different topic.

Imvvho, it can present an insight into deeper levels of the cache 
architecture.

[toc] | [prev] | [next] | [standalone]

#70722

>>>> Not true. The L1-cache of NetBurst-CPUs had 64 byte lines and the
>>>> L2-cache 128 byte lines with partitial invalidation of the lower
>>>> or upper half through the L1-cache.
>>>> What you say might have been true for Net-Burst based dual-socket
>>>> Xeons.

>>> https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf 
>>> Section 3.7.3, Hardware Prefetching for Second-Level Cache.

>> Alignment of prefetches is a totally different topic.

> Imvvho, it can present an insight into deeper levels of the cache 
> architecture.

This has nothing to do with false or true sharing if the higher level
cache with a larger line-size is shared.

[toc] | [prev] | [next] | [standalone]

#70723

On 12/27/2019 11:54 PM, Bonita Montero wrote:
>>>>> Not true. The L1-cache of NetBurst-CPUs had 64 byte lines and the
>>>>> L2-cache 128 byte lines with partitial invalidation of the lower
>>>>> or upper half through the L1-cache.
>>>>> What you say might have been true for Net-Burst based dual-socket
>>>>> Xeons.
> 
>>>> https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf 
>>>> Section 3.7.3, Hardware Prefetching for Second-Level Cache.
> 
>>> Alignment of prefetches is a totally different topic.
> 
>> Imvvho, it can present an insight into deeper levels of the cache 
>> architecture.
> 
> This has nothing to do with false or true sharing if the higher level
> cache with a larger line-size is shared.

It did with earlier models.

[toc] | [prev] | [next] | [standalone]

#70724

On 12/27/2019 11:57 PM, Chris M. Thomasson wrote:
> On 12/27/2019 11:54 PM, Bonita Montero wrote:
>>>>>> Not true. The L1-cache of NetBurst-CPUs had 64 byte lines and the
>>>>>> L2-cache 128 byte lines with partitial invalidation of the lower
>>>>>> or upper half through the L1-cache.
>>>>>> What you say might have been true for Net-Burst based dual-socket
>>>>>> Xeons.
>>
>>>>> https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf 
>>>>> Section 3.7.3, Hardware Prefetching for Second-Level Cache.
>>
>>>> Alignment of prefetches is a totally different topic.
>>
>>> Imvvho, it can present an insight into deeper levels of the cache 
>>> architecture.
>>
>> This has nothing to do with false or true sharing if the higher level
>> cache with a larger line-size is shared.
> 
> It did with earlier models.

The split 128... Best to keep things padded and properly aligned on 
boundaries. The two halfs are interesting.

[toc] | [prev] | [next] | [standalone]

#70726

>> It did with earlier models.

> The split 128... Best to keep things padded and properly aligned on 
> boundaries. The two halfs are interesting.

That was only relevant to MP P4-Xeons but not to the P4 desktop-CPUs.
On the latter all threads shared a single L2-cache.

[toc] | [prev] | [next] | [standalone]

#70745

On 12/28/2019 12:53 AM, Bonita Montero wrote:
>>> It did with earlier models.
> 
>> The split 128... Best to keep things padded and properly aligned on 
>> boundaries. The two halfs are interesting.
> 
> That was only relevant to MP P4-Xeons but not to the P4 desktop-CPUs.
> On the latter all threads shared a single L2-cache.

Good to hear.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web