Am 31.12.2023 um 18:30 schrieb Kaz Kylheku:

> When I describe a scenario in which five items are being frequently
> accessed and collide to the same cache line, which is associative with
> a set size of four, there is necessarily a conflict, because five is
> greater than four.

However, this scenario is unlikely to occur so often that
it makes sense to not let the stacks run synchronously.

Am 31.12.2023 um 19:44 schrieb Scott Lurndal:

> Why? ...

Because there must be set-conflicts on the same line index.
That's rather unlikely with four-way associativeness.

Am 31.12.2023 um 20:36 schrieb Chris M. Thomasson:

>> I'm pretty sure they never ran the numbers on that.

> I am pretty sure you are trolling, Bonita?

If you allocate memory the memory usually comes from a pool
where theset indices of the memory block are rather randomized.
It's rather unlikey that you'd get set conflicts with the both
thread to an extent that this really hurts performance.

On 12/31/2023 10:28 PM, Bonita Montero wrote:
> Am 31.12.2023 um 20:36 schrieb Chris M. Thomasson:
>
>>> I'm pretty sure they never ran the numbers on that.
>
>> I am pretty sure you are trolling, Bonita?
>
> If you allocate memory the memory usually comes from a pool
> where theset indices of the memory block are rather randomized.
> It's rather  unlikey that you'd get set conflicts with the both
> thread to an extent that this really hurts performance.
>

Oh my. You really did not read the paper I linked to up thread!

On 2024-01-01, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 31.12.2023 um 19:44 schrieb Scott Lurndal:
>
>> Why? ...
>
> Because there must be set-conflicts on the same line index.
> That's rather unlikely with four-way associativeness.

It's rather likely. Suppose you have a large number of threads,
with stacks that end on a multiple of 64 kB.

Only two of these threads are runnable concurrently on the
two hyperthreads. However, your application may be rapidly
switching between them.

If their stacks evacuate each other from the L1 cache,
that could be bad.

For compute-bound tasks with long quanta, it might not
matter so much; the same threads will occupy the hyperthreads
for tens of milliseconds at a time or whatever.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 31/12/2023 19:49, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 29/12/2023 17:04, Bonita Montero wrote:
>
>>>
>>> You've got strange ideas. alloca() has been completely removed from the
>>> Linux kernel.
>>
>> Citation? You are usually wrong in your claims, or at least mixed-up,
>> so I won't trust you without evidence. (That does not mean you are
>> wrong here - I don't know either way.)
>
> Kernel threads generally run with a small, fixed stack. Stack-based
> dynamic allocation is generally avoided. I don't know of any
> hard restrictions, but I suspect that Linus would look askance
> at it.
>

Oh, I have no doubts that it would be frowned upon in the kernel itself.
And I know that VLAs have been actively removed from the kernel. But
Bonita's claim implies that "alloca()" was used in the kernel earlier,
and has since been removed, presumably due to a specific decision.

>>
>> Of course, avoiding alloca() within the kernel is, again, utterly
>> irrelevant to the point under discussion.
>
> Very true

Am 01.01.2024 um 09:28 schrieb Kaz Kylheku:

> It's rather likely. ...

Absolutely not.

> Suppose you have a large number of threads,
> with stacks that end on a multiple of 64 kB.

The set size isn't 64kB.

> Only two of these threads are runnable concurrently on the
> two hyperthreads. However, your application may be rapidly
> switching between them.

If you have two threads synchronous in terms of stack allocation
you need conflicting data that touches cacklines with the same
set indices. That's unlikely.
The suggestion Intel made here is just a Nerd-suggestion.

Am 01.01.2024 um 07:53 schrieb Chris M. Thomasson:

> Oh my. You really did not read the paper I linked to up thread!

The suggestion Intel made here is just a Nerd-suggestion and
you're a nerd as well.

