On Sun, 12 Jul 2009 11:14:02 -0400, Jérôme M. Berger <jeber...@free.fr>
wrote:
Robert Jacques wrote:
On Sat, 11 Jul 2009 06:14:56 -0400, Lutger
<lutger.blijdest...@gmail.com> wrote:
"Jérôme M. Berger" wrote:
(...)
BLADE has already shown that it is possible to do stuff like this in
a
library, but I think it goes without saying that if it was built into
the language the syntax could be made considerably nicer. Compare:
auto m = MatrixOp!("a*A*B + b*C")(aVal, bVal, aMtrx, bMtrx, cMtrx);
auto m = a*A*B + b*C;
If D could do this, I think it would become the next FORTRAN. :)
-Lars
Actually, this has already been done in C++:
http://flens.sourceforge.net/ It should be possible to port it to D...
Jerome
Someone correct me if I'm wrong, but I think what Blade does is a bit
more
advanced than FLENS. Blade performs optimizations on the AST level and
generates (near) optimal assembly at compile time. I couldn't find
info on
what FLENS does exactly beyond inlining through template expressions,
but
from the looks of it it doesn't do any of the AST level optimizations
Blade
does. Anyone care to provide more info? Can Blade also generate better
asm
than is possible with libraries such as FLENS?
Flens (and several other libraries like it) just provide a syntactic
sugar for BLAS using expression templates. So calling something like a =
b + c + d gets transformed into (if you're lucky) a = b + c; a = a + d;
(and if you're unlucky) temp = b + c; a = temp + d;
The way I understand it, FLENS will never take the second solution.
If it cannot do the first with BLAS, it will fail to compile in
order to let you choose the best way to decompose your operation.
So you end up looping through memory multiple times. The next best
option are
expression templates, (Blitz or Boost come to mind) which encode the
arguments of each operation into a struct. This results in a lot of
temporaries and is a major performance hit for small-ish vectors, but
you only loop through memory once and make no allocations, which is a
win on larger vectors. Then you have BLADE and D array ops which don't
create any temporaries and are faster still. The counter is that a BLAS
library can be tuned for each specific CPU or GPU and select the fastest
library at runtime.
Actually, depending on your architecture, amount of data and number
of operands, looping through memory multiple may in theory be the
best option in some cases. This is because it will use the cache
(and the swap) more efficiently than a solution that loops only once
through all arrays at the same time.
For arrays this is never, ever the case. Array ops are memory bandwidth
bound. (Okay, with enough operands you could mess up the cache, but 100s
of operands are pathological) What you're probably thinking about are the
matrix multiply algorithms, but these algorithms inherently loop through
memory multiple times. It's not something 'added' by the limitation of a
fixed API.
