expression templates

[enuhtac]

Am 28.03.2011 02:19, schrieb Robert Jacques:
> Hmm... I don't know you're use case exactly, but it sounds like a case
> of operator overload abuse. The design of opCmp was inspired by the
> amount of bug prone repetition that happens with C++ style comparison
> operators. Furthermore, both opCmp and opEquals have fixed return
> types in order to limit abuse. (D also prevents the overload of
> certain operators for the same reason). The main reason behind
> expression templates is to avoid costly intermediates, but the
> expression is always going to be heavier weight than an int, so why
> can't you evaluated the expression then and there?

If my usage of opCmp is an overload abuse then expression templates are
an abuse of D. Maybe this is true, I'm not sure. Clearly opCmp and
opEquals were not designed with expression templates in mind.

What I would like to achieve is to generate source code from an
expression. E.g.:

expression:

lapl[I,J] = (v[I-1,J] + v[I+1,J] + v[I,J-1] + v[I,J+1]) / h^^2

generated source code:

for( j = 0; j < ny; ++j )
    for( i = 0; i < nx; ++i )
        lap[idx(i,j)] = (v[idx(i-1,j)] + v[idx(i+1,j)] + v[idx(i,j-1)] +
v[idx(i,j+1)]) / h^^2;

If this is D source code it can be immediately be compiled using
mixin(). But it is not necessarily D source code, it could also be
OpenCL source code for example.

So I'm trying to implement an abstraction layer that enables me to
formulate expressions and algorithms independant from the the device
they are executed on. A software written on top of this abtraction layer
would run on CPU or GPU without any modifications. Of course it is
necessary to pass some additional hints about the structure of the
expression to the code generator to enable specific optimizations - but
I think this can be easily done.

The first step to implement such a framework is to parse the expression.
I thought expression templates would be the easiest way to do so (as
compared to string parsing). Also this automatically ensures that
parsing is done at compile time which is necessary for the use of
mixin() of course.

Although not shown above I definitely need comparison operators for the
algorithms I would like to implement (e.g. Godunov type advection
schemes for the simulation of compressible fluid flows).

Regards,
enuhtac