Your concerns are legitimate. They make sense.
But let me put it in another perspective.
Let’s say that your proposal was accepted. Now we have to deal with the next step: How do we actually implement it?
You have multiple CPU architecture only x86 has a dedicated division instruction, everything else is an algorithm, and probably will kill all of the “branchless” benefits there.

But let’s focus on x86, what are the instructions that you are going to issue?
Have you actually tested this? Even though it may not actually be that trivial you can probably test this right now.
Does the cost of the alternative algorithm make it actually faster than just checking it?
You have to prove that it actually is otherwise the proposal is dead, there’s no reason to do it if it is not the case.

Come to think about. I’m going to try and come up with a benchmark for it, we can just try and test that out.
I will comeback to this later and then we can discuss if you actually have a paper.


From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of None via Std-Proposals
Sent: Wednesday, April 30, 2025 7:50 PM
To: std-proposals_at_[hidden]
Cc: None <a1343922569_at_[hidden]>
Subject: [std-proposals] 回复: 回复: Proposal: Integer division/remainder/division-remainder functions with exception throwing behavior

I believe my point still stands for the following reasons (in my opinion):
1. Regarding branch prediction and performance:
Modern CPU pipelines are typically 14-20 stages deep. When a branch prediction fails, the entire pipeline needs to be flushed and refilled, causing a significant penalty of 20-30 clock cycles. This is particularly impactful in high-performance computing scenarios.
2. About implementation efficiency:
The proposed solution leverages CPU's native division-by-zero exception mechanism, which is fundamentally different from manual checking:
    No branch instructions in the main execution path.
    Zero runtime overhead for the non-zero case (>99.9% scenarios).
    Exception handling path is completely out of line.
    Modern CPUs have dedicated hardware for exception handling.
3. On "trivial implementation":
While users can implement basic checks, they cannot efficiently utilize CPU's built-in mechanisms without non-portable assembly code. A standardized solution would:
    Provide consistent, portable behavior.
    Enable compiler optimizations impossible with user-level code.

I believe these technical merits warrant consideration for standardization. Would you be interested in more detailed analysis of these aspects?

________________________________
From: Jan Schultke <janschultke_at_[hidden]<mailto:janschultke_at_[hidden]>>
Sent: Thursday, May 1, 2025 1:35 AM
To: std-proposals_at_[hidden]<mailto:std-proposals_at_lists.isocpp.org> <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Cc: None <a1343922569_at_gmail.com<mailto:a1343922569_at_[hidden]>>
Subject: Re: [std-proposals] 回复: Proposal: Integer division/remainder/division-remainder functions with exception throwing behavior

To clarify on the second point, you can already express a division by zero check with a throw on failure using an if statement. The language already has all the tools to let you do it.

If it was much faster to handle the CPU trap instead, compilers would likely already detect this pattern and transform the branch into an unconditional division. The core language already has all the tools, so this seems more like a quality-of-implementation problem than anything.

A much more interesting proposal would be to change division by zero globally so that it throws instead of being UB. Maybe this could be a conditionally supported feature. Maybe it's something that should be implemented in a compiler first. Maybe it's already implemented somewhere, not sure.