This morning I thought that blocks of memory the size of a cache line
that are completely overwritten by a thread make it unnecessary to
remotely load the previous contents of the block into the local cache.
Instead, it would be sufficient to simply send an invalidate message
to all other caches. Importantly, writes that are the full size of a
cache line queue up in the write queue, so there is no need to load
any data from a remote cache. I had tackled this issue before and
wrote the test below, but on my former Zen2 3990X Windows PC, which
is now my Linux PC, dumping two competing AVX stores on a cache line
for which the other cores are competing resulted in no performance
-advantages. But my Windows 11 PC is now a Ryzen 9 7950X 16 core.
Then I ran the benchmark below again. With this, the partial over-
writing of a cache line without deleting the cache line with two
AVX stores is about 2.3 times slower. I think that's an impressive
difference that could lead to a new kind of optimization.

#include <iostream>
#include <vector>
#include <memory>
#include <cstring>
#include <chrono>
#include <thread>
#include <functional>
#include <semaphore>
#if defined(_MSC_VER)
#include <intrin.h>
#elif defined(__GNUC__)
#include <immintrin.h>
#endif

using namespace std;
using namespace chrono;

int main()
{ constexpr size_t
#if defined(__cpp_lib_hardware_interference_size)
CL_SIZE = hardware_destructive_interference_size,
#else
CL_SIZE = 64,
#endif
BLOCK_SIZE = 16ull * 1024,
#if defined(NDEBUG)
ROUNDS = 0x10000;
#else
ROUNDS = 1;
#endif
atomic_int readyCountDown;
counting_semaphore ready( 0 );
atomic_int synch;
unsigned hc = jthread::hardware_concurrency();
vector<char> vc( BLOCK_SIZE + CL_SIZE - 1 );
char const *aligned = to_address( vc.cbegin() );
aligned = (char const *)(((size_t)aligned + CL_SIZE - 1) &
-(ptrdiff_t)CL_SIZE);
string_view avc( aligned, aligned + BLOCK_SIZE );
atomic_int64_t sumNs;
auto partitialWrite = [&]<typename Clear64>( Clear64 clear64 )
{
if( readyCountDown.fetch_sub( 1, memory_order::relaxed ) > 1 )
ready.acquire();
else
ready.release( hc - 1 );
if( synch.fetch_sub( 1, memory_order::relaxed ) > 1 )
while( synch.load( memory_order::relaxed ) );
auto start = high_resolution_clock::now();
for( size_t r = ROUNDS; r--; )
for( auto it = avc.begin(), end = avc.end(); end - it >= CL_SIZE; it
+= CL_SIZE )
clear64( to_address( it ) ),
(char &)*it = 0;
sumNs.fetch_add( duration_cast<nanoseconds>(
high_resolution_clock::now() - start ).count() );
};
static auto clClear = []( void const *p )
{
#if defined(_MSC_VER)
__m256d
zero = _mm256_setzero_pd(),
*pMM = (__m256d *)p;
pMM[0] = zero;
pMM[1] = zero;
#elif defined(__GNUC__) || defined(__clang__)
__m128d
zero = _mm_setzero_pd(),
*pMM = (__m128d *)p;
pMM[0] = zero;
pMM[1] = zero;
pMM[2] = zero;
pMM[3] = zero;
#endif
};
using fn_t = function<void ()> const;
fn_t
fnNoClear( [&]() { partitialWrite( []( void const *p ) {} ); } ),
fnClear( [&]() { partitialWrite( clClear ); } );
vector<jthread> threads;
auto initiate = [&]( bool clear, char const *head )
{
readyCountDown.store( hc, memory_order::relaxed );
synch.store( hc, memory_order::relaxed );
sumNs.store( 0, memory_order::relaxed );
for( unsigned t = hc; t--; )
threads.emplace_back( []( fn_t &fn ) { fn(); }, cref( !clear ?
fnNoClear : fnClear ) );
threads.resize( 0 );
double ns = sumNs.load( memory_order::relaxed ) / ((double)BLOCK_SIZE
/ CL_SIZE * ROUNDS);
cout << head << ns << endl;
};
initiate( false, "no-clear: " );
initiate( true, "clear: " );
}

I further improved the code and I found that even if I clear
the cacheline with eight uint64_t stores I get the same speedup.
Would be nice to know wheter other x86-CPUs also have this kind
of optimization.