On 1/1/2024 5:11 AM, Bonita Montero wrote:
> Am 01.01.2024 um 07:53 schrieb Chris M. Thomasson:
>
>> Oh my. You really did not read the paper I linked to up thread!
>
> The suggestion Intel made here is just a Nerd-suggestion and
> you're a nerd as well.
>

LOL! Wow, you are the king of interesting responses!

:^) Happy New Year!

On 1/1/2024 5:11 AM, Bonita Montero wrote:
> Am 01.01.2024 um 09:28 schrieb Kaz Kylheku:
>
>> It's rather likely. ...
>
> Absolutely not.
>
>> Suppose you have a large number of threads,
>> with stacks that end on a multiple of 64 kB.
>
> The set size isn't 64kB.
>
>> Only two of these threads are runnable concurrently on the
>> two hyperthreads. However, your application may be rapidly
>> switching between them.
>
> If you have two threads synchronous in terms of stack allocation
> you need conflicting data that touches cacklines with the same
> set indices. That's unlikely.
> The suggestion Intel made here is just a Nerd-suggestion.
>

Are you are a full blown moron, or just a little?

Am 02.01.2024 um 00:34 schrieb Chris M. Thomasson:
> On 1/1/2024 5:11 AM, Bonita Montero wrote:
>> Am 01.01.2024 um 07:53 schrieb Chris M. Thomasson:
>>
>>> Oh my. You really did not read the paper I linked to up thread!
>>
>> The suggestion Intel made here is just a Nerd-suggestion and
>> you're a nerd as well.
>>
>
> LOL! Wow, you are the king of interesting responses!

You consider this suggestion to be important because it makes
you feel important.

On 1/2/2024 2:55 AM, Bonita Montero wrote:
> Am 02.01.2024 um 00:34 schrieb Chris M. Thomasson:
>> On 1/1/2024 5:11 AM, Bonita Montero wrote:
>>> Am 01.01.2024 um 07:53 schrieb Chris M. Thomasson:
>>>
>>>> Oh my. You really did not read the paper I linked to up thread!
>>>
>>> The suggestion Intel made here is just a Nerd-suggestion and
>>> you're a nerd as well.
>>>
>>
>> LOL! Wow, you are the king of interesting responses!
>
> You consider this suggestion to be important because it makes
> you feel important.
>

Not true. Don't project on me, oh holy one.

Now, I was reading all of the Intel optimization guides and using VTune
at the time, early 2000's. I happened to remember this one (64k aliasing
problem), and even found my own C code on the wayback machine that used
it. Just because you have not read them does not make me feel
"important". You silly rabbit! Tricks are for kids. :^)

Am 02.01.2024 um 19:38 schrieb Chris M. Thomasson:
> On 1/2/2024 2:55 AM, Bonita Montero wrote:
>> Am 02.01.2024 um 00:34 schrieb Chris M. Thomasson:
>>> On 1/1/2024 5:11 AM, Bonita Montero wrote:
>>>> Am 01.01.2024 um 07:53 schrieb Chris M. Thomasson:
>>>>
>>>>> Oh my. You really did not read the paper I linked to up thread!
>>>>
>>>> The suggestion Intel made here is just a Nerd-suggestion and
>>>> you're a nerd as well.
>>>>
>>>
>>> LOL! Wow, you are the king of interesting responses!
>>
>> You consider this suggestion to be important because it makes
>> you feel important.
>>
>
> Not true. Don't project on me, oh holy one.

I know you in this point - very good.

> Now, I was reading all of the Intel optimization guides and using VTune
> at the time, early 2000's. I happened to remember this one (64k aliasing
> problem), ...

There is no 64kB aliasing problem with the L1-cache since the cache
is smaller.

