mitchalsup@aol.com (MitchAlsup) writes:
>Chris M. Thomasson wrote:
>
>> On 11/25/2023 3:33 PM, Chris M. Thomasson wrote:
>>> On 11/25/2023 9:05 AM, Scott Lurndal wrote:
>>>>
>>>>
>>>> Clearly 1000 processors beating on the same cache line is
>>>> something to be avoided.   There still seem to be a dearth
>>>> of programmers that understand multithreaded programming.
>>>
>>> 1000 processors requires a distributed setup wrt NUMA. For instance, an
>>> amortized multi-queue that knows about locality tends to work rather
>>> well. The queue is distributed out where its unlikely that two
>>> processors might contend on the same thing in the queue logic.
>
>> If a processor obtains some work from the "queue" API (FIFO is not
>> guaranteed here.... ;^o), its highly likely that it is fairly local
>> work, close to "it" wrt the calling processor, wrt the physical layout
>> of the arch...
>
>When you have 1000 processors, and the number of cycles it takes

If you have a 1000 processors, you craft your workload to avoid
synchronization contention to the greatest extent possible. Any
workload with 1000 threads accessing a single resource is
fundamentally broken.

As for 'transactions', the problem with them isn't really hardware
support, or the size or number of discreet elements in the transaction,
it's how to leverage that capability from the standard languages like C,
C++, Rust or Carbon. Nobody programs in assembler any more, even
on microprocessors.

On 12/27/2023 9:21 AM, MitchAlsup wrote:
> Chris M. Thomasson wrote:
>
>> On 11/25/2023 3:33 PM, Chris M. Thomasson wrote:
>>> On 11/25/2023 9:05 AM, Scott Lurndal wrote:
>>>>
>>>>
>>>> Clearly 1000 processors beating on the same cache line is
>>>> something to be avoided.   There still seem to be a dearth
>>>> of programmers that understand multithreaded programming.
>>>
>>> 1000 processors requires a distributed setup wrt NUMA. For instance,
>>> an amortized multi-queue that knows about locality tends to work
>>> rather well. The queue is distributed out where its unlikely that two
>>> processors might contend on the same thing in the queue logic.
>
>> If a processor obtains some work from the "queue" API (FIFO is not
>> guaranteed here.... ;^o), its highly likely that it is fairly local
>> work, close to "it" wrt the calling processor, wrt the physical layout
>> of the arch...
>
> When you have 1000 processors, and the number of cycles it takes
> to perform a synchronization is 100-cycles, you need the synchron-
> ization to hand off enough work so that the winner has enough
> cycles of computation before another synchronization to allow
> all other processors to obtain work.

Agreed. Hummmmm...... I think, the little test of my xchg based "queue",
thing, just might do that in and of itself. I just need to port it 100%
pure C++11 so everybody can give it a run, as of now it is coded up in a
Relacy unit test:

https://groups.google.com/g/comp.arch/c/MarXjOpSmRM

>
>> Hummm, I need to start another thread on something related.

On 12/27/2023 1:12 PM, Chris M. Thomasson wrote:
> On 12/27/2023 9:21 AM, MitchAlsup wrote:
>> Chris M. Thomasson wrote:
>>
>>> On 11/25/2023 3:33 PM, Chris M. Thomasson wrote:
>>>> On 11/25/2023 9:05 AM, Scott Lurndal wrote:
>>>>>
>>>>>
>>>>> Clearly 1000 processors beating on the same cache line is
>>>>> something to be avoided.   There still seem to be a dearth
>>>>> of programmers that understand multithreaded programming.
>>>>
>>>> 1000 processors requires a distributed setup wrt NUMA. For instance,
>>>> an amortized multi-queue that knows about locality tends to work
>>>> rather well. The queue is distributed out where its unlikely that
>>>> two processors might contend on the same thing in the queue logic.
>>
>>> If a processor obtains some work from the "queue" API (FIFO is not
>>> guaranteed here.... ;^o), its highly likely that it is fairly local
>>> work, close to "it" wrt the calling processor, wrt the physical
>>> layout of the arch...
>>
>> When you have 1000 processors, and the number of cycles it takes
>> to perform a synchronization is 100-cycles, you need the synchron-
>> ization to hand off enough work so that the winner has enough
>> cycles of computation before another synchronization to allow
>> all other processors to obtain work.
>
> Agreed. Hummmmm...... I think, the little test of my xchg based "queue",
> thing, just might do that in and of itself. I just need to port it 100%
> pure C++11 so everybody can give it a run, as of now it is coded up in a
> Relacy unit test:
>
> https://groups.google.com/g/comp.arch/c/MarXjOpSmRM

When you get some free time to burn, take notice of how it can detect
local work vs foreign work...

>
>
>
>>
>>> Hummm, I need to start another thread on something related.
>

On 12/27/23 12:50 PM, Scott Lurndal wrote:
[snip]
> As for 'transactions', the problem with them isn't really hardware
> support, or the size or number of discreet elements in the transaction,
> it's how to leverage that capability from the standard languages like C,
> C++, Rust or Carbon. Nobody programs in assembler any more, even
> on microprocessors.

Translating locked critical sections into transactions would seem
likely to be possible.

*If* _all_ uses of a lock can _always_ use the transaction
mechanism, the lock mechanism can be removed (theoretically).
Otherwise, the lock would have to be checked at the beginning of
each transaction (adding it to the read set) so that a thread not
using the transaction mechanism (because it does not work) can
still be atomic by using the lock.

A higher level language might provide named critical sections (for
single-structure guarding, a reference to the structure might be a
name) where the compiler might implement the name-based guarding
with locking or transactions (or both).

An even higher level language might have the compiler do *all* the
hard analysis of removing data races. This is "merely" a form of
compiler autoparallelization.☺ (I do not see this happening any
time soon. I would also argue that such is inefficient in that it
will often be rediscovering information that was available or more
easily discovered in an earlier phase of software development.)

There are probably other language designs for addressing data
races. For memory management, Rust (from the little I have read)
introduced an interface that avoids the correctness issues of
manual memory management while avoiding some of the issues with
traditional garbage collection (including reference counting). I
have read even less about Rust's parallelism support, but I
suspect such was both integrated with the memory management (one
would expect a new language to have more elegance) and
philosophically similar (emphasizing correctness and execution
efficiency).

Versioning seems to present opportunities for parallelism beyond
what is provided by simply implemented atomicity (exploiting an
"as if" rule), so language development might be advised to account
for that possibility.

There are also cases where strict ordering is not important; fire-
and-forget atomics are a small-scale example. There might be a
clever interface that distinguishes such without being a burden to
the programmer; not using the returned value (locally) would seem
to allow the compiler to translate to a fire-and-forget, but that
_feels_ lacking as an interface. (Strict ordering is a mechanism
to provide data model consistency; data model consistency does not
_require_ strict ordering. Of course, reasoning about a
communication pattern becomes problematically difficult as
complexity increases.)

(There may also be cases where a data-dependent condition might be
needed rather than the data itself. A debit card transaction does
not care so much about the account balance but whether the balance
is sufficient to cover the transaction. For a single bound value,
a remote atomic add conditional on the bound might be practical to
implement in hardware (a biased representation could have this
value as zero); I am skeptical that such would be worthwhile.)

I am not sure how speculative multithreading would fit here.

Even more extreme, support for approximate (and stochastic)
computing might be desirable.

Blah, blah, blah.☹