Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #118619 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2024-03-29 14:14 +0100 |
| Last post | 2024-04-04 19:56 -0700 |
| Articles | 11 on this page of 71 — 5 participants |
Back to article view | Back to comp.lang.c++
C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-29 14:14 +0100
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-29 15:28 -0700
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-29 15:30 -0700
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-29 16:29 -0700
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-29 19:46 -0700
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-30 09:25 +0100
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-30 11:51 -0700
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-30 12:02 -0700
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-30 21:18 +0100
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-31 13:11 -0700
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-01 08:32 +0200
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-31 23:40 -0700
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-01 10:57 +0200
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-01 11:01 +0200
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-01 12:27 -0700
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-02 04:37 +0200
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-12 14:16 -0700
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-13 03:00 +0200
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-13 12:26 -0700
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-14 06:19 +0200
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-13 21:26 -0700
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-14 06:30 +0200
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-14 06:34 +0200
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-13 22:21 -0700
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-13 22:21 -0700
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-13 22:22 -0700
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-14 07:30 +0200
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-13 22:32 -0700
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-14 07:36 +0200
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-13 22:42 -0700
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-14 07:46 +0200
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-13 22:48 -0700
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-14 11:25 +0200
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-14 15:12 +0200
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-14 12:02 -0700
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-14 12:06 -0700
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-14 22:57 +0200
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-14 20:23 -0700
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-14 20:26 -0700
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-15 06:15 +0200
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-14 22:03 -0700
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-15 08:20 +0200
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-15 12:08 -0700
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-16 06:32 +0200
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-16 11:31 +0200
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-16 14:07 -0700
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-17 10:24 +0200
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-17 11:48 -0700
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-17 11:52 -0700
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-16 14:14 -0700
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-18 15:12 +0200
Re: C++20 futex with heavy contention slower than mutex Richard Damon <richard@damon-family.org> - 2024-04-18 22:03 -0400
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-19 06:18 +0200
Re: C++20 futex with heavy contention slower than mutex scott@slp53.sl.home (Scott Lurndal) - 2024-04-19 13:41 +0000
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-19 15:44 +0200
Re: C++20 futex with heavy contention slower than mutex scott@slp53.sl.home (Scott Lurndal) - 2024-04-19 14:48 +0000
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-19 17:32 +0200
Re: C++20 futex with heavy contention slower than mutex scott@slp53.sl.home (Scott Lurndal) - 2024-04-19 18:27 +0000
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-20 04:48 +0200
Re: C++20 futex with heavy contention slower than mutex scott@slp53.sl.home (Scott Lurndal) - 2024-04-20 15:16 +0000
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-20 17:36 +0200
Re: C++20 futex with heavy contention slower than mutex Richard Damon <richard@damon-family.org> - 2024-04-19 23:00 -0400
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-20 06:11 +0200
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-14 12:10 -0700
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-13 22:46 -0700
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-31 22:01 -0700
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-31 22:02 -0700
Re: C++20 futex with heavy contention slower than mutex Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-30 05:18 +0100
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-30 12:00 -0700
Re: C++20 futex with heavy contention slower than mutex Michael S <already5chosen@yahoo.com> - 2024-04-01 12:18 +0300
Re: C++20 futex with heavy contention slower than mutex "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-04 19:56 -0700
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-04-20 17:36 +0200 |
| Message-ID | <v00ne3$3o4ii$1@raubtier-asyl.eternal-september.org> |
| In reply to | #118812 |
Am 20.04.2024 um 17:16 schrieb Scott Lurndal: > It seems clear that the thread within userspace is completely > invisible to the kernel, thus it cannot by definition switch to it. I'm not talking about userlevel-threads but the state when a thread is in userspace-state. You lack imagination since you don't understand my idea.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-04-19 23:00 -0400 |
| Message-ID | <uvvb42$1kece$7@i2pn2.org> |
| In reply to | #118796 |
On 4/19/24 12:18 AM, Bonita Montero wrote: > Am 19.04.2024 um 04:03 schrieb Richard Damon: > >> How do you "signal" a user-thread without doing a kernel operation >> and a thread switch? > > The signals for the involuntary userspace thread-switch would be sent > by a dedicated kernel-thread or by the timer interrupt. This would be > more expensive than a thread-switch through the timer interrupt but > as voluntary thread-switches have a much higher frequency this would > be outweighed. TO WHAT? Are you going to reserve a core with a dedicated thread to do this? To "interrupt" a user thread to notify it, you would either need to perform a context switch to save the threads previous context or make the interrupt non-returnable. If you are going to context switch to the notification thread, you might as well switch the the new user-thread that you want to go to. > >> Admittedly, if the kernel knows it is switching from one thread >> to another in the same process it can do a lighter weight sort of >> context-switch, but it still needs to deal with kernel space operations. > > A context switch through the kernel is always expensive. A user > -level thread switch when blocking for a lock would be much faster. But you still had the kernal doing a context switch.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-04-20 06:11 +0200 |
| Message-ID | <uvvfa8$3fc0v$1@raubtier-asyl.eternal-september.org> |
| In reply to | #118803 |
Am 20.04.2024 um 05:00 schrieb Richard Damon: > On 4/19/24 12:18 AM, Bonita Montero wrote: >> Am 19.04.2024 um 04:03 schrieb Richard Damon: >> >>> How do you "signal" a user-thread without doing a kernel operation >>> and a thread switch? >> >> The signals for the involuntary userspace thread-switch would be sent >> by a dedicated kernel-thread or by the timer interrupt. This would be >> more expensive than a thread-switch through the timer interrupt but >> as voluntary thread-switches have a much higher frequency this would >> be outweighed. > > TO WHAT? > > Are you going to reserve a core with a dedicated thread to do this? A userspace thread is scheduled on a core if there's no other thread on that core. But if there would be other threads eligible to run on the core they would be scheduled by a signal in userspace if their context is also in userspace. > To "interrupt" a user thread to notify it, you would either need to > perform a context switch to save the threads previous context or make > the interrupt non-returnable. If you are going to context switch to the > notification thread, you might as well switch the the new user-thread > that you want to go to. You simply don't understand my idea !
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-04-14 12:10 -0700 |
| Message-ID | <uvh9mr$3pep9$5@dont-email.me> |
| In reply to | #118775 |
On 4/14/2024 6:12 AM, Bonita Montero wrote:
> That's my code:
>
[...]
> atomic_int lockState( 0 );
> bench( "Chris' mutex", [&]
> {
> if( lockState.exchange( 1, memory_order_acquire ) )
> while( lockState.exchange( 2, memory_order_acquire ) )
> lockState.wait( 2, memory_order_acquire );
No need for memory_order_acquire on the wait. Relaxed will do.
> if( lockState.exchange( 0, memory_order_release ) == 2 )
> lockState.notify_one();
> } );
> sort( results.begin(), results.end(), []( kv &lhs, kv &rhs ) {
> return lhs.second < rhs.second; } );
> for( kv &result : results )
> cout << result.first << ": " << result.second << endl;
> }
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-04-13 22:46 -0700 |
| Message-ID | <uvfqjp$3fnnk$7@dont-email.me> |
| In reply to | #118770 |
On 4/13/2024 10:42 PM, Chris M. Thomasson wrote: > On 4/13/2024 10:36 PM, Bonita Montero wrote: >> Am 14.04.2024 um 07:32 schrieb Chris M. Thomasson: > [...] >>> I did. Read again, well Windows Futex: >>> >>> https://groups.google.com/g/comp.lang.c++/c/1MZvhswJ6DQ/m/qyaYH-i0CgAJ >>> >>> Do you really want me to port this to c++20? >> >> Show it here with correct formatting. >> > > Do you mean, indentation? ;^) > > Anyway, you commented in the thread I linked you to. > > So, you can read my code, right? I use the explicit Windows API for a futex. Think of: https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitonaddress ;^)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-03-31 22:01 -0700 |
| Message-ID | <uudf43$2aa29$1@dont-email.me> |
| In reply to | #118638 |
On 3/30/2024 11:51 AM, Chris M. Thomasson wrote:
> On 3/30/2024 1:25 AM, Bonita Montero wrote:
>> {
>> for( bool cmp; !futex.compare_exchange_weak( cmp =
>> false, true, memory_order_acquire, memory_order_relaxed ); )
>> futex.wait( true, memory_order_relaxed );
>> futex.store( false, memory_order_release );
>> futex.notify_one();
>> }, futexTimes );
>
>
> You need to introduce some sort of waitbit logic to minimize calls to
> futex.notify_one() and futex.wait(). I posted an example but am having a
> hard time finding the damn thing in comp.lang.c++. I will try to find it.
Also, does notify_one automatically imply release semantics?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-03-31 22:02 -0700 |
| Message-ID | <uudf50$2aa29$2@dont-email.me> |
| In reply to | #118644 |
On 3/31/2024 10:01 PM, Chris M. Thomasson wrote:
> On 3/30/2024 11:51 AM, Chris M. Thomasson wrote:
>> On 3/30/2024 1:25 AM, Bonita Montero wrote:
>>> {
>>> for( bool cmp; !futex.compare_exchange_weak( cmp =
>>> false, true, memory_order_acquire, memory_order_relaxed ); )
>>> futex.wait( true, memory_order_relaxed );
>>> futex.store( false, memory_order_release );
>>> futex.notify_one();
>>> }, futexTimes );
>>
>>
>> You need to introduce some sort of waitbit logic to minimize calls to
>> futex.notify_one() and futex.wait(). I posted an example but am having
>> a hard time finding the damn thing in comp.lang.c++. I will try to
>> find it.
>
> Also, does notify_one automatically imply release semantics?
I don't think so, humm. Cannot remember.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-03-30 05:18 +0100 |
| Message-ID | <uu83qp$pv7s$1@raubtier-asyl.eternal-september.org> |
| In reply to | #118625 |
Am 29.03.2024 um 23:28 schrieb Chris M. Thomasson: > On 3/29/2024 6:14 AM, Bonita Montero wrote: >> The following program simulates constant locking und unlocking of one >> to jthread::hardware_concurrency() threadas with a std::mutex and a >> futex. On my 16 core / 32 thread Zen4 system a futex is faster up to >> 5 threads constantly contending, but beyond the CPU time of the futex >> explodes and the conventional mutex is faster with Windows as and with >> Linux. > [...] > > A futex is not a mutex! > You can build a mutex on top of a futex and that's the typical usage.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-03-30 12:00 -0700 |
| Message-ID | <uu9ngf$15kid$1@dont-email.me> |
| In reply to | #118619 |
On 3/29/2024 6:14 AM, Bonita Montero wrote:
> The following program simulates constant locking und unlocking of one
> to jthread::hardware_concurrency() threadas with a std::mutex and a
> futex. On my 16 core / 32 thread Zen4 system a futex is faster up to
> 5 threads constantly contending, but beyond the CPU time of the futex
> explodes and the conventional mutex is faster with Windows as and with
> Linux.
[...]
I think I found my highly experimental windows futex based mutex:
https://groups.google.com/g/comp.lang.c++/c/1MZvhswJ6DQ/m/qyaYH-i0CgAJ
(read all to refresh the context... ;^)
Notice:
___________________
void unlock()
{
if (InterlockedExchange(&m_state, 0) == 2)
{
WakeByAddressSingle(&m_state);
}
}
___________________
We only signal when we have to!
copy and paste from the link. Sorry about the copy and paste destroying
all of my indentation, argh!
Can you run this Bonita? Fwiw, it would be my first time using a Windows
Futex! lol:
______________________________________
#include <iostream>
#include <thread>
#include <functional>
#define WIN32_LEAN_AND_MEAN
#include <Windows.h>
#define CT_L2_ALIGNMENT 128
#define CT_THREADS 32
#define CT_ITERS 6666666
struct ct_futex_mutex
{
ULONG alignas(CT_L2_ALIGNMENT) m_state;
ct_futex_mutex() : m_state(0)
{
}
void lock()
{
if (InterlockedExchange(&m_state, 1))
{
while (InterlockedExchange(&m_state, 2))
{
ULONG cmp = 2;
WaitOnAddress(&m_state, &cmp, sizeof(ULONG), INFINITE);
}
}
}
void unlock()
{
if (InterlockedExchange(&m_state, 0) == 2)
{
WakeByAddressSingle(&m_state);
}
}
};
struct ct_shared
{
ct_futex_mutex m_mtx;
unsigned long m_count;
ct_shared() : m_count(0) {}
~ct_shared()
{
if (m_count != 0)
{
std::cout << "counter is totally fubar!\n";
}
}
};
void ct_thread(ct_shared& shared)
{
for (unsigned long i = 0; i < CT_ITERS; ++i)
{
shared.m_mtx.lock();
++shared.m_count;
shared.m_mtx.unlock();
shared.m_mtx.lock();
--shared.m_count;
shared.m_mtx.unlock();
}
}
int main()
{
std::thread threads[CT_THREADS];
std::cout << "Starting up...\n";
{
ct_shared shared;
for (unsigned long i = 0; i < CT_THREADS; ++i)
{
threads[i] = std::thread(ct_thread, std::ref(shared));
}
std::cout << "Running...\n";
for (unsigned long i = 0; i < CT_THREADS; ++i)
{
threads[i].join();
}
}
std::cout << "Completed!\n";
return 0;
}
______________________________________
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-04-01 12:18 +0300 |
| Message-ID | <20240401121800.00000d25@yahoo.com> |
| In reply to | #118619 |
On Fri, 29 Mar 2024 14:14:11 +0100 Bonita Montero <Bonita.Montero@gmail.com> wrote: > The following program simulates constant locking und unlocking of one > to jthread::hardware_concurrency() threadas with a std::mutex and a > futex. On my 16 core / 32 thread Zen4 system a futex is faster up to > 5 threads constantly contending, but beyond the CPU time of the futex > explodes and the conventional mutex is faster with Windows as and with > Linux. > In case of heavy contention what to consider 'faster' is not at all obvious. On lightly loaded system with more cores than work to do (a typical client) 'faster' means faster forward progress of group of contending threads. Achieved by very long polling before switching to wait, probably up to several tens of usec and by hyperactive tickless OS scheduler. On heavily loaded system with much more work to do than available cores, 'faster' means more work done by unrelated threads and processes. Achieved by very short polling before switching to wait, probably less than 500 nsec and by 'passive' OS scheduler that rarely intervenes outside of clock tick. And of course there are cases in the middle. And then traditional HPC with MPI that is completely different kettle of fish.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-04-04 19:56 -0700 |
| Message-ID | <uunp8e$14n67$1@dont-email.me> |
| In reply to | #118650 |
On 4/1/2024 2:18 AM, Michael S wrote: > On Fri, 29 Mar 2024 14:14:11 +0100 > Bonita Montero <Bonita.Montero@gmail.com> wrote: > >> The following program simulates constant locking und unlocking of one >> to jthread::hardware_concurrency() threadas with a std::mutex and a >> futex. On my 16 core / 32 thread Zen4 system a futex is faster up to >> 5 threads constantly contending, but beyond the CPU time of the futex >> explodes and the conventional mutex is faster with Windows as and with >> Linux. >> > > In case of heavy contention what to consider 'faster' is not at all > obvious. > > On lightly loaded system with more cores than work to do (a typical > client) 'faster' means faster forward progress of group of contending > threads. Achieved by very long polling before switching to wait, > probably up to several tens of usec and by hyperactive tickless OS > scheduler. > > On heavily loaded system with much more work to do than available > cores, 'faster' means more work done by unrelated threads and processes. > Achieved by very short polling before switching to wait, probably less > than 500 nsec and by 'passive' OS scheduler that rarely intervenes > outside of clock tick. > > And of course there are cases in the middle. > > And then traditional HPC with MPI that is completely different kettle of > fish. > Ditto. However, I did find it interesting (20+ years ago) to test worst case scenarios. What happens when I blast this mutex algorithm A with artificial load vs algo B forcing it into horrible periods of radical contention. How do they handle it...
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c++
csiph-web