compiling and linking
Matt Hoffman
I've been getting frustrated with the long compile times of stan
models, so I spent some time today breaking out a bunch of the Eigen
functionality out of .hpp files and into .cpp files.
The upshot: a logistic regression model that formerly took ~33 seconds
to compile now takes "only" ~12 seconds to compile and link (once the
.cpp files are compiled, which only needs to happen once).
It's a pretty big change in terms of LOC altered, plus the makefile
had to undergo some changes. So before pushing I'd like to check with
Bob and/or Daniel that I haven't done anything catastrophically
stupid. The tests seem to check out, but still good to be safe, and
also we may want to do more of this kind of thing and I don't want to
set any bad precedents.
Matt
Bob Carpenter
target for speed and also the next hardest after the
parser itself. I'm guessing this will also make it
possible to compile on a 32-bit architecture (not
just cross-compile from a 64-bit machine to a 32-bit
executable).
I also waited for Daniel to handle the bin/stanc make
target. So let's all look at it when we're back in
the office. I'm around tomorrow, so we can at least
look at the code organization.
Most of the libs like Eigen we use can be built
separately because we're only using double and
var instantiations of templates. Eigen seemed
like the slowest to compile, but there's also all
of our auto-dif and math and probability functions.
I'd like to do the refactoring so everything still
works header only. You'll see that
I did the tests that way for the parser and set up
the example in demo that way.
- Bob
Ben Goodrich
I think it would be better if it were possible to build stanc without building libstan because if the R package cannot build a fat binary that works on the 3 flavors of Mac (64bit Intel, 32bit Intel, and 32bit PowerPC), then no binary will be built at all for Macs on the CRAN server. And PowerPC with g++ 4.2 won't build libstan or anything else that links against Eigen.
Ben
Matt Hoffman
checked. If CRAN is going to insist that we support 32-bit powerpc,
and we can't do that because of Eigen, then we can break it out. I
think for now we can actually just remove the dependency/-lstan flag.
If that doesn't work, then it should be possible for stanc to directly
include the .cpp files.
Bob Carpenter
Ben -- I know it's important to the R users and can
make a huge difference in how many people are able
to use Stan in practice.
bin/stanc does not depend on libstan.a or Eigen.
It only calls the compiler, which in turn only calls the
parser and code generator, neither of which
actually execute anything in Stan proper.
> If that doesn't work, then it should be possible for stanc to directly
> include the .cpp files.
for the parser/generator.
Matt built a .a archive for libstan because they
get reused. And that's the way the models are building now.
If a user can't build libstan, they won't be able to compile
the C++ generated for a model. But then I'm not too worried
about the antique enthusiast PowerPC crew.
- Bob
Ben Goodrich
If a user can't build libstan, they won't be able to compile
the C++ generated for a model. But then I'm not too worried
about the antique enthusiast PowerPC crew.
My main point is that the 2^1 PowerPC users would prevent the 2^x MacIntel users from having a binary version of the rstan package. And the Mac version of R defaults to binary package downloads, so without the binary package, many MacIntel users wouldn't be able to install rstan. If they don't have a C++ compiler, they wouldn't be able to estimate a model, but rstan could check for that and prompt them to install a C++ compiler.
Ben
Bob Carpenter
I understood. In addition to getting rid of an unnecessary
(and hence undesirable) dependency in the build, removing
bin/stanc's dependency on libstan.a will let CRAN build
a fat Mac binary for bin/stanc.
We're only worried about PowerPC to the extent that
it'll block us releasing that fat binary.
I didn't even know the Mac still supported fat binaries!
- Bob
Ben Goodrich
Ben