Convert from PyStan back end to BridgeStan

[bob-carpenter]

It would be good for performance and for keeping up with Stan releases to replace PyStan with the BridgeStan interface to Stan. BridgeStan is also much simpler. We just released a stable 1.0 version with full doc and testing (please let us know if something's unclear). BridgeStan communicates through the low-level ctypes interface for Python, which lets us do everything in memory directly without copying. It's also good for compatibility and installation because it only requires memory compatibility, which is guaranteed by the C++ spec.

[abhiagwl]

Hey Bob! Thanks a lot for the suggestion. @justindomke pointed out BridgeStan is worth looking at (and potentially rewriting much of vistan to be compatible with BridgeStan.) I will update you once we settle on some ideas.

[justindomke]

We poked around the code a little bit this morning. It seems the only place that the code actually uses pystan is in the file interface.py, and inside of that there’s only a few points where pystan is used. So I think that it should be possible to change over to a dependency on bridgestan instead of pystan without needing to re-write much of anything except a few lines in interface.py.

[bob-carpenter]

In addition to interface.py, there is a line that's duplicated in utilities.py and interface.py to configure PyStan logging.

The PyStan model class and fit objects are used a lot, so those are going to have to be recoded for BridgeStan. I couldn't quite tell from casually looking at the code how the PyStan model and fit classes were used outside of interface.py if at all or if you just expose your own class Model. If it's the latter, it'll be a lot easier to retrofit BridgeStan.

It's super important to turn on Stan optimization. It's currently in this state:

        # THIS IS SLOW! TURN OPTIMIZATION ON SOMEDAY!
        extra_compile_args = ['-O1', '-w', '-Wno-deprecated']

Stan requires -O3 to be performant as we coded assuming extensive compiler optimizations in the Stan code base and the underlying matrix and math code (Eigen and Boost) do the same. -O3 should be on the order of 10x times -O0. I'm not sure about -O1. The nice thing is that the BridgeStan compiler will compile a model at -O3 a lot faster than PyStan will compile one at -O1. And BridgeStan just uses make directly for keeping everything up to date, so you could get rid of all the caching code.

I don't see where is_good_model could fail for a well-formed Stan model. Is this just to check that the Stan model isn't broken? (I can imagine you doing that because you used our old example-models, which were full of buggy models.). Running 100 iterations of sampling is really expensive to just check the model is well formed. 1 iteration should be enough if you absolutely have to do this for some reason.