On Tue, Nov 3, 2009 at 5:53 PM, Benoit Jacob
<jacob.benoit..1@xxxxxxxxx> wrote:
Hi,
I'm just back from Google offices in Mountain View where I had lunch
with 4 Googlers including Keir.
It's very likely that they start using Eigen in a few months for a few
projects, so the idea is that they start right away using (a
pre-release of) Eigen 3.0 (more on that later, i want us to start
discussing roadmaps soon but i need to merge my fork first).
There is already use of 2.0, and that will continue until 3.0 is available.
So the very vague timeline is that at some point during Spring 2010 we
release usable betas of eigen 3.0 with a 99% finalized API and they
start playing with that.
Now let's discuss what came out of the conversation, as to how to make
Eigen 3 most useful to them.
1. The biggest requirement is to guarantee reliability/precision. A
big part of that is already happening, e.g. that's part of what the
refactor_solve_api fork is about. But we need to go beyond that and
actually i had been thinking for a while that, in addition to our
current unit tests that don't aim to test precision, we need a bunch
of precision-oriented tests. Over the past months, as i was more and
more concerned with that, I've already written several small programs
to test that, so i have to turn them into official unit tests.
Moreover one of the Googlers (was it Keir?) had a great idea: a great
test would be to run the big BLAS/LAPACK test suites against a
BLAS/LAPACK lib implemented on top of Eigen. Since Gael already
implemented BLAS level 1 and 3 on top of Eigen (the blas/ directory),
we're already almost able to start doing that! Also, when we write
custom precision-oriented tests, we could have a peek at the datafiles
of the LAPACK test suite, and steal their tricky matrices.
This would be great. LAPACK, for all its fortran cruftiness, is exceptionally well tested. We would be wise to exploit the test suites built over the decades to verify LAPACK's correctness.
A second benefit to having a LAPACK / BLAS frontend to Eigen is that lots of other software could use eigen as a drop in replacement for MKL, ATLAS, etc.
2. They also had a requirement that a single executable should be able
to run fast on various hardware with various cache size. So here the
big problem is that we currently only allow to specify the cache size
as a compile time constant, namely a preprocessor #define
EIGEN_TUNE_FOR_CPU_CACHE_SIZE. One of the Googlers (Matthew, i think)
suggested that it might be as easy as defining
EIGEN_TUNE_FOR_CPU_CACHE_SIZE to be the name of some variable defined
in the application. Thinking again about it, there is one little
problem here: we are passing that to ei_meta_sqrt, so currently it has
to be a compile time constant. In the case of a runtime parameter, the
sqrt would have to be computed at runtime. What should we do?
* Just use sqrt() ? The questions are: are we OK to always pay for a
sqrt here? This seems like unneeded extra performance degradation for
small dyn-size matrices (of course it's negligible for large
matrices). In the default case of a compile-time constant, GCC >= 4.3
is able to compute the sqrt at compile-time, but i wonder about MSVC
and ICC.
If the variable is encapsulated in a binary library, then the square root can also be stored in a variable so that it is only recomputed if the size changes; for example:
void Eigen::SetCacheBlockSize(int new_size) {
ei_cache_block_size = new_size;
ei_sqrt_cache_block_size = sqrt(new_size)
}
* Introduce a separate preprocessor #define to let the user specify a
runtime cache size variable name?
Or going farther into the direction of binary libraries:
* Introduce a preprocessor symbol to define some global variables,
e.g. one for the cpu cache size? We'd need to tell the user that if he
wants to use the corresponding feature, then one of his source file
must define that macro before #including Eigen.
There is of course always the option of creating an optional tiny
binary lib, but i still don't see a compelling reason to do that...
I don't think a small binary library is crazy, provided it is optional and disabled by default. This would also open the door to us determining cache sizes at startup, so the user doesn't have to. It's extra maintenance, but going forward it may be required if we wish Eigen to get used in prebuilt software. For example, consider packages depending on Eigen compiled for debian, or libmv when eventually bundled with blender.
There was another item brought up by a Googler, who couldn't make lunch, which was that there aren't any benchmarks on the wiki comparing sparse performance. It would be nice if the benchmark suite included comparisons against, e.g. gmm++ and ublas. I realize most of the solvers are implemented by other backends, but things like sparse matrix multiplication is still done natively.
Thanks for joining us for lunch!
Keir
Benoit