Date: Fri, 8 Aug 2025 18:13:42 +0200
> On 8 Aug 2025, at 17:31, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Friday, 8 August 2025 05:31:27 Pacific Daylight Time Hans Åberg via Std-
> Proposals wrote:
>> There is 9–10% overhead with std::span relative to using clang O3 in some 10
>> million random division runs of the function “div32” calling the “div”
>> function I mentioned. Somewhat less with g++ O3, but it has somewhat worse
>> absolute timings on the “without” variation.
>
> For this mailing list, all of the above is completely irrelevant.
As you snipped what I responded to, your post does not make sense:
C++ does not have multiprecision support, and the hard part is implementing division. So it would seem suitable to have support for that so that users don't have to write it over and again.
If you go back to my original post, you can see that is all I mention.
The performance issues are what others brought up, to which I responded, which indeed is a side issue.
Compiler vendors can't get this performance because they would have to do the math, and I know of no public references of what is necessary.
> Don't get me wrong: it's important to have performance improvements and we
> appreciate you've found an area that could use improvement. Your proposal also
> rests on the fact that there is performance gain to be had.
>
> But the numbers and technique are less important.
>
> What you had to do in order to benchmark your implementation isn't relevant to
> the discussion of the API. In fact, some vendors may not even be allowed to
> look at your code. As a compiler vendor, if they see an optimisation
> bottleneck in their own compiler, they can also fix it. They may have
> techniques you are not allowed to use.
>
> Your benchmark numbers are also not very important. Technology will keep
> progressing quickly, so they will be stale soon. Vendors will also have other
> constraints you didn't: they may need to target older generations or other
> architectures you haven't addressed. They may also choose to implement the
> algorithm directly in assembly for some cases, as in the case of a 128-bit
> dividend by a 64-bit divisor on x86-64, which is a single instruction.
>
> In summary, do not design your API based on your benchmarking techniques,
> limitations, or results.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Platform & System Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> On Friday, 8 August 2025 05:31:27 Pacific Daylight Time Hans Åberg via Std-
> Proposals wrote:
>> There is 9–10% overhead with std::span relative to using clang O3 in some 10
>> million random division runs of the function “div32” calling the “div”
>> function I mentioned. Somewhat less with g++ O3, but it has somewhat worse
>> absolute timings on the “without” variation.
>
> For this mailing list, all of the above is completely irrelevant.
As you snipped what I responded to, your post does not make sense:
C++ does not have multiprecision support, and the hard part is implementing division. So it would seem suitable to have support for that so that users don't have to write it over and again.
If you go back to my original post, you can see that is all I mention.
The performance issues are what others brought up, to which I responded, which indeed is a side issue.
Compiler vendors can't get this performance because they would have to do the math, and I know of no public references of what is necessary.
> Don't get me wrong: it's important to have performance improvements and we
> appreciate you've found an area that could use improvement. Your proposal also
> rests on the fact that there is performance gain to be had.
>
> But the numbers and technique are less important.
>
> What you had to do in order to benchmark your implementation isn't relevant to
> the discussion of the API. In fact, some vendors may not even be allowed to
> look at your code. As a compiler vendor, if they see an optimisation
> bottleneck in their own compiler, they can also fix it. They may have
> techniques you are not allowed to use.
>
> Your benchmark numbers are also not very important. Technology will keep
> progressing quickly, so they will be stale soon. Vendors will also have other
> constraints you didn't: they may need to target older generations or other
> architectures you haven't addressed. They may also choose to implement the
> algorithm directly in assembly for some cases, as in the case of a 128-bit
> dividend by a 64-bit divisor on x86-64, which is a single instruction.
>
> In summary, do not design your API based on your benchmarking techniques,
> limitations, or results.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Platform & System Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-08-08 16:13:57