• Peter Jacobs (11/11) Oct 21 2019 Toward the end of Walter's recent talk, D at 20, he says
• Nicholas Wilson (17/28) Oct 21 2019 It really comes into effect if you use:
• Peter Jacobs (5/11) Oct 21 2019 Our methods take a few short cuts and occasionally step over a
• Nicholas Wilson (11/26) Oct 21 2019 The reason I asked that is to see what sort of action you take

Peter Jacobs <peterj mech.uq.edu.au> writes:

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?

Nicholas Wilson <iamthewilsonator hotmail.com> writes:

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.

Peter Jacobs <peterj mech.uq.edu.au> writes:

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.

Nicholas Wilson <iamthewilsonator hotmail.com> writes:

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.