On 1/2/2024 9:48 PM, Bonita Montero wrote:
> Am 02.01.2024 um 19:38 schrieb Chris M. Thomasson:
>> On 1/2/2024 2:55 AM, Bonita Montero wrote:
>>> Am 02.01.2024 um 00:34 schrieb Chris M. Thomasson:
>>>> On 1/1/2024 5:11 AM, Bonita Montero wrote:
>>>>> Am 01.01.2024 um 07:53 schrieb Chris M. Thomasson:
>>>>>
>>>>>> Oh my. You really did not read the paper I linked to up thread!
>>>>>
>>>>> The suggestion Intel made here is just a Nerd-suggestion and
>>>>> you're a nerd as well.
>>>>>
>>>>
>>>> LOL! Wow, you are the king of interesting responses!
>>>
>>> You consider this suggestion to be important because it makes
>>> you feel important.
>>>
>>
>> Not true. Don't project on me, oh holy one.
>
> I know you in this point - very good.
>
>> Now, I was reading all of the Intel optimization guides and using
>> VTune at the time, early 2000's. I happened to remember this one (64k
>> aliasing problem), ...
>
> There is no 64kB aliasing problem with the L1-cache since the cache
> is smaller.
>

Oh god. Have you not read the paper yet? If you have read it all, then
you do not seem to understand it at all. That's on you, Bonita. Like I
said you need to write Intel a letter telling them how that paper never
needed to be written. Lol! You make me laugh!

:^)

Am 03.01.2024 um 22:32 schrieb Chris M. Thomasson:

> On 1/2/2024 9:48 PM, Bonita Montero wrote:

>> There is no 64kB aliasing problem with the L1-cache since the cache
>> is smaller.

> Oh god. Have you not read the paper yet? ...

The Pentium 4's L1 data cache is between 16 and 32kB, so there
can't be a 64kB aliasing. And aliasing can be only on a set basis
and the sets are 4kB or 8kB large.

On 1/3/2024 7:37 PM, Bonita Montero wrote:
> Am 03.01.2024 um 22:32 schrieb Chris M. Thomasson:
>
>> On 1/2/2024 9:48 PM, Bonita Montero wrote:
>
>>> There is no 64kB aliasing problem with the L1-cache since the cache
>>> is smaller.
>
>> Oh god. Have you not read the paper yet? ...
>
>
> The Pentium 4's L1 data cache is between 16 and 32kB, so there
> can't be a 64kB aliasing. And aliasing can be only on a set basis
> and the sets are 4kB or 8kB large.
>

Are you trying to tell me that the aliasing problem on those older Intel
hyperthreaded processors and the workaround (from Intel) was a myth?
lol. ;^)

Am 06.01.2024 um 04:21 schrieb Chris M. Thomasson:

> Are you trying to tell me that the aliasing problem on those older Intel
> hyperthreaded processors and the workaround (from Intel) was a myth?
> lol. ;^)

Intel just made a nerd-suggestion. With four-way associativity
there's no frequent aliasing problem in the L1 data dache of
Pentium 4.

On 2024-01-06, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 06.01.2024 um 04:21 schrieb Chris M. Thomasson:
>
>> Are you trying to tell me that the aliasing problem on those older Intel
>> hyperthreaded processors and the workaround (from Intel) was a myth?
>> lol. ;^)
>
> Intel just made a nerd-suggestion. With four-way associativity
> there's no frequent aliasing problem in the L1 data dache of
> Pentium 4.

I think the L1 cache was 8K on that thing, and the blocks are 32 bytes.

I think how it works on the P4 is that the address is structured is like
this:

31 11 10 5 4 0
| | | | | |
[ 21 bit tag ] [ 6 bit cache set ] [ 5 bit offset into 32 bit block ]

Thus say we have an area of the stack with the address
range nnnnFF80 to nnnnFFFF (128 bytes, 4 x 32 byte cache blocks).

These four blocks all map to the same set: they have the same six
bits in the "cache set" part of the address.

So if a thread is accessing something in all four blocks, it will
completely use that cache set, all by itself.

If any other thread has a similar block in its stack, with the same
cache set ID, it will cause evictions against this thread.

