Hi hi,
2013/10/16 Karl Rupp <r...@iue.tuwien.ac.at>
> Hi,
>
> > It seems like the behavior of scalar_vector, unit_vector etc has changed
> > a bit since the appearance of the kernel generator.
> > I am currently extending the API of the generator, with relational
> > operators. I want to design a specific kernel which checks for X[i] <
> > 0.42, for all i.
> > Since operator< is misleading, I am using the more verbose but clearer
> > approach :
> >
> > element_less_than(X, scalar_vector<NumericType>(X.size(), 0.42)).
> > The verbosity is a problem, but a minor one, so I will ignore it for now
> > (I think end users can live with that :P).
>
> Most of all, it is consistent with element_prod(), element_div(), and
> friends. It may be a bit verbose, yes, but it could be way worse ;-)
>
>
Yes, I think that Eigen's approach to have proxy objects(arrays) for
elementwise operation : x.array()*y.array() , is a lot of work for barely
no gain, so I'm clearly in favor of keeping things unambiguous and simple,
albeit slightly verbose :)
> > Anyway, my problem is that the
> > VIENNACL_GENERATE_BINARY_ELEMENTOPERATION_OVERLOADS which generates
> > functions and function overloads for element_* does not handle
> > implicit_vector<>. For now, I can just add the proper overloads. But my
> > problem is actually that, right now, implicit_vector<>'s meaning has
> > diverged, with the use of the kernel generator.
> >
> > scalar_vector<float> v(N,0);
> > x += v;
> > y = element_less_than(x,v);
> >
> > makes perfect sense when using the OpenCL backend, but does not make
> > sense with the OPENMP and the CUDA backend.
> > How to handle this divergence? It does look extremely complicated to me.
>
> Since we don't know until runtime which backend is in use, the only
> clean appraoch is to throw an exception for cases where there is no
> implementation in the other backends.
>
> 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?
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
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?
Best regards,
Philippe
> 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
>
------------------------------------------------------------------------------
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
