Hi,
> While we're at it. I'm implementing reductions, now.
> There are two options here :
>
> template<class OP, class VectorType> reduce(VectorType const & v) {
> return scalar_expression<VectorType, OP, reduce_type>(v, OP());
> }
This is inconsistent with other uses of expression templates.
> template<class OP, class VectorType> reduce(VectorType const & v) {
> return scalar_expression<VectorType, VectorType, reduce_type<OP>
> >(v,v);
> }
>
> the first one is scheduler-friendly, but the second one is more
> meta-programming friendly. I'm really confused here, any advice on which
> one to choose?
The second. :-)
> I would prefer the first one, since handling the second
> one in the scheduler would clearly be a pain, considering that I don't
> want to introduce REDUCE_ADD, REDUCE_MAX, etc..., but just a single
> REDUCE, operator, and reuse the existing ones. I think several other
> similar cases will arise, such as three arguments function, where it is
> preferable to create the appropriate tree structure directly from the
> function call. Am I right?
No matter which of the two approaches you pick, the compiler will always
end up instantiating one overload for each reduction operation. When
converting the expression over to the scheduler, you will have the
freedom of regrouping expressions as needed no matter which one of the
two approaches you pick...
With respect to temporaries: Keep in mind that temporaries inside a
single statement are guaranteed to live as long as there are
const-references to it. However, I don't think this is an issue here...
Best regards,
Karli
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
_______________________________________________
ViennaCL-devel mailing list
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
