Date: Tue, 25 Feb 2025 11:14:28 -0500
On Tue, Feb 25, 2025 at 1:12 AM Simon Schröder via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
>
>
> On Feb 24, 2025, at 11:02 PM, JOHN MORRISON via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>
> The motivation isn't better performance than shared_ptr but I don't want it substantially worse either. It is going to be used to optimize painting routines so they don't cause screen lag. I suspect that setting and testing locks may have more latency and there can be a lockout on the GUI thread if a lock get hit.
>
> I can confirm that this is really important in GUI programming. If you are drawing a 1000 objects on screen, you cannot acquire a lock for each of them during painting. You’ll never get a responsive UI this way.
>
> I guess the major discussion should be a meta-discussion. What do we prioritize in C++:
> * thread safety?
> * or the zero overhead principle (you don’t pay for what you don’t use)?
> Is the zero overhead principle not a major thing in C++ anymore? Does it not get trumped by the safety discussion? Is C++ not classical C++ anymore? (I don’t really know.)
If I have 1000 objects and I'm iterating through them and doing a
check to see if each one exists... that's 1000 cache misses. Even if
the `ptr_to_unique`s are all in an array, those control blocks are
almost certainly *aren't* contiguously allocated. So checking each one
is likely going to be a cache miss.
In terms of memory accesses, `weak_ptr::lock` is equivalent to that.
It does need to do atomic operations, but this is *not* a mutex lock.
So in terms of real performance, I would argue that accessing a
`ptr_to_unique` is just as expensive as locking a `weak_ptr`.
If adding safety costs you basically nothing, why be unsafe?
> This discussion about a general direction of C++ should inform the implementation of ptr_to_unique. As long as we hold to the zero overhead principle ptr_to_unique should not check if it is running in the correct thread (by default) and should definitely not use locking (by default). I already suggested to have a template parameter which can select between safety and performance. The question is then what should be the default. Should we opt out to get zero overhead? Or is zero overhead the default and we opt in to safety? Can we use profiles which change the default?
`shared_ptr` didn't have to use atomic references, but it does. If you
write a single-threaded application that uses `shared_ptr`, you are
technically paying for something you don't use.
But if you're going to have a vocabulary type, it's a *really* good
idea for it to be ironclad. And if threading is going to be a
first-class feature of the language, standard library types need to
accommodate it.
<std-proposals_at_[hidden]> wrote:
>
>
>
> On Feb 24, 2025, at 11:02 PM, JOHN MORRISON via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>
> The motivation isn't better performance than shared_ptr but I don't want it substantially worse either. It is going to be used to optimize painting routines so they don't cause screen lag. I suspect that setting and testing locks may have more latency and there can be a lockout on the GUI thread if a lock get hit.
>
> I can confirm that this is really important in GUI programming. If you are drawing a 1000 objects on screen, you cannot acquire a lock for each of them during painting. You’ll never get a responsive UI this way.
>
> I guess the major discussion should be a meta-discussion. What do we prioritize in C++:
> * thread safety?
> * or the zero overhead principle (you don’t pay for what you don’t use)?
> Is the zero overhead principle not a major thing in C++ anymore? Does it not get trumped by the safety discussion? Is C++ not classical C++ anymore? (I don’t really know.)
If I have 1000 objects and I'm iterating through them and doing a
check to see if each one exists... that's 1000 cache misses. Even if
the `ptr_to_unique`s are all in an array, those control blocks are
almost certainly *aren't* contiguously allocated. So checking each one
is likely going to be a cache miss.
In terms of memory accesses, `weak_ptr::lock` is equivalent to that.
It does need to do atomic operations, but this is *not* a mutex lock.
So in terms of real performance, I would argue that accessing a
`ptr_to_unique` is just as expensive as locking a `weak_ptr`.
If adding safety costs you basically nothing, why be unsafe?
> This discussion about a general direction of C++ should inform the implementation of ptr_to_unique. As long as we hold to the zero overhead principle ptr_to_unique should not check if it is running in the correct thread (by default) and should definitely not use locking (by default). I already suggested to have a template parameter which can select between safety and performance. The question is then what should be the default. Should we opt out to get zero overhead? Or is zero overhead the default and we opt in to safety? Can we use profiles which change the default?
`shared_ptr` didn't have to use atomic references, but it does. If you
write a single-threaded application that uses `shared_ptr`, you are
technically paying for something you don't use.
But if you're going to have a vocabulary type, it's a *really* good
idea for it to be ironclad. And if threading is going to be a
first-class feature of the language, standard library types need to
accommodate it.
Received on 2025-02-25 16:14:42