Is building bin/libstan.a necessary?

[Daniel Lee]

Just wondering. It only has one compiled file in it.

I'm thinking we can either:

1. make Stan programs header only. (We still need to split out stanc's library)

2. add more stuff to the library and hopefully make the compile time a little quicker.

Daniel

[Allen Riddell]

For Python at least, ensuring libstan.a is in the right place is a serious
challenge. Making sure it is removed and then replaced when upgrading is also
a concern.

I'd welcome a header-only Stan.

Best,

Allen

> --
> 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/d/optout.

[Marcus Brubaker]

The only reason we build libstan.a is because we need to somehow allocate the global variables for the autodiff stack which are declared in agrad/rev/var_stack.cpp.  If a model simply included that file (perhaps renaming it to var_stack_impl.hpp or something), we would no longer need libstan.a.

Cheers,

Marcus

[Bob Carpenter]

We also want to look at reducing model compile time.
libstan.a isn't doing that.

The only reason we build the parsers out
as separate translation units is that Windows chokes on
compiling it header only. They're usable header only
as well if the compilers get better. I followed
the pattern outlined in Vandevoorde and Josuttis's book:

1. header-only file .hpp
2. definitions file .def.hpp (includes 1)
3. instantiation file .cpp (includes 2)

To use header only, you include (2).

To use standalone, you include (1), but also
compile (3) in its own translation unit and then link it.

- Bob

[Allen Riddell]

Where does this stand? Should I try this out in Python (renaming/including
agrad/rev/var_stack.cpp)?

Not compiling libstan.a would simplify a tremendous number of things for the
PyStan build process. Not only would one not have to worry about putting
libstan.a in its right place, but one could also distribute the software as
a compressed wheel which will speed up installation slightly (above and beyond
not having to compile libstan.a).

Best wishes,

-a

[Marcus Brubaker]

I'd say give it a shot for PyStan and see how it goes.  If we could make Stan 100% header-only for models, that would be great.  I know we'd like to try to precompile things to speed up model compilation but, honestly, it seems that this is unlikely in the near to medium future.

Also of note, I poked around and found this: http://stackoverflow.com/questions/11709859/how-to-have-static-data-members-in-a-header-only-library which suggests that if we made the static variables into static members of some base class then we'd be set.  This seems like it might be a more elegant solution than requiring models to include some file exactly once to get the static definition.

Cheers,

Marcus

[Bob Carpenter]

I'm all in favor of building moders header only. I'd
be in favor of doing the same with the parser if Windows
can handle it.

Can we then just distribute pre-built binary versions of
the parser? I have no idea how to distribute cross-platform
binaries.

Doesn't the problem with the globals (for reverse mode
stack) just go away if we build header only? We'll only have
a single translation unit, hence only one definition.

A bottleneck for compiling models will be
the probability functions, which can't be instantiated
ahead of time due to the combinatorics of argument types.

- Bob

[Allen Riddell]

On 09/17, Marcus Brubaker wrote:
> I'd say give it a shot for PyStan and see how it goes. If we could make
> Stan 100% header-only for models, that would be great. I know we'd like to
> try to precompile things to speed up model compilation but, honestly, it
> seems that this is unlikely in the near to medium future.
>
> Also of note, I poked around and found this:
> http://stackoverflow.com/questions/11709859/how-to-have-static-data-members-in-a-header-only-library
> which suggests that if we made the static variables into static members of
> some base class then we'd be set. This seems like it might be a more
> elegant solution than requiring models to include some file exactly once to
> get the static definition.
>

Great, I'll give this a shot with agrad/rev/var_stack.cpp.

[Allen Riddell]

On 09/17, Bob Carpenter wrote:
> I'm all in favor of building moders header only. I'd
> be in favor of doing the same with the parser if Windows
> can handle it.
>
> Can we then just distribute pre-built binary versions of
> the parser? I have no idea how to distribute cross-platform
> binaries.

This, as of about a few months ago, ceased to be a problem for Python. You can
now build OS X and Windows binaries and distribute them from the package index
(Python's CRAN). But I'd make the change for the simplification of the build
process alone. It's really ugly right now.

>
> Doesn't the problem with the globals (for reverse mode
> stack) just go away if we build header only? We'll only have
> a single translation unit, hence only one definition.

Bob, can you explain this a bit more? Is this different than what Marcus said in
the previous emails?

What was the thinking behind not making agrad/rev/var_stack.cpp header only in
the first place? Was the idea that it would decrease compile time of the models?

Best, -a

[Bob Carpenter]

The problem is that

Everything WAS header only in the first place. Then we ran into slow compilation
times and troubles with Windows toolchains crashing (and maybe other issues?).

You'll have to get more help from Daniel and/or Marcus on the justification
for what's there now --- they both understand the build process much better than
I do.

If var_stack is the only thing left, you should just be able to include the .cpp
like it was a .hpp file. If it has a header guard, that is. Adding a header
guard won't hurt it if it doesn't.

The most general way to lay things out is to create three parallel files:

.hpp header
.def.hpp header-only definitions
.cpp instantiations

Then we can have our cake and eat it, too. To use the lib header only, you
include def.hpp. To build it, you use .cpp and then for code that links to it,
include .hpp. It's the code pattern you see in the parser. It's discussed
in Vandevoorde and Josuttis's most excellent C++ templates book.

- Bob

[Marcus Brubaker]

In the time that I've worked on Stan, var_stack.cpp (or something like it) has always existed.  The reason, I suspect, is that we needed to have static global variables for the autodiff stack and the traditional way to define something like this is to have a compiled object file which instantiated those global variables.  I'm certain that compilation time was never really a factor for this in particular.  (Compilation time was an issue for libstanc.a, i.e., the parser part, but this is different.)

Anyway, it seems like (based on the stackoverflow link) that C++ can handle this itself for static class members, removing the need for var_stack.cpp and making Stan header-only for model compilation.

Cheers,

Marcus

[Bob Carpenter]

The original version was header only because I didn't know
how to handle anything but one translation unit (I didn't even
know that's what I was doing). Everything's easy if you only have
one translation unit :-)

I also created a simplified version of Stan's autodiff in the
nomad branch for simple A/B comparisons with the new autodiff.
And partly to help diagnose why Stan is so fast at first order (alas,
still a mystery, though not unpleasant for Stan as is).

- Bob