Sure, if each of these threads confines itself to working with just one
cacheline-sized aperture of the stack, it looks better.

You're forgetting that the sets are very small and that groups of
adjacent four 32 byte blocks map to the same set. Touch four adjacent
cache blocks that are aligned on a 128 byte boundary, and you have
hit full occupancy in the cache set corresponding to that block!

(I suspect the references to 64K should not be kilobytes but sets.
The 8K cache has 64 sets.)

In memory, 128 byte blocks that is aligned maps to, and precisely covers
a cache set. If two such blocks addresses that are equal modulo 8K, they
collide to the same cache set. If one of those blocks is fully present
in the cache, the other must be fully evicted.

It's really easy to see how things can go south under hyperthreading.
If two hyperthreads are working with clashing 128 byte areas that each
want to hog the same cache set, and the core is switching between them
on a fine-grained basis, ... you get the picture.

It's very easy for the memory mapping allocations used for thread
stacks to produce addresses such tha the delta between them is a
multiple of 8K.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Am 06.01.2024 um 09:31 schrieb Kaz Kylheku:
> On 2024-01-06, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 06.01.2024 um 04:21 schrieb Chris M. Thomasson:
>>
>>> Are you trying to tell me that the aliasing problem on those older Intel
>>> hyperthreaded processors and the workaround (from Intel) was a myth?
>>> lol. ;^)
>>
>> Intel just made a nerd-suggestion. With four-way associativity
>> there's no frequent aliasing problem in the L1 data dache of
>> Pentium 4.
>
> I think the L1 cache was 8K on that thing, and the blocks are 32 bytes.
>
> I think how it works on the P4 is that the address is structured is like
> this:
>
> 31 11 10 5 4 0
> | | | | | |
> [ 21 bit tag ] [ 6 bit cache set ] [ 5 bit offset into 32 bit block ]
>
> Thus say we have an area of the stack with the address
> range nnnnFF80 to nnnnFFFF (128 bytes, 4 x 32 byte cache blocks).
>
> These four blocks all map to the same set: they have the same six
> bits in the "cache set" part of the address.
>
> So if a thread is accessing something in all four blocks, it will
> completely use that cache set, all by itself.
>
> If any other thread has a similar block in its stack, with the same
> cache set ID, it will cause evictions against this thread.
>
> Sure, if each of these threads confines itself to working with just one
> cacheline-sized aperture of the stack, it looks better.
>
> You're forgetting that the sets are very small and that groups of
> adjacent four 32 byte blocks map to the same set. Touch four adjacent
> cache blocks that are aligned on a 128 byte boundary, and you have
> hit full occupancy in the cache set corresponding to that block!
>
> (I suspect the references to 64K should not be kilobytes but sets.
> The 8K cache has 64 sets.)
>
> In memory, 128 byte blocks that is aligned maps to, and precisely covers
> a cache set. If two such blocks addresses that are equal modulo 8K, they
> collide to the same cache set. If one of those blocks is fully present
> in the cache, the other must be fully evicted.
>
> It's really easy to see how things can go south under hyperthreading.
> If two hyperthreads are working with clashing 128 byte areas that each
> want to hog the same cache set, and the core is switching between them
> on a fine-grained basis, ... you get the picture.
>
> It's very easy for the memory mapping allocations used for thread
> stacks to produce addresses such tha the delta between them is a
> multiple of 8K.
>

Of course it's easy to intentionally provoke frequent aliasing
with the P4's L1 cache, but actually this doesn't happen often.

