Eigen lib optimizations (and Eigen 3.2 compatibility)

[Bob Carpenter]

> Quoting Bob Carpenter <ca...@alias-i.com>:
>
>> Everything's working now with Eigen 3.2 beta, at least
>> on my machine.

On 3/20/13 11:53 AM, Ben Goodrich wrote:
> Yes, it's working for me too. Do you think the Ref<>
> thing is going to be a big help?

I haven't quite figured it out yet! Have you?
For everyone else:

http://eigen.tuxfamily.org/dox-devel/classEigen_1_1Ref.html

I also think we could probably make more use of .noalias()
than we do, but I'm not 100% sure about that, either.
The refs:

http://eigen.tuxfamily.org/dox/TopicLazyEvaluation.html

http://eigen.tuxfamily.org/dox/TopicWritingEfficientProductExpression.html

I also haven't been able to figure out how to
follow their function-calling advice with
Derived templates and still distinguish
vectors, row vectors, and matrices.

http://eigen.tuxfamily.org/dox/TopicFunctionTakingEigenTypes.html

- Bob

[Ben Goodrich]

On Wednesday, March 20, 2013 12:31:13 PM UTC-4, Bob Carpenter wrote:

On 3/20/13 11:53 AM, Ben Goodrich wrote:
> Yes, it's working for me too. Do you think the Ref<>
 > thing is going to be a big help?

I haven't quite figured it out yet!   Have you?
For everyone else:

   http://eigen.tuxfamily.org/dox-devel/classEigen_1_1Ref.html

I think the intention is that a Ref<> can be to anything that inherits from MatrixBase, so Matrix<Scalar, Dynamic, Dynamic>, Matrix<Scalar, Dynamic, 1>, Matrix<Scalar, 1, Dynamic>, a Map<> of a Matrix<> a Block<> of a Matrix<> etc. I haven't figured out yet whether expressions like .transpose() would work. But if you combine Ref<> with enable_if / disable_if depending on the Scalar type, then it could simplify a lot of code.
 

I also think we could probably make more use of .noalias()
than we do, but I'm not 100% sure about that, either.

Yeah, unless you are multiplying a matrix by itself, then we should use .noalias() on the left.

Ben

[Marcus Brubaker]

Ref<> would also seem to allow us to move a lot of the code out of
header files if desired to speed up compilation. Right now (and for
the foreseeable future) we're unlikely to get a lot of benefit from
compile time template optimizations so that might also be worth it.

> --
> 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.
>
>

[Bob Carpenter]

On 3/20/13 12:51 PM, Ben Goodrich wrote:
> On Wednesday, March 20, 2013 12:31:13 PM UTC-4, Bob Carpenter wrote:
>
> On 3/20/13 11:53 AM, Ben Goodrich wrote:
> > Yes, it's working for me too. Do you think the Ref<>
> > thing is going to be a big help?
>
> I haven't quite figured it out yet! Have you?
> For everyone else:
>
> http://eigen.tuxfamily.org/dox-devel/classEigen_1_1Ref.html
> <http://eigen.tuxfamily.org/dox-devel/classEigen_1_1Ref.html>
>
>
> I think the intention is that a Ref<> can be to anything that inherits from MatrixBase, so Matrix<Scalar, Dynamic,
> Dynamic>, Matrix<Scalar, Dynamic, 1>, Matrix<Scalar, 1, Dynamic>, a Map<> of a Matrix<> a Block<> of a Matrix<> etc. I
> haven't figured out yet whether expressions like .transpose() would work. But if you combine Ref<> with enable_if /
> disable_if depending on the Scalar type, then it could simplify a lot of code.

Aha! Then we could use a Ref and also (dis|en)able_if on the
R and C types to distinguish vectors from row vectors
from matrices. Cool!

I'll write out an enabler lib for our basic types so
we don't have to keep duplicating code. I'll have to
think a bit on what we need there. Maybe it can be
combined with argument promotion for computing the result
type.

> I also think we could probably make more use of .noalias()
> than we do, but I'm not 100% sure about that, either.


> Yeah, unless you are multiplying a matrix by itself, then we should use .noalias() on the left.

OK -- that's a rule I can follow. Marcus already used
them in most of the really critical code.

Daniel and I are going to code-review all of the matrix
stuff again for the refactor, so I'll look for .noalias()
opportunities.

I'll also drop a note on the overview of how we're refactoring.
We're not actually trying to change implementations, just
break apart the really big files and tests and cut down on
interdependencies. But we can clean up things like .noalias()
as we go.

- Bob

[Bob Carpenter]

On 3/20/13 1:00 PM, Marcus Brubaker wrote:
> Ref<> would also seem to allow us to move a lot of the code out of
> header files if desired to speed up compilation. Right now (and for
> the foreseeable future) we're unlikely to get a lot of benefit from
> compile time template optimizations so that might also be worth it.

Our notes crossed on header files versus code files.

I don't see how Ref will help with that. Ref itself requires
a template parameter that will look like what we currently have,
or will have to be instantiated. Or am I missing something here?

An example of the code layout in .hpp and .cpp files would help
me. I don't need the implementations.

- Bob