> On 7 Aug 2025, at 23:25, Oliver Hunt <oliver_at_[hidden]> wrote:
>
>> 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).

I am just saying that I prefer doing some testing. I am seeing overheads on things that should properly be inlined.