[vsipl++] [patch] Serial Expression Profiling

[Don McCoy]

Jules Bergmann wrote:
> 
> I think it would be easier to read the expression name if
>   - it used prefix or infix notation
>   - treated sub-expressions differently from leaves
> 
> I.e. the above expression could be:
> 
>  prefix: +(*(S,S), /(S,S))
>  infix:  (S*S)+(S/S)
> 
> I would suggest doing infix first, even though it is harder to read,
> and then adding support for infix, since we'll have to support
> operators (such as 'hypot') that don't have infix equivalents.
> 
Do you want support for both expression encodings?  And did you mean 
'prefix' first?

And since you bring it up, most operators don't have an infix equivalent 
(or prefix/postfix as far as I know).  That is why I chose the lower 
case u, b and t to express them.  That was pretty arbitrary, so if we'd 
like to incorporate things like scalar constants, we could rethink this 
a bit.

> 
>  >
>  > Changing it to
>  >
>  >    (v1 * T(4) + v2) / v3
>  >
>  > yields:
>  >
>  >    Expr[LF] 1D *SS+SS/SS 2048 : 1536309 : 1 : 6144 : 14.3626
> 
> As an example of how this notation breaks down, (v1 * T(4)) / (v2 + v3) 
> also
> has the same name: '*SS+SS/SS'.
> 
True, true.  I realized this at the time, but rationalized it by saying 
the user will know what they wrote and it is unlikely that would have 
*both* of the above expressions coded in their algorithm.  The other, 
and probably less compelling reasons, are that the two will likely 
compute in about the same amount of time and the notation is more compact.

That being said, the fact that there are more common notations to use 
and that it is not particularly difficult to change, means we should 
probably do so.

> 
> An alternative to generating the name in this way is to use the standard
> C++ typeinfo (i.e. 'typeid(ExprBlockType).name()').  This is *much* more
> verbose and difficult to read than the above, but it would be possible to
> clean up in a post-processing step.
> 
This was my first thought, but decided that it only made it harder to 
use the profiling if we mandate that extra post-processing step.


I'll take a look at the remaining suggestions and let you know if I have 
any other questions.

Thanks!

-- 
Don McCoy
don (at) CodeSourcery
(888) 776-0262 / (650) 331-3385, x712