expression templates

[Robert Jacques]

On Tue, 29 Mar 2011 08:24:01 -0400, enuhtac <enuhtac_lists at gmx.de> wrote:

> 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

Makes sense. I think, particularly if you're thinking about targeting  
OpenCl, etc, than instead of using <=, etc, you should use a higher order  
primitive, like min, filter or map, as this information becomes critical  
to implementation selection. I've used vectorized booleans in Matlab  
before, and found that while the syntax is short and sweet, the usage is  
always a shortcut to another concept.