On 07/05/2023 6:25 pm, Bonita Montero wrote:
> This morning I thought that blocks of memory the size of a cache line
> that are completely overwritten by a thread make it unnecessary to
> remotely load the previous contents of the block into the local cache.
> Instead, it would be sufficient to simply send an invalidate message
> to all other caches. Importantly, writes that are the full size of a
> cache line queue up in the write queue, so there is no need to load
> any data from a remote cache. I had tackled this issue before and
> wrote the test below, but on my former Zen2 3990X Windows PC, which
> is now my Linux PC, dumping two competing AVX stores on a cache line
> for which the other cores are competing resulted in no performance
> -advantages. But my Windows 11 PC is now a Ryzen 9 7950X 16 core.
> Then I ran the benchmark below again. With this, the partial over-
> writing of a cache line without deleting the cache line with two
> AVX stores is about 2.3 times slower. I think that's an impressive
> difference that could lead to a new kind of optimization.
>
> #include <iostream>
> #include <vector>
> #include <memory>
> #include <cstring>
> #include <chrono>
> #include <thread>
> #include <functional>
> #include <semaphore>
> #if defined(_MSC_VER)
>     #include <intrin.h>
> #elif defined(__GNUC__)
>     #include <immintrin.h>
> #endif
>
> using namespace std;
> using namespace chrono;
>
> int main()
> {
>     constexpr size_t
> #if defined(__cpp_lib_hardware_interference_size)
>         CL_SIZE = hardware_destructive_interference_size,
> #else
>         CL_SIZE = 64,
> #endif
>         BLOCK_SIZE = 16ull * 1024,
> #if defined(NDEBUG)
>         ROUNDS = 0x10000;
> #else
>         ROUNDS = 1;
> #endif
>     atomic_int readyCountDown;
>     counting_semaphore ready( 0 );
>     atomic_int synch;
>     unsigned hc = jthread::hardware_concurrency();
>     vector<char> vc( BLOCK_SIZE + CL_SIZE - 1 );
>     char const *aligned = to_address( vc.cbegin() );
>     aligned = (char const *)(((size_t)aligned + CL_SIZE - 1) &
> -(ptrdiff_t)CL_SIZE);
>     string_view avc( aligned, aligned + BLOCK_SIZE );
>     atomic_int64_t sumNs;
>     auto partitialWrite = [&]<typename Clear64>( Clear64 clear64 )
>     {
>         if( readyCountDown.fetch_sub( 1, memory_order::relaxed ) > 1 )
>             ready.acquire();
>         else
>             ready.release( hc - 1 );
>         if( synch.fetch_sub( 1, memory_order::relaxed ) > 1 )
>             while( synch.load( memory_order::relaxed ) );
>         auto start = high_resolution_clock::now();
>         for( size_t r = ROUNDS; r--; )
>             for( auto it = avc.begin(), end = avc.end(); end - it >=
> CL_SIZE; it += CL_SIZE )
>                 clear64( to_address( it ) ),
>                 (char &)*it = 0;
>         sumNs.fetch_add( duration_cast<nanoseconds>(
> high_resolution_clock::now() - start ).count() );
>     };
>     static auto clClear = []( void const *p )
>     {
> #if defined(_MSC_VER)
>         __m256d
>             zero = _mm256_setzero_pd(),
>             *pMM = (__m256d *)p;
>         pMM[0] = zero;
>         pMM[1] = zero;
> #elif defined(__GNUC__) || defined(__clang__)
>         __m128d
>             zero = _mm_setzero_pd(),
>             *pMM = (__m128d *)p;
>         pMM[0] = zero;
>         pMM[1] = zero;
>         pMM[2] = zero;
>         pMM[3] = zero;
> #endif
>     };
>     using fn_t = function<void ()> const;
>     fn_t
>         fnNoClear( [&]() { partitialWrite( []( void const *p ) {} ); } ),
>         fnClear( [&]() { partitialWrite( clClear ); } );
>     vector<jthread> threads;
>     auto initiate = [&]( bool clear, char const *head )
>     {
>         readyCountDown.store( hc, memory_order::relaxed );
>         synch.store( hc, memory_order::relaxed );
>         sumNs.store( 0, memory_order::relaxed );
>         for( unsigned t = hc; t--; )
>             threads.emplace_back( []( fn_t &fn ) { fn(); }, cref(
> !clear ? fnNoClear : fnClear ) );
>         threads.resize( 0 );
>         double ns = sumNs.load( memory_order::relaxed ) /
> ((double)BLOCK_SIZE / CL_SIZE * ROUNDS);
>         cout << head << ns << endl;
>     };
>     initiate( false, "no-clear: " );
>     initiate( true, "clear: " );
> }

