Re: [ggt-devel] GMTL: Vector expression template code checked in

[Patrick H. <pa...@in...>]

Patrick Hartling wrote:
> Another problem with this is that it doesn't compile with Visual C++ 
> 7.0.

Since I haven't found any viable workarounds for this problem, I started
working on patches to GMTL that make the vector expression code optional
based on whether the compiler supports the language features used [*]. 
Fortunately for me, Allen's tendency to leave old code in comments
has paid off in a lot of places in terms of the speed at which I can
apply #ifdef's.  This means that users of compilers that can't handle
the more advanced template code won't be able to get the performance
boost of the expression templates, but at least their code will work.

I am concerned, however, about this approach.  It has the same pitfalls
as anything that uses #ifdef's; viz., some code won't be compiled all
the time.  The only other alternative I can think of is to tell users of
GMTL and Visual C++ 7.0 that they have to use 0.3.5.  Of course, if
there are ever any API changes (I don't think that 0.4.0 introduced any
interface changes), then those users could face writing code that
supports both GMTL 0.3.5 and whatever the current version is at the time.

Not being a GMTL author, I can't really say what's good or what's bad
for GMTL, but IMHO, I think that there needs to be something in place
for allowing users of partially compliant C++ compilers to utilize GMTL. 
  I am still inclined to follow the #ifdef approach in the event that
compilers besides VC++ 7.0 have trouble with GMTL.  Are there any other
suggestions?

    -Patrick


[*] I am also concerned that the MIPSpro C++ Compiler 7.3.1.x may not be
able to handle this code, but I haven't tried it yet due to time
constraints.  I have no idea about how well the Sun or HP compilers
handle any of GMTL.

> Allen Bierbaum wrote:
> 
>>I just merged my work on expression templates from the work branch into 
>>the CVS head of GMTL.
>>
>>This is a *major* feature addition and re-working of the VecBase (Vec & 
>>Point) classes and all operators that work on them.
>>
>>This change uses expression templates to remove temporary objects from 
>>expression evaluation and potentially allow compilers to better optimize 
>>the code.
>>
>>For example, with the previous code:
>>
>>vec1 = vec2 + vec3 + (vec4 * 6)
>>
>>that would have created 3 temporary vectors.  In the new code the 
>>expression templates output code that directly computes the final value 
>>from the given operands.  This has shown at least a 2x performance 
>>increase in my tests.
>>
>>The code is far from perfect though and could definitely be optimized 
>>much further.  (especially by someone that knows intel assembly and has 
>>some patience)
>>
>>There is one common compiler error to be aware of.  It is not possible 
>>to pass expression templates where VecBase/Vec/Point objects are expected.
>>
>>Details:
>>
>>GMTL makes extensive use of expression templates.  These templates come 
>>into play when evaluating statement such as:
>>
>>gmtl::Vec3f vec1, vec2, vec3;
>>vec1 = vec2 + (vec3 * 6.0);
>>
>>When evaluating the expression on the second line, GMTL creates an 
>>expression template tree to fully evaluate this expression when = is 
>>called.  The details of this process are normally hidden from the user, 
>>but can come to the forefront when a method expects a Vec or Point 
>>argument and is passed an expression.  For example:
>>
>>void myMethod(gmtl::Vec3f vec)
>>{ ... }
>>
>>gmtl::Vec3f vec1, vec2;
>>
>>myMethod(vec1);           // Works correctly
>>myMethod(vec1 + vec2);    // Fails to compile
>>
>>The reason the second line fails to compile is that the type for "vec1 + 
>>vec2" is not a Vec3f.  It is an expression template that describes how 
>>to sum two Vec3f's. (You may expect an autoconversion to happen, but it 
>>does not because of template argument deduction rules).
>>
>>There are two solutions to this, either explicitly construct a temporary
>>object to pass to the method (which is what an auto conversion would do 
>>anyway) or write the method to handle expression templates.  This second 
>>option is not difficult, but does require a further understanding of 
>>GMTL then is documented here.
>>
>>Here is how the first option could be used:
>>
>>myMethod(gmtl::Vec3f(vec1 + vec2));     // Creates a temporary to pass in
>>
>>
>>
>>In closing: Give the code and try and let me know what you think. :)
>>
>>
>>-Allen
> 
> 
> 


-- 
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2msw3          | http://www.infiscape.com/