boost::dll

[Krzysztof Sakrejda]

I got a boost::dll example working to the extent that:

1. stanc generates a class
2. I add a factory function for creating an instance of the model from a var_context
3. compile the whole thing into a shared object
4. link into a small test program and load the symbol for the factory function

I'm pretty close to getting a working example that constructs and uses a model instance but I have to drop this for a few days. The only difficulty I've run into so far is that boost::dll is not in 1.60.0 so I used the development version of Boost and it seems to work fine for the example (no warnings/errors anyway). Has anybody tried Stan's unit tests with the development version of boost lately?

Krzysztof

[Daniel Lee]

What does boost::dll do?

Krzysztof

--
You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Lee]

And what are you trying to do? From what you've described, we should be able to do that from CmdStan without boost. We just choose to build an executable all at once.

Daniel

[Krzysztof Sakrejda]

On Thursday, August 11, 2016 at 10:00:20 AM UTC-4, Daniel Lee wrote:
> And what are you trying to do? From what you've described, we should be able to do that from CmdStan without boost. We just choose to build an executable all at once.

Hey, sorry I just posted b/c I knew Ben had been interested in it too. boost::dll makes it reasonably straightforward to used shared libraries as plugins from c++. You basically pass it a path and a symbol alias and it lets you instantiate the relevant function in one step.

