Hi,
> Rather than introducing yet another base class, what about allowing
> implicit vectors in vector_base<> by suitable constructor arguments?
> This will also keep compilation times under control :-)
>
>
> I'm a bit confused, this solution would then allocate memory in the case
> of :
> element_less_than(X, vector<NumericType>(scalar_vector<NumericType>(X.
> size(), 0.42))), wouldn't it?
No, I propose to extend vector_base<> such that it can hold either
'full' vectors containing data buffers, as well as implicit vectors
which are fully specified by only a few numbers/indices.
> If I want to normalize a vector by substracting a constant c, simply writing
> y = x - scalar_vector<NumericType>(x.size(),c);
> results in a single OpenCL kernel, and more importantly only N reads
> instead of 2N.
>
> In my opinion, it would be a bit sad to remove this functionnality, but
> on the other hand I have no intention to duplicate aaaall the operator
> overloads for implicit_vector_base<> and implicit_matrix_base<> :P
That would be too heavy on both the compiler and on us ;-) Therefore,
let's piggy-back the implicit types on top of vector_base<> and
matrix_base<>. With all the kernel launch overheads it is absolutely no
problem to have a runtime dispatch at this point.
To give you an idea of the implementation:
enum vector_base_selector
{
DENSE_VECTOR,
SCALAR_VECTOR,
UNIT_VECTOR,
};
template <typename NumericT>
class vector_base
{
...
private:
vector_base_selector dense_or_implicit_;
// buffer for dense vectors:
handle_type elements_;
// members for representing the implicit types:
NumericT value_; // for scalar vector
long unit_vector_index_; // for unit vector
...
};
We can't integrate this before 1.6.0, though...
> I also thought about using enable_if<> to check for vector_base<> or
> implicit_vector_base<>, (or only vector_base<> #ifndef
> VIENNACL_WITH_OPENCL), but I'm a bit afraid of the consequences on the
> compilation time, so I thought that providing a common base class in the
> OpenCL case would be a good solution, wouldn't it?
Excessive enable_if<> can also lead to troubles with older and/or
somewhat broken compilers. enable_if<> turned out to be too heavy for
{vector, vector_range, vector_slice} already, so I don't want to go down
the same path again...
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
