Hello Rainer,
BCS wrote:
Reply to Rainer,
2. Expression-level optimization is the compiler's job, not the
programmer's.
Some (many?) of the interesting optimizations that can be applied to
expressions with overloaded operators are not algebraic in nature.
I'm not sure what you mean by "algebraic" here, but...
Algebraic optimizations would be optimizations that work by applying stuff
you learned in algebra class.
Many of the use cases for operator overloading don't work if the
compiler is allowed to assume all the same identities it can for
scalars (e.g. the transitive identity doesn't hold for matrix math).
The compiler shouldn't make any assumptions. The compiler doesn't
/need/ to make any assumptions, since the compiler has access to the
actual code. For example, take a simple vector expression, with
3-element vectors:
[...]
Ok try another case:
y = a*b + c*a;
for scalers, the compiler can (and should) convert that 3 ops to 2:
y = a*(b+c);
for a matrix you can't. And I'm sure there are matrix cases where you can
get improvements by doing algebraic manipulations before you inline that
would be darn near impossible to get the compiler to figure out after you
inline.
Unless you wan to make a way for the programmer to both add and
remove expression level optimizations, and require an optimization
engine powerful enough to use them, you can't do optimization of
expressions with overloaded operators purely in the compiler.
Why should the programmer need to give hints to the compiler when the
compiler already has enough information to figure out how to optimize
properly?
Because the compiler doesn't have enough information. I've tried to work
with systems that are supposed to do math all by them selves. They didn't
work well. Computational Algebra Systems don't work without hints.
