I am a bit confused.
In optimized release mode the `Assert` are reduced to a nnop and will
not abort (or throw an exception). For user-visible/induced runtime
errors we have `AssertThrow` which will throw an exception (and not
abort a program). In summary:
- we use `Assert(...)` in the library to check for logical error
conditions in *debug* mode. These are optimized out in optimized
release mode.
The reasoning behind this is that these asserts are "static", logical
mistakes in the library / user code.
- we use `AssertThrow(...)` to check for error conditions in *debug*
and *release* mode. These checks are always run and used to validate
user-controlled input.
(and catchable to do something in case such an error is encountered).
So I am not sure how you would ever use an `Assert(...)` in optimized
release mode (where you want to run your program to get any
performance).
Regarding the additional if statement: If this is performance critical I
suggest to not use the c++ exception mechanism in this way. Stack
unwinding is very, very slow.
On the other hand, if you have a very unlikely error path and handled in
an if-statement (c++20 style):
if (/* error condition */) [[unlikely]] {
// ... handle error
}
then we have often made the observation that this leads to very acceptable
performance - even in hot execution paths.
Best,
Matthias
On Thu, Aug 3, 2023, at 12:25 CDT, Simon Wiesheier <[email protected]>
wrote:
> Let me please clarify my last concerns in this regard:
>
> The operations
> GridTools::find_active_cell_around_point and
> feValues.reinit
> are executed at quadrature point level and performance
> is really important in our application.
>
> The reason why I wanted to use an
> try/catch block is to surrogate the use of an if-statement.
> Consider these two variants:
>
> Variant 1:
>
> disable_abort_on_exception();
> try
> {
> feValues.reinit(cell,...);
> }
> catch(dealii::Exception Base exception & )
> {
> Assert(checkSecondRunTimeCondition, ...)
> // do something
> }
>
> Variant 2:
>
> if(cell->state()==-1)
> {
> Assert(checkSecondRunTimeCondition, ...)
> // do something
> }
> else
> {
> feValues.reinit(cell,...);
> }
>
> As you can see, there are two conditions I have to check at every
> quadrature point.
> Clearly, Variant 2 implements an if-requests and is probably not the way to
> go.
>
>
> 1. So with regard to performance, would you prefer Variant 1
> (as the try/catch introduces less overhead compared to the if-statement)?
> 2. If so, is the call of "disable_abort_on_exception()" good
> coding practice or would you refrain from doing so?
> In the main function of our program, we have a try/catch with
> catch(dealii::ExceptionBase exception &).
> Given that, in my opinion "disable_abort_on_exception()"
> should cause any undue behavior.
>
> Best,
> Simon
>
>
> Am Do., 3. Aug. 2023 um 14:21 Uhr schrieb Wolfgang Bangerth <
> [email protected]>:
>
>> On 8/2/23 15:58, Simon Wiesheier wrote:
>> >
>> > Does that make sense?
>> > Or do you see a better solution, like checking
>> > cell->status() right after GridTools::find_active_cell_around_point?
>>
>> This. If the function you call returns an error code in the form of an end
>> iterator, just test for that rather than doing something with this
>> iterator
>> and wait to see what happens. It is always worth checking errors as early
>> as
>> possible.
>>
>> Best
>> W.
>>
>> --
>> ------------------------------------------------------------------------
>> Wolfgang Bangerth email: [email protected]
>> www: http://www.math.colostate.edu/~bangerth/
>>
>>
>> --
>> The deal.II project is located at http://www.dealii.org/
>> For mailing list/forum options, see
>> https://groups.google.com/d/forum/dealii?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "deal.II User Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/dealii/53307567-6cd6-3f21-2c63-a5eedf5367f5%40colostate.edu
>> .
>>
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/dealii/874jlfdc1x.fsf%4043-1.org.
