precompiling Stan as object code

43 views
Skip to first unread message

Bob Carpenter

unread,
Dec 1, 2013, 10:07:52 PM12/1/13
to stan...@googlegroups.com
[back on stan-dev]

On 12/1/13, 5:35 PM, Ben Goodrich wrote:

>> The only thing I was thinking about doing was using
>> template instantiations as we do for the grammars
>> so these become one-time speed costs at the expense of
>> using much more memory. This is just the template lib
>> version of breaking a lib into .cpp and .hpp file.
>
> Is it not possible to do the same thing with the rest of Stan the library? Like instantiate one dynamically resizeable
> Cholesky object with our scalar types?

It's pretty straightforward. Especially for Cholesky,
which only has two instantiations until we add RHMC,
namely Matrix<double> and Matrix<var>.

The problem is that we have a lot of functions and many of
them are far more polymorphic than the Cholesky decomposition.

The worst case is for now is the Student-t density function,
which has four arguments, each of which can be instantiated by

double, var,
vector<double>, vector<var>,
row-vector<double>, row-vector<var>,
vector<var>, vector<double>, for a total of 8^4 (4096) instantiations.

I don't think that will be feasible in terms of compilation time
or object code size.

With the header-based approach we take now, only the instances that
are used in a particular model get instantiated and compiled, though
it has to be done on a model-per-model basis.

- Bob


Ben Goodrich

unread,
Jan 12, 2014, 7:13:07 PM1/12/14
to stan...@googlegroups.com

I see what you are saying about instantiating the density functions, but can we do something about instantiating the classes we use? I have been reading about the "extern template" syntax, which is now part of the c++11 standard but has been a gcc-ism since version 3.3, so it should work with the llvm-g++-4.2 on Macs and the mingw-4.6 on Windows. This basically does explicit instantiation once and then blocks implicit instantiation in the files that use those classes.

There is a recipe for it here

http://books.google.com/books?id=gCn0wqT4W14C&lpg=PT472&ots=H8T2VMlz2O&dq=c%2B%2B11%20%22extern%20template%22&pg=PT471#v=onepage&q&f=false

and a FAQ here

http://www.stroustrup.com/C++11FAQ.html#extern-templates

Ben

Bob Carpenter

unread,
Jan 13, 2014, 6:46:22 PM1/13/14
to stan...@googlegroups.com


On 1/13/14, 1:13 AM, Ben Goodrich wrote:

> I see what you are saying about instantiating the density functions, but can we do something about instantiating the
> classes we use? I have been reading about the "extern template" syntax, which is now part of the c++11 standard but has
> been a gcc-ism since version 3.3, so it should work with the llvm-g++-4.2 on Macs and the mingw-4.6 on Windows. This
> basically does explicit instantiation once and then blocks implicit instantiation in the files that use those classes.
>
> There is a recipe for it here
>
> http://books.google.com/books?id=gCn0wqT4W14C&lpg=PT472&ots=H8T2VMlz2O&dq=c%2B%2B11%20%22extern%20template%22&pg=PT471#v=onepage&q&f=false
>
> and a FAQ here
>
> http://www.stroustrup.com/C++11FAQ.html#extern-templates

Stroustrup also links the proposal:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1448.pdf

We're not really doing any dynamic linking (except of a complete
Stan model with R in RStan; and maybe in PyStan), and that's the use
case the proposal talks about.

Where would we put the "extern template" declaration? And what compilation
would it suppress?

- Bob

Daniel Lee

unread,
Jan 19, 2014, 6:30:40 PM1/19/14
to stan...@googlegroups.com
On Tue, Jan 14, 2014 at 8:46 AM, Bob Carpenter <ca...@alias-i.com> wrote:
Where would we put the "extern template" declaration?  And what compilation
would it suppress?

I'm curious about this also. What would "extern template" buy us in terms of saving compilation time?

Ben Goodrich

unread,
Jan 19, 2014, 7:38:29 PM1/19/14
to stan...@googlegroups.com

My understanding is that we have things like

Eigen::Matrix<var,Eigen::Dynamic,Eigen::Dynamic>

all over the place and the compiler has to generate a lot of code every time one of those functions gets invoked. So, the extern template mechanism outlined in the Boost recipes book tries to make it such that you can tell the compiler to generate all the necessary code for that type once in a file that gets #included by files that need it.

Ben
 

Daniel Lee

unread,
Jan 19, 2014, 7:43:44 PM1/19/14
to stan...@googlegroups.com
I was under the impression that it only gets instantiated once because we're header only.

I think Bob's under the same impression. This is from his email on 12/2/2013:

With the header-based approach we take now, only the instances that
are used in a particular model get instantiated and compiled, though
it has to be done on a model-per-model basis.

 
 

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

Ben Goodrich

unread,
Jan 19, 2014, 7:55:23 PM1/19/14
to stan...@googlegroups.com
On Sunday, January 19, 2014 7:43:44 PM UTC-5, Daniel Lee wrote:
On Mon, Jan 20, 2014 at 9:38 AM, Ben Goodrich <goodri...@gmail.com> wrote:
On Sunday, January 19, 2014 6:30:40 PM UTC-5, Daniel Lee wrote:
On Tue, Jan 14, 2014 at 8:46 AM, Bob Carpenter <ca...@alias-i.com> wrote:
Where would we put the "extern template" declaration?  And what compilation
would it suppress?

I'm curious about this also. What would "extern template" buy us in terms of saving compilation time?

My understanding is that we have things like

Eigen::Matrix<var,Eigen::Dynamic,Eigen::Dynamic>

all over the place and the compiler has to generate a lot of code every time one of those functions gets invoked. So, the extern template mechanism outlined in the Boost recipes book tries to make it such that you can tell the compiler to generate all the necessary code for that type once in a file that gets #included by files that need it.

I was under the impression that it only gets instantiated once because we're header only.

I think Bob's under the same impression. This is from his email on 12/2/2013:
With the header-based approach we take now, only the instances that
are used in a particular model get instantiated and compiled, though
it has to be done on a model-per-model basis.

But we do that once for each of hundreds of tests, right?

Ben

Daniel Lee

unread,
Jan 19, 2014, 7:58:40 PM1/19/14
to stan...@googlegroups.com
Yes. That's right.

So its use is very close to explicit template instantiation?


Ben Goodrich

unread,
Jan 19, 2014, 8:02:29 PM1/19/14
to stan...@googlegroups.com
On Sunday, January 19, 2014 7:58:40 PM UTC-5, Daniel Lee wrote:
Yes. That's right.

So its use is very close to explicit template instantiation?

I think so.

Ben
 
Reply all
Reply to author
Forward
0 new messages