Date: Thu, 07 Aug 2025 14:25:48 -0700
> On Aug 7, 2025, at 2:03 PM, Hans Åberg <haberg_1_at_[hidden]> wrote:
>
>
>> On 7 Aug 2025, at 22:21, Oliver Hunt <oliver_at_[hidden]> wrote:
>>
>> As a simple example I made a terrible multi precision add, and there’s no difference in codegen between the array and the std::span version:
>
> On this low level, everything causes an overhead: array computations, loops, jumps, multiplications, size of words, etc.
>
>
You are making the claim that std::span introduces overhead that is not present if the API uses raw pointers.
I just provided you an example showing that the code generation is _identical_.
Rather than just saying “everything causes overhead”, you need to provide evidence that that is the case.
Otherwise this feels like a premature optimization that may not actually be necessary, while at the same
time directly inhibiting many memory safety and hardening features.
If the context of “everything causes overhead” I could point to the problem of reverse iteration: for most CPU
architectures (especially older or lower end ones) the load predictors generally assume forward iteration of
memory, so doing a high to low walk through the array would in principle be slower (I believe most newer or
high end processors detect reverse iteration at this point, but forward iteration is universally supported).
—Oliver
>
>
>> On 7 Aug 2025, at 22:21, Oliver Hunt <oliver_at_[hidden]> wrote:
>>
>> As a simple example I made a terrible multi precision add, and there’s no difference in codegen between the array and the std::span version:
>
> On this low level, everything causes an overhead: array computations, loops, jumps, multiplications, size of words, etc.
>
>
You are making the claim that std::span introduces overhead that is not present if the API uses raw pointers.
I just provided you an example showing that the code generation is _identical_.
Rather than just saying “everything causes overhead”, you need to provide evidence that that is the case.
Otherwise this feels like a premature optimization that may not actually be necessary, while at the same
time directly inhibiting many memory safety and hardening features.
If the context of “everything causes overhead” I could point to the problem of reverse iteration: for most CPU
architectures (especially older or lower end ones) the load predictors generally assume forward iteration of
memory, so doing a high to low walk through the array would in principle be slower (I believe most newer or
high end processors detect reverse iteration at this point, but forward iteration is universally supported).
—Oliver
Received on 2025-08-07 21:26:00