I'm figuring out what it would take to have a centrally installed command line client that could be re-used with multiple models and this was one of the pieces. The specific models could be built into shared libraries and only found/used by the client at runtime. Back when Allen and I were working on some of the pieces for running Stan as a server this was one of the missing pieces we couldn't figure out (well, couldn't figure out without resorting to R/Python for their build/plugin systems).

Krzysztof

>
>
>
>
> Daniel
>
>
>
>
> On Thu, Aug 11, 2016 at 9:58 AM, Daniel Lee <bea...@alum.mit.edu> wrote:
>
> What does boost::dll do?
>
>
>
>
> On Thu, Aug 11, 2016 at 9:51 AM, Krzysztof Sakrejda <krzysztof...@gmail.com> wrote:
> I got a boost::dll example working to the extent that:
>
>
>
> 1. stanc generates a class
>
> 2. I add a factory function for creating an instance of the model from a var_context
>
> 3. compile the whole thing into a shared object
>
> 4. link into a small test program and load the symbol for the factory function
>
>
>
> I'm pretty close to getting a working example that constructs and uses a model instance but I have to drop this for a few days.  The only difficulty I've run into so far is that boost::dll is not in 1.60.0 so I used the development version of Boost and it seems to work fine for the example (no warnings/errors anyway).  Has anybody tried Stan's unit tests with the development version of boost lately?
>
>
>
> Krzysztof
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
>

> To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.

[Ben Goodrich]

On Thursday, August 11, 2016 at 10:23:55 AM UTC-4, Krzysztof Sakrejda wrote:

On Thursday, August 11, 2016 at 10:00:20 AM UTC-4, Daniel Lee wrote:
> And what are you trying to do? From what you've described, we should be able to do that from CmdStan without boost. We just choose to build an executable all at once.

Hey, sorry I just posted b/c I knew Ben had been interested in it too.  boost::dll makes it reasonably straightforward to used shared libraries as plugins from c++.  You basically pass it a path and a symbol alias and it lets you instantiate the relevant function in one step.  

This is great. Presumably, we can get the dll library included in the next version of BH. Could it help with compilation time / size to compile as much as possible up front in rstan and then link the plugin with the specifics of the model to it? It is also conceivable that the various interfaces could all work with the same model as a plugin.

Ben

[a...@ariddell.org]

On 08/11/2016 10:23 AM, Krzysztof Sakrejda wrote:
> On Thursday, August 11, 2016 at 10:00:20 AM UTC-4, Daniel Lee wrote:
>> And what are you trying to do? From what you've described, we should be able to do that from CmdStan without boost. We just choose to build an executable all at once.
>
> Hey, sorry I just posted b/c I knew Ben had been interested in it too. boost::dll makes it reasonably straightforward to used shared libraries as plugins from c++. You basically pass it a path and a symbol alias and it lets you instantiate the relevant function in one step.
>
> I'm figuring out what it would take to have a centrally installed command line client that could be re-used with multiple models and this was one of the pieces. The specific models could be built into shared libraries and only found/used by the client at runtime. Back when Allen and I were working on some of the pieces for running Stan as a server this was one of the missing pieces we couldn't figure out (well, couldn't figure out without resorting to R/Python for their build/plugin systems).
>

In theory you could compile a model once and then use the same shared
object from R and Python (and anything else), right?

There are some practical difficulties here (e.g., you'd have to compile
this shared object for every target platform and manage distributing it).

Very cool!

[Daniel Lee]

I just ran through all the doc.

This is cool and I can see a decent use case for it in RStan and PyStan.

It doesn't address the template instantiation, though. I take it you've instantiation the generated code with doubles and vars somewhere?


Daniel

[Krzysztof Sakrejda]

On Thursday, August 11, 2016 at 12:58:55 PM UTC-4, Ben Goodrich wrote:
> On Thursday, August 11, 2016 at 10:23:55 AM UTC-4, Krzysztof Sakrejda wrote:On Thursday, August 11, 2016 at 10:00:20 AM UTC-4, Daniel Lee wrote:
>
> > And what are you trying to do? From what you've described, we should be able to do that from CmdStan without boost. We just choose to build an executable all at once.
>
>
>
> Hey, sorry I just posted b/c I knew Ben had been interested in it too.  boost::dll makes it reasonably straightforward to used shared libraries as plugins from c++.  You basically pass it a path and a symbol alias and it lets you instantiate the relevant function in one step.  
>
>
>
> This is great. Presumably, we can get the dll library included in the next version of BH. Could it help with compilation time / size to compile as much as possible up front in rstan and then link the plugin with the specifics of the model to it?

That's a great question. I only took the output of stanc and appended a factory function to the end of it so I could compile the shared library and have a symbol to load in the C++. I know Daniel and Bob have talked about pre-compiling pieces before the model but there are so many ways to instantiate the various functions that that sort of pre-compiled library would be huge (Bob mentioned something about terabytes). Maybe we could pre-compile some of the more commonly used stuff but I'm not sure how to pick that out from the rest. It's not really an issue that you need boost::dll to address---just some judicious pre-compilation of specific instantiated templates.

>It is also conceivable that the various interfaces could all work with the same model as a plugin.

This could definitely work but I'm not sure what the advantage would be to R/Python unless the current methods for loading models are difficult to maintain. I looked at the .hpp files rstan outputs and it looks like a pretty moderate amount of Rcpp module magic. Not sure about Python.

Krzysztof


>
> Ben

[Krzysztof Sakrejda]

On Thursday, August 11, 2016 at 1:19:01 PM UTC-4, Daniel Lee wrote:
> I just ran through all the doc.
>
> This is cool and I can see a decent use case for it in RStan and PyStan.
>
> It doesn't address the template instantiation, though. I take it you've instantiation the generated code with doubles and vars somewhere?

I didn't deal with that at all, I think it's a separate issue (?) I just took the output of running stanc on examples/bernoulli/bernoull.stan
and appended the factory function:

// Factory method
static boost::shared_ptr<bernoulli_model> create(stan::io::var_context& context) {
return boost::shared_ptr<bernoulli_model>(
new bernoulli_model(context)
);
}

BOOST_DLL_ALIAS(
bernoulli_model_namespace::create, // <-- this function is exported
create_model // <-- with this alias name
)

} // namespace

The boost::dll can be used to load the factory function and go from there.

[Krzysztof Sakrejda]

On Thursday, August 11, 2016 at 1:11:14 PM UTC-4, a...@ariddell.org wrote:
> On 08/11/2016 10:23 AM, Krzysztof Sakrejda wrote:
> > On Thursday, August 11, 2016 at 10:00:20 AM UTC-4, Daniel Lee wrote:
> >> And what are you trying to do? From what you've described, we should be able to do that from CmdStan without boost. We just choose to build an executable all at once.
> >
> > Hey, sorry I just posted b/c I knew Ben had been interested in it too. boost::dll makes it reasonably straightforward to used shared libraries as plugins from c++. You basically pass it a path and a symbol alias and it lets you instantiate the relevant function in one step.
> >
> > I'm figuring out what it would take to have a centrally installed command line client that could be re-used with multiple models and this was one of the pieces. The specific models could be built into shared libraries and only found/used by the client at runtime. Back when Allen and I were working on some of the pieces for running Stan as a server this was one of the missing pieces we couldn't figure out (well, couldn't figure out without resorting to R/Python for their build/plugin systems).
> >
>
> In theory you could compile a model once and then use the same shared
> object from R and Python (and anything else), right?

Yes, and maybe we could reduce the wrapping that R/Python interfaces have to do down to some simpler calls.

> There are some practical difficulties here (e.g., you'd have to compile
> this shared object for every target platform and manage distributing it).

Yeah, I don't know if that's necessarily worth the effort... I was thinking more of making it easier to cache models locally. Maybe you could generate and pre-compile a lot of models for rstan that would then just need to be downloaded (?) I don't know what the compelling use cases would be outside of a more flexible command line client.

K

> Very cool!

[Sebastian Weber]

Hi!

@Ben: Would this stuff allow us to conveniently compile the exposed stan functions for R and save them in order to avoid recompilation every time we restart R?

Other than that this sounds very cool (I understood that this will bring down compilation times and potentially make models sharable between interfaces).

Sebastian