Date: Thu, 2 Apr 2026 13:55:09 +0200
czw., 2 kwi 2026 o 13:52 Frederick Virchanza Gotham via Std-Proposals
<std-proposals_at_[hidden]> napisaĆ(a):
>
>
>
> On Thursday, April 2, 2026, Marcin Jaczewski via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>>
>> True, its has its benefits but atomic increment cost too and could
>> affect every core.
>> Looking at people who want 101% CPU and go out of their way to avoid
>> sharing cache lines between cores, seams like
>> this `big_int` will not be acceptable for them.
>> Or maybe have two ints? `big_int` and `big_int_shared`?
>
>
>
>
> Don't you mean:
>
> std::big_int
>
> and:
>
> std::atomic< std::big_int >
>
> The latter could be specialised and optimised (instead of just allowing the compiler to use a mutex).
No, atomicity of counter that is shared has nothing with atomicy of
object itself that is not shared.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
<std-proposals_at_[hidden]> napisaĆ(a):
>
>
>
> On Thursday, April 2, 2026, Marcin Jaczewski via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>>
>> True, its has its benefits but atomic increment cost too and could
>> affect every core.
>> Looking at people who want 101% CPU and go out of their way to avoid
>> sharing cache lines between cores, seams like
>> this `big_int` will not be acceptable for them.
>> Or maybe have two ints? `big_int` and `big_int_shared`?
>
>
>
>
> Don't you mean:
>
> std::big_int
>
> and:
>
> std::atomic< std::big_int >
>
> The latter could be specialised and optimised (instead of just allowing the compiler to use a mutex).
No, atomicity of counter that is shared has nothing with atomicy of
object itself that is not shared.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2026-04-02 11:55:28
