public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH 0/3] Uncontroversial improvements to C++20 wait-related implementation
@ 2021-03-22 15:29 Thiago Macieira
  2021-03-23 15:39 ` Thomas Rodgers
  0 siblings, 1 reply; 6+ messages in thread
From: Thiago Macieira @ 2021-03-22 15:29 UTC (permalink / raw)
  To: libstdc++; +Cc: gcc-patches

> Discussion at:
> https://gcc.gnu.org/pipermail/libstdc++/2021-February/052043.html
> 
> This patch set includes the uncontroversial parts that improve
> performance but don't otherwise change ABI.
> 
> Please note we still need to decide on how to deal with the future ABI
> break.
> 
> Thiago Macieira (3):
>   Atomic __platform_wait: accept any 32-bit type, not just int
>   std::latch: reduce internal implementation from ptrdiff_t to int
>   barrier: optimise by not having the hasher in a loop
>  
>  libstdc++-v3/include/bits/atomic_wait.h |  7 ++++---
>  libstdc++-v3/include/std/barrier        | 10 +++++-----
>  libstdc++-v3/include/std/latch          |  4 ++--
>  3 files changed, 11 insertions(+), 10 deletions(-)

ping?
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH 0/3] Uncontroversial improvements to C++20 wait-related implementation
  2021-03-22 15:29 [PATCH 0/3] Uncontroversial improvements to C++20 wait-related implementation Thiago Macieira
@ 2021-03-23 15:39 ` Thomas Rodgers
  2021-03-23 16:26   ` Thiago Macieira
  0 siblings, 1 reply; 6+ messages in thread
From: Thomas Rodgers @ 2021-03-23 15:39 UTC (permalink / raw)
  To: Thiago Macieira; +Cc: libstdc++, gcc-patches

On 2021-03-22 08:29, Thiago Macieira via Libstdc++ wrote:

>> Discussion at:
>> https://gcc.gnu.org/pipermail/libstdc++/2021-February/052043.html
>> 
>> This patch set includes the uncontroversial parts that improve
>> performance but don't otherwise change ABI.
>> 
>> Please note we still need to decide on how to deal with the future ABI
>> break.
>> 
>> Thiago Macieira (3):
>> Atomic __platform_wait: accept any 32-bit type, not just int
>> std::latch: reduce internal implementation from ptrdiff_t to int
>> barrier: optimise by not having the hasher in a loop
>> 
>> libstdc++-v3/include/bits/atomic_wait.h |  7 ++++---
>> libstdc++-v3/include/std/barrier        | 10 +++++-----
>> libstdc++-v3/include/std/latch          |  4 ++--
>> 3 files changed, 11 insertions(+), 10 deletions(-)
> 
> ping?

I will be submitting a new patch for the 
atomic.wait/barrier/latch/semaphore functionality a bit later today that 
subsumes the changes to atomic_wait and latch, and includes the changes 
to barrier.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH 0/3] Uncontroversial improvements to C++20 wait-related implementation
  2021-03-23 15:39 ` Thomas Rodgers
@ 2021-03-23 16:26   ` Thiago Macieira
  2021-03-23 16:35     ` Jonathan Wakely
  0 siblings, 1 reply; 6+ messages in thread
From: Thiago Macieira @ 2021-03-23 16:26 UTC (permalink / raw)
  To: Thomas Rodgers; +Cc: libstdc++, gcc-patches

On Tuesday, 23 March 2021 08:39:43 PDT Thomas Rodgers wrote:
> I will be submitting a new patch for the
> atomic.wait/barrier/latch/semaphore functionality a bit later today that
> subsumes the changes to atomic_wait and latch, and includes the changes
> to barrier.

Thanks, Thomas

Is that meant to be part of GCC 11's release?