On 1/6/2024 1:30 AM, Bonita Montero wrote:
> Am 06.01.2024 um 09:31 schrieb Kaz Kylheku:
>> On 2024-01-06, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 06.01.2024 um 04:21 schrieb Chris M. Thomasson:
>>>
>>>> Are you trying to tell me that the aliasing problem on those older
>>>> Intel
>>>> hyperthreaded processors and the workaround (from Intel) was a myth?
>>>> lol. ;^)
>>>
>>> Intel just made a nerd-suggestion. With four-way associativity
>>> there's no frequent aliasing problem in the L1 data dache of
>>> Pentium 4.
>>
>> I think the L1 cache was 8K on that thing, and the blocks are 32 bytes.
>>
>> I think how it works on the P4 is that the address is structured is like
>> this:
>>
>>   31          11 10                5 4                                0
>>   |            | |                 | |                                |
>>   [ 21 bit tag ] [ 6 bit cache set ] [ 5 bit offset into 32 bit block ]
>>
>> Thus say we have an area of the stack with the address
>> range nnnnFF80 to nnnnFFFF (128 bytes, 4 x 32 byte cache blocks).
>>
>> These four blocks all map to the same set: they have the same six
>> bits in the "cache set" part of the address.
>>
>> So if a thread is accessing something in all four blocks, it will
>> completely use that cache set, all by itself.
>>
>> If any other thread has a similar block in its stack, with the same
>> cache set ID, it will cause evictions against this thread.
>>
>> Sure, if each of these threads confines itself to working with just one
>> cacheline-sized aperture of the stack, it looks better.
>>
>> You're forgetting that the sets are very small and that groups of
>> adjacent four 32 byte blocks map to the same set. Touch four adjacent
>> cache blocks that are aligned on a 128 byte boundary, and you have
>> hit full occupancy in the cache set corresponding to that block!
>>
>> (I suspect the references to 64K should not be kilobytes but sets.
>> The 8K cache has 64 sets.)
>>
>> In memory, 128 byte blocks that is aligned maps to, and precisely covers
>> a cache set. If two such blocks addresses that are equal modulo 8K, they
>> collide to the same cache set. If one of those blocks is fully present
>> in the cache, the other must be fully evicted.
>>
>> It's really easy to see how things can go south under hyperthreading.
>> If two hyperthreads are working with clashing 128 byte areas that each
>> want to hog the same cache set, and the core is switching between them
>> on a fine-grained basis, ...  you get the picture.
>>
>> It's very easy for the memory mapping allocations used for thread
>> stacks to produce addresses such tha the delta between them is a
>> multiple of 8K.
>>
>
>
> Of course it's easy to intentionally provoke frequent aliasing
> with the P4's L1 cache, but actually this doesn't happen often.

Fwiw, some people were complaining about bad performance using
hyperthreading. Turning it off in bios improved performance. Hence the
paper was written to show them how to vastly improve performance when
hyperthreading was turned on. You call it nerd stuff, and I still cannot
figure out why?

