Hi,
Yes, I feel like we would to do this whenever the vector and matrix kernels
are handled by the same backend ( generator, blas linker, or whatever).
Indeed, there are some operators in matrix_base so it will be complicated
to split things up. The core circular dependency seems to be in the
scheduler, which is required for the operators, but at the same time
requires the operator (through the use of traits on matrix_base<>*
objects). I'll see what I can do to decouple the operators from the
attributes. Nightmares in perspective. :D
Philippe
2014-05-26 17:10 GMT+02:00 Karl Rupp <r...@iue.tuwien.ac.at>:
> Hi,
>
>
> > This has been a nightmare to make the opencl kernels device-specific.
>
>> I'm facing a dependency problem which traits cannot solve. The reason is
>> the following:
>>
>> -> The kernel generator requires some traits (row_major(), size(),
>> internal_size2(), etc.)
>> -> The generator is now included in linalg/opencl/kernels/vector.hpp,
>> hence it is included from viennacl/vector.hpp
>> -> There is no dependency between vector.hpp and matrix.hpp, which is a
>> very good thing.
>>
>
> I noticed this somewhat circular dependency when I checked that all
> headers are self-sufficient. It could be resolved via removing unnecessary
> includes back then, but it wasn't easy.
>
>
>
> Considering all these informations, vector-only files such as
>> vector_float_double-test-opencl will fail to compile because the
>> generator uses e.g. traits:row_major(), and matrix.hpp is not included
>> (so matrix_base is declared but not defined).
>>
>> An extremly bad solution would be to have two versions of the generator
>> (one for vector-only statements, one for other).
>>
>
> Yes, this is indeed bad ;-)
>
>
> A better option would
>> be to split matrix.hpp into two files, one containing the definition of
>> the class only, to make the traits usable without having to include the
>> whole library.
>>
>> What do you think about it?
>>
>
> Is it enough to split off the class definition in matrix.hpp? There are
> some operator overloads defined inside the class definition right now for
> reasons of implicit conversions, so it may be quite hard to split them off.
> In the end, it may not even be enough to split the files, because the
> circular dependency is a data type dependency, not just a file level
> dependency. I thought about splitting matrix_base into a type that takes
> care of the user interface (operator overloads, etc.) and a type which only
> holds the data (and can be included by the generator to get information
> such as row-major, etc.). As this would probably be a good share of the
> preparation for linking with external BLAS libraries, we might as well want
> to go down that route anyway.
>
> Either way, I'm afraid that this is not just a tiny refactoring, but
> touches larger (internal) parts of the library. If a simple file split is
> enough, I'm not against it - just don't expose it to the user.
>
> Best regards,
> Karli
>
>
>
------------------------------------------------------------------------------
The best possible search technologies are now affordable for all companies.
Download your FREE open source Enterprise Search Engine today!
Our experts will assist you in its installation for $59/mo, no commitment.
Test it for FREE on our Cloud platform anytime!
http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
_______________________________________________
ViennaCL-devel mailing list
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
