From: Thiago Macieira <thiago.macieira@intel.com>
To: libstdc++@gcc.gnu.org
Cc: gcc-patches@gcc.gnu.org
Subject: [PATCH 3/3] barrier: optimise by not having the hasher in a loop
Date: Fri, 5 Mar 2021 10:21:28 -0800 [thread overview]
Message-ID: <20210305182128.2071822-4-thiago.macieira@intel.com> (raw)
In-Reply-To: <20210305182128.2071822-1-thiago.macieira@intel.com>
Our thread's ID does not change so we don't have to get it every time
and hash it every time.
libstdc++-v3/ChangeLog:
* include/std/barrier(arrive): move hasher one level up in the
stack.
---
libstdc++-v3/include/std/barrier | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libstdc++-v3/include/std/barrier b/libstdc++-v3/include/std/barrier
index e09212dfcb9..4bb5642c164 100644
--- a/libstdc++-v3/include/std/barrier
+++ b/libstdc++-v3/include/std/barrier
@@ -94,7 +94,7 @@ It looks different from literature pseudocode for two main reasons:
alignas(__phase_alignment) __barrier_phase_t _M_phase;
bool
- _M_arrive(__barrier_phase_t __old_phase)
+ _M_arrive(__barrier_phase_t __old_phase, size_t __current)
{
const auto __old_phase_val = static_cast<unsigned char>(__old_phase);
const auto __half_step =
@@ -103,9 +103,7 @@ It looks different from literature pseudocode for two main reasons:
static_cast<__barrier_phase_t>(__old_phase_val + 2);
size_t __current_expected = _M_expected;
- std::hash<std::thread::id> __hasher;
- size_t __current = __hasher(std::this_thread::get_id())
- % ((_M_expected + 1) >> 1);
+ __current %= ((__current_expected + 1) >> 1);
for (int __round = 0; ; ++__round)
{
@@ -163,12 +161,14 @@ It looks different from literature pseudocode for two main reasons:
[[nodiscard]] arrival_token
arrive(ptrdiff_t __update)
{
+ std::hash<std::thread::id> __hasher;
+ size_t __current = __hasher(std::this_thread::get_id());
__atomic_phase_ref_t __phase(_M_phase);
const auto __old_phase = __phase.load(memory_order_relaxed);
const auto __cur = static_cast<unsigned char>(__old_phase);
for(; __update; --__update)
{
- if(_M_arrive(__old_phase))
+ if(_M_arrive(__old_phase, __current))
{
_M_completion();
_M_expected += _M_expected_adjustment.load(memory_order_relaxed);
--
2.30.1
prev parent reply other threads:[~2021-03-05 18:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-05 18:21 [PATCH 0/3] Uncontroversial improvements to C++20 wait-related implementation Thiago Macieira
2021-03-05 18:21 ` [PATCH 1/3] Atomic __platform_wait: accept any 32-bit type, not just int Thiago Macieira
2021-03-05 18:21 ` [PATCH 2/3] std::latch: reduce internal implementation from ptrdiff_t to int Thiago Macieira
2021-03-05 18:21 ` Thiago Macieira [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210305182128.2071822-4-thiago.macieira@intel.com \
--to=thiago.macieira@intel.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=libstdc++@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).