Your code is an unreadable mess made worse by the "using" directives.

/Flibble

Am 08.05.2023 um 06:01 schrieb Mr Flibble:
> On 07/05/2023 6:25 pm, Bonita Montero wrote:
>> This morning I thought that blocks of memory the size of a cache line
>> that are completely overwritten by a thread make it unnecessary to
>> remotely load the previous contents of the block into the local cache.
>> Instead, it would be sufficient to simply send an invalidate message
>> to all other caches. Importantly, writes that are the full size of a
>> cache line queue up in the write queue, so there is no need to load
>> any data from a remote cache. I had tackled this issue before and
>> wrote the test below, but on my former Zen2 3990X Windows PC, which
>> is now my Linux PC, dumping two competing AVX stores on a cache line
>> for which the other cores are competing resulted in no performance
>> -advantages. But my Windows 11 PC is now a Ryzen 9 7950X 16 core.
>> Then I ran the benchmark below again. With this, the partial over-
>> writing of a cache line without deleting the cache line with two
>> AVX stores is about 2.3 times slower. I think that's an impressive
>> difference that could lead to a new kind of optimization.
>>
>> #include <iostream>
>> #include <vector>
>> #include <memory>
>> #include <cstring>
>> #include <chrono>
>> #include <thread>
>> #include <functional>
>> #include <semaphore>
>> #if defined(_MSC_VER)
>>      #include <intrin.h>
>> #elif defined(__GNUC__)
>>      #include <immintrin.h>
>> #endif
>>
>> using namespace std;
>> using namespace chrono;
>>
>> int main()
>> {
>>      constexpr size_t
>> #if defined(__cpp_lib_hardware_interference_size)
>>          CL_SIZE = hardware_destructive_interference_size,
>> #else
>>          CL_SIZE = 64,
>> #endif
>>          BLOCK_SIZE = 16ull * 1024,
>> #if defined(NDEBUG)
>>          ROUNDS = 0x10000;
>> #else
>>          ROUNDS = 1;
>> #endif
>>      atomic_int readyCountDown;
>>      counting_semaphore ready( 0 );
>>      atomic_int synch;
>>      unsigned hc = jthread::hardware_concurrency();
>>      vector<char> vc( BLOCK_SIZE + CL_SIZE - 1 );
>>      char const *aligned = to_address( vc.cbegin() );
>>      aligned = (char const *)(((size_t)aligned + CL_SIZE - 1) &
>> -(ptrdiff_t)CL_SIZE);
>>      string_view avc( aligned, aligned + BLOCK_SIZE );
>>      atomic_int64_t sumNs;
>>      auto partitialWrite = [&]<typename Clear64>( Clear64 clear64 )
>>      {
>>          if( readyCountDown.fetch_sub( 1, memory_order::relaxed ) > 1 )
>>              ready.acquire();
>>          else
>>              ready.release( hc - 1 );
>>          if( synch.fetch_sub( 1, memory_order::relaxed ) > 1 )
>>              while( synch.load( memory_order::relaxed ) );
>>          auto start = high_resolution_clock::now();
>>          for( size_t r = ROUNDS; r--; )
>>              for( auto it = avc.begin(), end = avc.end(); end - it >=
>> CL_SIZE; it += CL_SIZE )
>>                  clear64( to_address( it ) ),
>>                  (char &)*it = 0;
>>          sumNs.fetch_add( duration_cast<nanoseconds>(
>> high_resolution_clock::now() - start ).count() );
>>      };
>>      static auto clClear = []( void const *p )
>>      {
>> #if defined(_MSC_VER)
>>          __m256d
>>              zero = _mm256_setzero_pd(),
>>              *pMM = (__m256d *)p;
>>          pMM[0] = zero;
>>          pMM[1] = zero;
>> #elif defined(__GNUC__) || defined(__clang__)
>>          __m128d
>>              zero = _mm_setzero_pd(),
>>              *pMM = (__m128d *)p;
>>          pMM[0] = zero;
>>          pMM[1] = zero;
>>          pMM[2] = zero;
>>          pMM[3] = zero;
>> #endif
>>      };
>>      using fn_t = function<void ()> const;
>>      fn_t
>>          fnNoClear( [&]() { partitialWrite( []( void const *p ) {} );
>> } ),
>>          fnClear( [&]() { partitialWrite( clClear ); } );
>>      vector<jthread> threads;
>>      auto initiate = [&]( bool clear, char const *head )
>>      {
>>          readyCountDown.store( hc, memory_order::relaxed );
>>          synch.store( hc, memory_order::relaxed );
>>          sumNs.store( 0, memory_order::relaxed );
>>          for( unsigned t = hc; t--; )
>>              threads.emplace_back( []( fn_t &fn ) { fn(); }, cref(
>> !clear ? fnNoClear : fnClear ) );
>>          threads.resize( 0 );
>>          double ns = sumNs.load( memory_order::relaxed ) /
>> ((double)BLOCK_SIZE / CL_SIZE * ROUNDS);
>>          cout << head << ns << endl;
>>      };
>>      initiate( false, "no-clear: " );
>>      initiate( true, "clear: " );
>> }
>
> Your code is an unreadable mess made worse by the "using" directives.

