[Numpy-discussion] performance matrix multiplication vs. matlab
jacob.benoit.1 at gmail.com
Tue Jun 9 21:46:00 EDT 2009
I'm one of the Eigen developers and was pointed to your discussion. I
just want to clarify a few things for future reference (not trying to
get you to use Eigen):
> No, eigen does not provide a (complete) BLAS/LAPACK interface.
> I don't know if that's even a goal of eigen
Not a goal indeed, though there's agreement that such a bridge would
be a nice add-on. (Would be a one-directional bridge though. You can't
express with BLAS/LAPACK all what you can express with the Eigen API).
> (it started as a project for KDE, to support high performance core
> computations for things like spreadsheet and co).
Yes, that's how it started 3 years ago. A lot changed since, though. See
> Eigen is:
> - not mature.
> - heavily expression-template-based C++, meaning compilation takes ages
No, because _we_ are serious about compilation times, unlike other c++
template libraries. But granted, compilation times are not as short as
a plain C library either.
> + esoteric, impossible to decypher compilation errors.
Try it ;) See e.g. this comment:
> - SSE dependency harcoded, since it is setup at build time. That's
> going backward IMHO - I would rather see a numpy/scipy which can load
> the optimized code at runtime.
Eigen doesn't _require_ any SIMD instruction set although it can use
SSE / AltiVec if enabled.
It is true that with Eigen this is set up at build time, but this is
only because it is squarely _not_ Eigen's job to do runtime platform
checks. Eigen isn't a binary library. If you want a runtime platform
switch, just compile your critical Eigen code twice, one with SSE one
without, and do the platform check in your own app. The good thing
here is that Eigen makes sure that the ABI is independent of whether
vectorization is enabled.
And to reply to Matthieu's mail:
> I would add that it relies on C++ compiler extensions (the restrict
> keyword) as does blitz. You unfortunately can't expect every compiler
> to support it unless the C++ committee finally adds it to the
currently we have:
#define EIGEN_RESTRICT __restrict
This is ready to be replaced by an empty symbol if some compiler
doesn't support restrict. The only reason why we didn't do this is
that all compilers we've encountered so far support restrict.
More information about the NumPy-Discussion