stanc3
stanc3 copied to clipboard
stan-dev
Create optimization to turn off all runtime checks
There might be two versions of this - one MIR optimization that just removes check_ function calls, and another backend-specific one that tries to get the Math library to not run checks during optimized code generation.
Two versions seems like at least one too many.
What does it mean for math library to not run checks? Not including checks changes behavior, so it's not just optimization.
On Jul 22, 2019, at 3:18 PM, seantalts [email protected] wrote:
There might be two versions of this - one MIR optimization that just removes check_ function calls, and another backend-specific one that tries to get the Math library to not run checks during optimized code generation.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
Two versions seems like at least one too many.
Can you say more about what you mean by that?
What does it mean for math library to not run checks? Not including checks changes behavior, so it's not just optimization.
We've talked about this idea before - we could have a mode that basically just doesn't run any of the check_* functions in the Math library. I think we had decided that the change in behavior was fine for the optimized version - you said that folks shouldn't be relying on exceptions or reject to do control flow.
On Jul 23, 2019, at 6:54 AM, seantalts [email protected] wrote:
Two versions seems like at least one too many.
Can you say more about what you mean by that?
I'm not convinced that even doing this once is worth the development and maintenance cost because of the segfault danger. Segfalting Stan code will tear down the process Stan's running in, whether it's RStan, PyStan or the planned Stan server.
What's the speedup to models you think you can get with this?
What does it mean for math library to not run checks? Not including checks changes behavior, so it's not just optimization.
We've talked about this idea before - we could have a mode that basically just doesn't run any of the check_* functions in the Math library.
I misunderstood and thought you were talking about adding features to the math library.
I think we had decided that the change in behavior was fine for the optimized version - you said that folks shouldn't be relying on exceptions or reject to do control flow.
Not intended control flow, like rejecting parameter values that lead to transformed parameters that fail their checks. For instance, we don't want to put a lower bound on a parameter y this way:
parameters { real y; ...
trasnformed parameters { real<lower = 0> z = y - 2; }
We need <lower = 2> on the declaration of y instead.
The main thing I'm talking about here, though, is that exceptions will get converted to segfaults and segfaults will tear down the process in which Stan's running.
We talked about that too - you can trap sigsegv! Probably worth experimenting with that to make sure we understand how it works before we implement this feature.
On Tue, Jul 23, 2019 at 22:24 Bob Carpenter [email protected] wrote:
On Jul 23, 2019, at 6:54 AM, seantalts [email protected] wrote:
Two versions seems like at least one too many.
Can you say more about what you mean by that?
I'm not convinced that even doing this once is worth the development and maintenance cost because of the segfault danger. Segfalting Stan code will tear down the process Stan's running in, whether it's RStan, PyStan or the planned Stan server.
What's the speedup to models you think you can get with this?
What does it mean for math library to not run checks? Not including checks changes behavior, so it's not just optimization.
We've talked about this idea before - we could have a mode that basically just doesn't run any of the check_* functions in the Math library.
I misunderstood and thought you were talking about adding features to the math library.
I think we had decided that the change in behavior was fine for the optimized version - you said that folks shouldn't be relying on exceptions or reject to do control flow.
Not intended control flow, like rejecting parameter values that lead to transformed parameters that fail their checks. For instance, we don't want to put a lower bound on a parameter y this way:
parameters { real y; ...
trasnformed parameters { real<lower = 0> z = y - 2; }
We need <lower = 2> on the declaration of y instead.
The main thing I'm talking about here, though, is that exceptions will get converted to segfaults and segfaults will tear down the process in which Stan's running.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/stan-dev/stanc3/issues/233?email_source=notifications&email_token=AAGET3ESE37XBYYHNCUXQRLQA5ZH3A5CNFSM4IFZY4ZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2UPLRQ#issuecomment-514389446, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGET3FQROAXSPOUD64SW7TQA5ZH3ANCNFSM4IFZY4ZA .
That's great. I either missed or completely forgot that discussion.
Off topic comment: We should add the traps now either in Stan or at the PyStan or RStan level.