If that is your problem you'd have a lot of other problems with the
code.

My previous benchmark measures the time it takes to write a cache line
that other cores are competing for. But I figured that writing a cache
line would be faster even if it didn't have to be fetched from another
cache, but came directly from RAM. When loading from RAM, a snoop must
be sent to the other cores, but if the CPU recognizes that the cache
line is being completely overwritten, then only an invalidate message
must be sent to the other caches, i.e. the snoop response does not
have to contain any content.
The benchmark below measures this by repetitively scanning a one
gigabyte block of memory. On my 7950X Zen4 system, wiping the cache
line first gives a speedup of about 16%. On my 3990X Zen2 system
there's a slow-down of about 2%.

#include <iostream>
#include <vector>
#include <new>
#include <chrono>
#include <cmath>
#if defined(_MSC_VER)
#include <intrin.h>
#elif defined(__GNUC__) || defined(__clang__)
#include <immintrin.h>
#endif

using namespace std;
using namespace chrono;

int main()
{ constexpr size_t
#if defined(__cpp_lib_hardware_interference_size)
CL_SIZE = hardware_destructive_interference_size,
#else
CL_SIZE = 64,
#endif
BLOCK_SIZE = 1ull << 30,
ROUNDS = 30;
vector<char> block( BLOCK_SIZE + CL_SIZE - 1 );
char
*align = (char *)((size_t)(to_address( block.begin() ) + CL_SIZE - 1)
& -(ptrdiff_t)CL_SIZE),
*alignEnd = align + BLOCK_SIZE;
auto bench = [&]<typename Clear>( char const *head, Clear clear, double
before ) -> double
{
auto start = high_resolution_clock::now();
for( size_t r = ROUNDS; r--; )
for( char *p = (char *)align; p != alignEnd; p += CL_SIZE )
clear( p ),
*p = 0;
double ns = duration_cast<nanoseconds>( high_resolution_clock::now() -
start ).count() / ((double)ROUNDS * BLOCK_SIZE / CL_SIZE);
cout << head << ns;
if( before > 0.0 )
cout << " (" << trunc( 1.0e3 * before / ns ) / 10.0 << "%)";
cout << endl;
return ns;
};
static auto clClear = []( void const *p )
{
#if defined(_MSC_VER) && (defined(__AVX__) || defined(__AVX512VL__) ||
defined(__AVX512DQ__))
#if defined(__AVX512VL__) || defined(__AVX512DQ__)
*(__m512d *)p = _mm512_setzero_pd();
#else
__m256d
zero = _mm256_setzero_pd(),
*pMM = (__m256d *)p;
pMM[0] = zero;
pMM[1] = zero;
#endif
#elif defined(__GNUC__) || defined(__clang__)
__m128d
zero = _mm_setzero_pd(),
*pMM = (__m128d *)p;
pMM[0] = zero;
pMM[1] = zero;
pMM[2] = zero;
pMM[3] = zero;
#else
auto unroll = []<size_t ... Indices, typename Fn>(
index_sequence<Indices ...>, Fn fn )
{
((fn.template operator ()<Indices>()), ...);
};
unroll( make_index_sequence<CL_SIZE / 8>(), [&]<size_t I>() {
((uint64_t*)p)[I] = 0; } );
#endif
};
static auto clUntouched = []( auto ) {};
double untouched = bench( "untouched: ", clUntouched, -1.0 );
bench( "clear: ", clClear, untouched );
}