On 1/6/2024 1:15 PM, Chris M. Thomasson wrote:
> On 1/6/2024 1:30 AM, Bonita Montero wrote:
>> Am 06.01.2024 um 09:31 schrieb Kaz Kylheku:
>>> On 2024-01-06, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> Am 06.01.2024 um 04:21 schrieb Chris M. Thomasson:
>>>>
>>>>> Are you trying to tell me that the aliasing problem on those older
>>>>> Intel
>>>>> hyperthreaded processors and the workaround (from Intel) was a myth?
>>>>> lol. ;^)
>>>>
>>>> Intel just made a nerd-suggestion. With four-way associativity
>>>> there's no frequent aliasing problem in the L1 data dache of
>>>> Pentium 4.
>>>
>>> I think the L1 cache was 8K on that thing, and the blocks are 32 bytes.
>>>
>>> I think how it works on the P4 is that the address is structured is like
>>> this:
>>>
>>>   31          11 10                5 4                                0
>>>   |            | |                 | |                                |
>>>   [ 21 bit tag ] [ 6 bit cache set ] [ 5 bit offset into 32 bit block ]
>>>
>>> Thus say we have an area of the stack with the address
>>> range nnnnFF80 to nnnnFFFF (128 bytes, 4 x 32 byte cache blocks).
>>>
>>> These four blocks all map to the same set: they have the same six
>>> bits in the "cache set" part of the address.
>>>
>>> So if a thread is accessing something in all four blocks, it will
>>> completely use that cache set, all by itself.
>>>
>>> If any other thread has a similar block in its stack, with the same
>>> cache set ID, it will cause evictions against this thread.
>>>
>>> Sure, if each of these threads confines itself to working with just one
>>> cacheline-sized aperture of the stack, it looks better.
>>>
>>> You're forgetting that the sets are very small and that groups of
>>> adjacent four 32 byte blocks map to the same set. Touch four adjacent
>>> cache blocks that are aligned on a 128 byte boundary, and you have
>>> hit full occupancy in the cache set corresponding to that block!
>>>
>>> (I suspect the references to 64K should not be kilobytes but sets.
>>> The 8K cache has 64 sets.)
>>>
>>> In memory, 128 byte blocks that is aligned maps to, and precisely covers
>>> a cache set. If two such blocks addresses that are equal modulo 8K, they
>>> collide to the same cache set. If one of those blocks is fully present
>>> in the cache, the other must be fully evicted.
>>>
>>> It's really easy to see how things can go south under hyperthreading.
>>> If two hyperthreads are working with clashing 128 byte areas that each
>>> want to hog the same cache set, and the core is switching between them
>>> on a fine-grained basis, ...  you get the picture.
>>>
>>> It's very easy for the memory mapping allocations used for thread
>>> stacks to produce addresses such tha the delta between them is a
>>> multiple of 8K.
>>>
>>
>>
>> Of course it's easy to intentionally provoke frequent aliasing
>> with the P4's L1 cache, but actually this doesn't happen often.
>
> Fwiw, some people were complaining about bad performance using
> hyperthreading. Turning it off in bios improved performance. Hence the
> paper was written to show them how to vastly improve performance when
> hyperthreading was turned on. You call it nerd stuff, and I still cannot
> figure out why?

Humm... I can see it know. Bonita works for Intel and received the
complaints... Bonita says shut up you stupid nerds! Humm... ;^o

Am 06.01.2024 um 22:15 schrieb Chris M. Thomasson:

> Fwiw, some people were complaining about bad performance using
> hyperthreading. Turning it off in bios improved performance.
> Hence the paper was written to show them how to vastly improve
> performance when hyperthreading was turned on. You call it nerd
> stuff, and I still cannot figure out why?

We were talking about mutual cache flushing and you don't kow
that this was the issue with switching of hyperthreading.

Am 06.01.2024 um 22:19 schrieb Chris M. Thomasson:

> Humm... I can see it know. Bonita works for Intel and received the
> complaints... Bonita says shut up you stupid nerds! Humm... ;^o

Intel made a number of bad decisions with the Pentium 4 that the
architecture was dropped and replaced with a descendant of Pentium
3, whose descendants are still in current Intel CPUs today. In this
respect, not only was the architecture bad, but also the documenta-
tion, because it is certainly very rare that moving the stack of a
thread when threads are running synchronously is of any use.

On 1/7/2024 1:10 AM, Bonita Montero wrote:
> Am 06.01.2024 um 22:15 schrieb Chris M. Thomasson:
>
>> Fwiw, some people were complaining about bad performance using
>> hyperthreading. Turning it off in bios improved performance.
>> Hence the  paper was written to show them how to vastly improve
>> performance when  hyperthreading was turned on. You call it nerd
>> stuff, and I still cannot figure out why?
>
> We were talking about mutual cache flushing and you don't kow
> that this was the issue with switching of hyperthreading.
>
>

I know that they had a problem and the provided workaround from Intel
really did help out. I find it amusing that you are trying to tell me
that this is all nerd stuff, as if it does not mean anything. Oh well.

Am 07.01.2024 um 21:46 schrieb Chris M. Thomasson:

> I know that they had a problem and the provided workaround from Intel
> really did help out. ...

Absolutely not, not with four way associativity.