Toward the end of Walter's recent talk, D at 20, he says something to the effect that optimizations are disabled when exceptions can be thrown.  We have a compressible flow solver in which it is very convenient to be able to throw an exception from deep within the code and catch it at a relatively high level where we can partially recover and continue the calculation.  Because our calculations can run for days across hundreds of processors, we also care about letting the optimizer do its best. In what parts of our program would the optimizer be disabled because of the presence of the exception and its handling code?  How do we tell?

On Monday, 21 October 2019 at 20:12:19 UTC, Peter Jacobs wrote:
> Toward the end of Walter's recent talk, D at 20, he says something to the effect that optimizations are disabled when exceptions can be thrown.  We have a compressible flow solver in which it is very convenient to be able to throw an exception from deep within the code and catch it at a relatively high level where we can partially recover and continue the calculation.  Because our calculations can run for days across hundreds of processors, we also care about letting the optimizer do its best. In what parts of our program would the optimizer be disabled because of the presence of the exception and its handling code?  How do we tell?

It really comes into effect if you use:

a) structs with destructors
b) scope(exit) and scope(failure)

as these need to be run, regardless of the return mode of the function i.e. normally or via an exception.

Also if the function is nothrow (possibly inferred because its a template, n.b. also that nothrow function can throw Errors as these are considered terminal) then you should also be fine. The effect of exceptions on optimisation effect logic heavy code a lot more that math heavy code.

What kind of conditions are you wanting to throw exception on? infinities, NaNs, ill conditioning, something else?

As always the best way to check is to mark the function of interest, nothrow take a look at the disassembly and compare to without nothrow. You may also want to look to the optimisation summary that I _think_ you can get LDC to generate.

On Monday, 21 October 2019 at 20:37:32 UTC, Nicholas Wilson wrote:
>
> What kind of conditions are you wanting to throw exception on? infinities, NaNs, ill conditioning, something else?
>
> As always the best way to check is to mark the function of interest, nothrow take a look at the disassembly and compare to without nothrow. You may also want to look to the optimisation summary that I _think_ you can get LDC to generate.

Our methods take a few short cuts and occasionally step over a stability boundary, so I guess that it may look like ill-conditioning.

Thank you for the explanation and suggestions.

On Monday, 21 October 2019 at 21:09:32 UTC, Peter Jacobs wrote:
> On Monday, 21 October 2019 at 20:37:32 UTC, Nicholas Wilson wrote:
>>
>> What kind of conditions are you wanting to throw exception on? infinities, NaNs, ill conditioning, something else?
>>
>> As always the best way to check is to mark the function of interest, nothrow take a look at the disassembly and compare to without nothrow. You may also want to look to the optimisation summary that I _think_ you can get LDC to generate.
>
> Our methods take a few short cuts and occasionally step over a stability boundary, so I guess that it may look like ill-conditioning.

The reason I asked that is to see what sort of action you take because there may be better architectures that you can use to handle that kind of change.

For example, you are integrating with some scheme and hit a region of high curvature and need to rollback and change scheme (to either a less coarse time step or better integrator). In which case it may be best to take a page out of databases and use a change-commit kind of approach to short circuit through your calculations and if at the end of your update loop a flag is set that says this update is invalid then retry with another scheme.

> Thank you for the explanation and suggestions.