On 08/05/2023 5:44 am, Bonita Montero wrote:
> Am 08.05.2023 um 06:01 schrieb Mr Flibble:
>> On 07/05/2023 6:25 pm, Bonita Montero wrote:
>>> This morning I thought that blocks of memory the size of a cache line
>>> that are completely overwritten by a thread make it unnecessary to
>>> remotely load the previous contents of the block into the local cache.
>>> Instead, it would be sufficient to simply send an invalidate message
>>> to all other caches. Importantly, writes that are the full size of a
>>> cache line queue up in the write queue, so there is no need to load
>>> any data from a remote cache. I had tackled this issue before and
>>> wrote the test below, but on my former Zen2 3990X Windows PC, which
>>> is now my Linux PC, dumping two competing AVX stores on a cache line
>>> for which the other cores are competing resulted in no performance
>>> -advantages. But my Windows 11 PC is now a Ryzen 9 7950X 16 core.
>>> Then I ran the benchmark below again. With this, the partial over-
>>> writing of a cache line without deleting the cache line with two
>>> AVX stores is about 2.3 times slower. I think that's an impressive
>>> difference that could lead to a new kind of optimization.
>>>
>>> #include <iostream>
>>> #include <vector>
>>> #include <memory>
>>> #include <cstring>
>>> #include <chrono>
>>> #include <thread>
>>> #include <functional>
>>> #include <semaphore>
>>> #if defined(_MSC_VER)
>>>      #include <intrin.h>
>>> #elif defined(__GNUC__)
>>>      #include <immintrin.h>
>>> #endif
>>>
>>> using namespace std;
>>> using namespace chrono;
>>>
>>> int main()
>>> {
>>>      constexpr size_t
>>> #if defined(__cpp_lib_hardware_interference_size)
>>>          CL_SIZE = hardware_destructive_interference_size,
>>> #else
>>>          CL_SIZE = 64,
>>> #endif
>>>          BLOCK_SIZE = 16ull * 1024,
>>> #if defined(NDEBUG)
>>>          ROUNDS = 0x10000;
>>> #else
>>>          ROUNDS = 1;
>>> #endif
>>>      atomic_int readyCountDown;
>>>      counting_semaphore ready( 0 );
>>>      atomic_int synch;
>>>      unsigned hc = jthread::hardware_concurrency();
>>>      vector<char> vc( BLOCK_SIZE + CL_SIZE - 1 );
>>>      char const *aligned = to_address( vc.cbegin() );
>>>      aligned = (char const *)(((size_t)aligned + CL_SIZE - 1) &
>>> -(ptrdiff_t)CL_SIZE);
>>>      string_view avc( aligned, aligned + BLOCK_SIZE );
>>>      atomic_int64_t sumNs;
>>>      auto partitialWrite = [&]<typename Clear64>( Clear64 clear64 )
>>>      {
>>>          if( readyCountDown.fetch_sub( 1, memory_order::relaxed ) > 1 )
>>>              ready.acquire();
>>>          else
>>>              ready.release( hc - 1 );
>>>          if( synch.fetch_sub( 1, memory_order::relaxed ) > 1 )
>>>              while( synch.load( memory_order::relaxed ) );
>>>          auto start = high_resolution_clock::now();
>>>          for( size_t r = ROUNDS; r--; )
>>>              for( auto it = avc.begin(), end = avc.end(); end - it >=
>>> CL_SIZE; it += CL_SIZE )
>>>                  clear64( to_address( it ) ),
>>>                  (char &)*it = 0;
>>>          sumNs.fetch_add( duration_cast<nanoseconds>(
>>> high_resolution_clock::now() - start ).count() );
>>>      };
>>>      static auto clClear = []( void const *p )
>>>      {
>>> #if defined(_MSC_VER)
>>>          __m256d
>>>              zero = _mm256_setzero_pd(),
>>>              *pMM = (__m256d *)p;
>>>          pMM[0] = zero;
>>>          pMM[1] = zero;
>>> #elif defined(__GNUC__) || defined(__clang__)
>>>          __m128d
>>>              zero = _mm_setzero_pd(),
>>>              *pMM = (__m128d *)p;
>>>          pMM[0] = zero;
>>>          pMM[1] = zero;
>>>          pMM[2] = zero;
>>>          pMM[3] = zero;
>>> #endif
>>>      };
>>>      using fn_t = function<void ()> const;
>>>      fn_t
>>>          fnNoClear( [&]() { partitialWrite( []( void const *p ) {} );
>>> } ),
>>>          fnClear( [&]() { partitialWrite( clClear ); } );
>>>      vector<jthread> threads;
>>>      auto initiate = [&]( bool clear, char const *head )
>>>      {
>>>          readyCountDown.store( hc, memory_order::relaxed );
>>>          synch.store( hc, memory_order::relaxed );
>>>          sumNs.store( 0, memory_order::relaxed );
>>>          for( unsigned t = hc; t--; )
>>>              threads.emplace_back( []( fn_t &fn ) { fn(); }, cref(
>>> !clear ? fnNoClear : fnClear ) );
>>>          threads.resize( 0 );
>>>          double ns = sumNs.load( memory_order::relaxed ) /
>>> ((double)BLOCK_SIZE / CL_SIZE * ROUNDS);
>>>          cout << head << ns << endl;
>>>      };
>>>      initiate( false, "no-clear: " );
>>>      initiate( true, "clear: " );
>>> }
>>
>> Your code is an unreadable mess made worse by the "using" directives.
>
> If that is your problem you'd have a lot of other problems with the
> code.