If not, what do we do about preventing the future BC break and potential 
heisenbugs?

 1) do nothing, accept they will happen silently
 2) cause non-silent BC breaks
 3) disable the code for now (unless explicitly opted-in)

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH 0/3] Uncontroversial improvements to C++20 wait-related implementation
  2021-03-23 16:26   ` Thiago Macieira
@ 2021-03-23 16:35     ` Jonathan Wakely
  2021-03-26 23:53       ` Thomas Rodgers
  0 siblings, 1 reply; 6+ messages in thread
From: Jonathan Wakely @ 2021-03-23 16:35 UTC (permalink / raw)
  To: Thiago Macieira; +Cc: Thomas Rodgers, libstdc++, gcc-patches

On 23/03/21 09:26 -0700, Thiago Macieira via Libstdc++ wrote:
>On Tuesday, 23 March 2021 08:39:43 PDT Thomas Rodgers wrote:
>> I will be submitting a new patch for the
>> atomic.wait/barrier/latch/semaphore functionality a bit later today that
>> subsumes the changes to atomic_wait and latch, and includes the changes
>> to barrier.
>
>Thanks, Thomas
>
>Is that meant to be part of GCC 11's release?

Yes.

>If not, what do we do about preventing the future BC break and potential
>heisenbugs?
>
> 1) do nothing, accept they will happen silently

This is our current policy for experimental features and it isn't
going to change for GCC 11.


> 2) cause non-silent BC breaks
> 3) disable the code for now (unless explicitly opted-in)
>
>-- 
>Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel DPG Cloud Engineering
>
>
>


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH 0/3] Uncontroversial improvements to C++20 wait-related implementation
  2021-03-23 16:35     ` Jonathan Wakely
@ 2021-03-26 23:53       ` Thomas Rodgers
  0 siblings, 0 replies; 6+ messages in thread
From: Thomas Rodgers @ 2021-03-26 23:53 UTC (permalink / raw)
  To: Jonathan Wakely; +Cc: Thiago Macieira, libstdc++, gcc-patches

On 2021-03-23 09:35, Jonathan Wakely wrote:

> On 23/03/21 09:26 -0700, Thiago Macieira via Libstdc++ wrote: On 
> Tuesday, 23 March 2021 08:39:43 PDT Thomas Rodgers wrote: I will be 
> submitting a new patch for the
> atomic.wait/barrier/latch/semaphore functionality a bit later today 
> that
> subsumes the changes to atomic_wait and latch, and includes the changes
> to barrier.
> Thanks, Thomas
> 
> Is that meant to be part of GCC 11's release?

Yes.

> If not, what do we do about preventing the future BC break and 
> potential
> heisenbugs?
> 
> 1) do nothing, accept they will happen silently

This is our current policy for experimental features and it isn't
going to change for GCC 11.

> 2) cause non-silent BC breaks
> 3) disable the code for now (unless explicitly opted-in)
> 
> -- Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel DPG Cloud Engineering

FWIW, I would like to commit to an ABI for this with GCC12 and 
everything currently residing in the __detail namespace would be moved 
into the .so as part of that (likely with a third, and ideally final, 
rewrite).

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [PATCH 0/3] Uncontroversial improvements to C++20 wait-related implementation
@ 2021-03-05 18:21 Thiago Macieira
  0 siblings, 0 replies; 6+ messages in thread
From: Thiago Macieira @ 2021-03-05 18:21 UTC (permalink / raw)
  To: libstdc++; +Cc: gcc-patches

Discussion at:
https://gcc.gnu.org/pipermail/libstdc++/2021-February/052043.html

This patch set includes the uncontroversial parts that improve
performance but don't otherwise change ABI.

Please note we still need to decide on how to deal with the future ABI
break.

Thiago Macieira (3):
  Atomic __platform_wait: accept any 32-bit type, not just int
  std::latch: reduce internal implementation from ptrdiff_t to int
  barrier: optimise by not having the hasher in a loop

 libstdc++-v3/include/bits/atomic_wait.h |  7 ++++---
 libstdc++-v3/include/std/barrier        | 10 +++++-----
 libstdc++-v3/include/std/latch          |  4 ++--
 3 files changed, 11 insertions(+), 10 deletions(-)

-- 
2.30.1


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2021-03-26 23:53 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-22 15:29 [PATCH 0/3] Uncontroversial improvements to C++20 wait-related implementation Thiago Macieira
2021-03-23 15:39 ` Thomas Rodgers
2021-03-23 16:26   ` Thiago Macieira
2021-03-23 16:35     ` Jonathan Wakely
2021-03-26 23:53       ` Thomas Rodgers
  -- strict thread matches above, loose matches on Subject: below --
2021-03-05 18:21 Thiago Macieira

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).