On Tuesday, 1 March 2022 at 07:50:27 UTC, forkit wrote:
> On Tuesday, 1 March 2022 at 06:57:26 UTC, forkit wrote:
>> On Monday, 28 February 2022 at 20:33:17 UTC, Walter Bright
>
> We need to refocus on why exception handling was introduced, and not just on it's 'cost'.

+1000

The counter-hype of being anti-exceptions is even worse than being anti-OOP...
10% facts and 90% cyclical hype

On Tuesday, 1 March 2022 at 05:06:22 UTC, Elronnd wrote:
> On Tuesday, 1 March 2022 at 01:39:05 UTC, deadalnix wrote:
>> obj can be kept in a register in the goto case, it cannot in the exception case. So you'll have a couple extra load/store vs extra branches.
>
> Nope, it can be kept in a register in the exception case too.  See: https://godbolt.org/z/zP1P3xvr3
>
> The pushes and pops of RBX are necessary in both cases, because it is a caller-saved register.  (And, well, they are also necessary for stack alignment, so be wary of taking too many conclusions from a microbenchmark.)  Beyond that, note that the exception-using versions have fewer instructions in the hot path, fewer branches, and exactly the same number of memory accesses as the manually-checking versions.
>
> (GCC generates better code, but clang's implementation of 'h' is more representative, which is why I show both; *usually* you can't run both the happy path and the sad path branchlessly.)

I'm not sure that gcc's code is actually better, it's pretty much the same, with the cold section split out. The only notable difference in is to use add/mov vs lea for gcc.

Interestingly, i submitted a patch to split exception code in cold section for LLVM the way GCC does it, but it ended up not being merged :/

In any case, your example show that even in the presence of exception, register promotion is still possible, which I think strengthen my original point: of all the solutions available, exception are the one that imposes the smallest cost on the non exception path.

On Tuesday, 1 March 2022 at 06:50:54 UTC, Araq wrote:
> On Tuesday, 1 March 2022 at 06:44:05 UTC, H. S. Teoh wrote:
>> If error codes are somehow fundamentally more efficient, why can't the compiler just rewrite throwing functions into functions that return error codes, with the compiler inserting error code checks into the caller as needed?
>
> Exactly. It's entirely feasible. And it is what Swift does: https://www.mikeash.com/pyblog/friday-qa-2017-08-25-swift-error-handling-implementation.html
>
> (It's not universally faster than table based exceptions but it seems preferable for embedded devices.)

Yes, this is doable and indeed done in some cases. The main benefit is that the resulting binaries are smaller, which is important on embeded devices.

Exceptions handling typically causes a ~20% increase of the binaries.

Another benefit is that it is much cheaper in the exceptional case. The flip side of this is that it imposes a greater cost in the non throwing case.

On Tuesday, 1 March 2022 at 12:51:08 UTC, deadalnix wrote:
> I'm not sure that gcc's code is actually better, it's pretty much the same, with the cold section split out. The only notable difference in is to use add/mov vs lea for gcc.

Yes:

1. hot/cold splitting

2. lea vs add/mov (marginal, but still smaller)

3. branchless h

I think all of these qualify gcc's code as better.

> Interestingly, i submitted a patch to split exception code in cold section for LLVM the way GCC does it, but it ended up not being merged :/

Curious, why not?

On Tuesday, 1 March 2022 at 19:20:04 UTC, Elronnd wrote:
>> Interestingly, i submitted a patch to split exception code in cold section for LLVM the way GCC does it, but it ended up not being merged :/
>
> Curious, why not?

The perf benefits weren't so obvious expect for huge binaries. Huge binaries ended up being optimizable in other ways, such as bolt, PGO+LTO and the benefit wasn't so obvious in the end.

On Tuesday, 1 March 2022 at 12:13:51 UTC, meta wrote:
>
> ... Also my use cases for D are system level softwares (graphics/audio engine, low level networking, automation)
>
> I should mention that I'm not asking for enforcing error handling to everyone, I just want to make sure I can live and keep programming by not having to use exceptions at all :)
>
> ...

but you can already do this (i.e. program by not having to use exceptions at all).

dmd, for example, doesn't use exceptions (as per previous post from Walter).

And it's in D.

I presume you're talking about exceptions in phobos?

I'm not sure how much of phobos was designed for such low-level programming.

But in any case, it's all open-source, and can be modified (or used to build your own libraries).

So there is nothing holding you back ;-)