Yes, I do:

Another problem I have with the code is the lack of whitespace (again
hinders readability).

Yet another problem I have with the code is short or meaningless
variable names; meaningful variable and function names almost makes code
self documenting.

And yet another problem I have with the code is the author.

/Flibble

Am 08.05.2023 um 16:22 schrieb Mr Flibble:

> Yes, I do:
>
> Another problem I have with the code is the lack of whitespace (again
> hinders readability).
>
> Yet another problem I have with the code is short or meaningless
> variable names; meaningful variable and function names almost makes code
> self documenting.
>
> And yet another problem I have with the code is the author.
>
> /Flibble

That's just a matter of taste and IQ.

On 08/05/2023 4:19 pm, Bonita Montero wrote:
> Am 08.05.2023 um 16:22 schrieb Mr Flibble:
>
>> Yes, I do:
>>
>> Another problem I have with the code is the lack of whitespace (again
>> hinders readability).
>>
>> Yet another problem I have with the code is short or meaningless
>> variable names; meaningful variable and function names almost makes
>> code self documenting.
>>
>> And yet another problem I have with the code is the author.
>>
>> /Flibble
>
> That's just a matter of taste and IQ.

If the target audience of your code is just yourself then you could
probably get away with writing a shite incomprehensible mess but you are
posting your code to a public forum with the hope, presumably, that
others will read it so you should, as a bare minimum, attempt to make
your code comprehensible to others.

/Flibble

Am 08.05.2023 um 18:06 schrieb Mr Flibble:
> On 08/05/2023 4:19 pm, Bonita Montero wrote:
>> Am 08.05.2023 um 16:22 schrieb Mr Flibble:
>>
>>> Yes, I do:
>>>
>>> Another problem I have with the code is the lack of whitespace (again
>>> hinders readability).
>>>
>>> Yet another problem I have with the code is short or meaningless
>>> variable names; meaningful variable and function names almost makes
>>> code self documenting.
>>>
>>> And yet another problem I have with the code is the author.
>>>
>>> /Flibble
>>
>> That's just a matter of taste and IQ.
>
> If the target audience of your code is just yourself ...

No, it's people that also understood what I wrote along with
the source.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>My previous benchmark measures the time it takes to write a cache line
>that other cores are competing for. But I figured that writing a cache
>line would be faster even if it didn't have to be fetched from another
>cache, but came directly from RAM. When loading from RAM, a snoop must
>be sent to the other cores, but if the CPU recognizes that the cache
>line is being completely overwritten, then only an invalidate message
>must be sent to the other caches, i.e. the snoop response does not
>have to contain any content.

Actually, the first store (e.g. 8-byte 64-bit store) that hits the
cache line requires the local cache to acquire exclusive access
to the entire line. At which point the coherency protocol will
request other cores to either write a modified line back to
memory (or a higher cache level, e.g. L3, depending on whether
the cache levels are exclusive or inclusive) or invalidate a
shared or owned line before responding to the local cache exclusive access request.

By the time the CPU knows that the entire line has been modified
it is far to late to simply invalidate any remote lines.

Am 08.05.2023 um 18:59 schrieb Scott Lurndal:

> By the time the CPU knows that the entire line has been modified
> it is far to late to simply invalidate any remote lines.

As I've shown there's a performance difference when the cacheline
is written a whole. So there's a remote invalidation only.