Hi Oswin, >> Unfortunately, C++ template metaprogramming is not very friendly to >> exchanging library interfaces at this point, free functions would >> be a lot easier. > I know, I have looked into the interfaces and figured that there might > be some rough edges to get around. My biggest concern are naming > collisions which might make 1:1 replacements hard, e.g. > ublas/shark::blas::matrix_expression vs viennacl::matrix_expression, > which mean different things. Also, my library supports mixing of > row/column major in expressions which is not supported by viennacl yet, > therefore I expect some clashes there.
yeah, I bet that any attempt of trying to 'exchange' libraries based on such expression template magic will not work satisfactorily. This is too much an 'accident' of C++... ;-) > My current plan would be to use my expression system as frontend and map > that to the computational kernels of viennaCL in the same way I did it > with the ATLAS backend - just with a few more bells and whistles to > ensure that cpu stuff only interacts with cpu stuff and gpu-stuff only > with gpu. > > this means i would use the exposed interface in e.g. > viennacl/linalg/opencl/matrix_operations.hpp and more or less ignore the > expression templates. If you want to have backend-independence, use the functions in viennacl/linalg/XXXXX_operations.hpp instead. These functions dispatch into the respective backend. At the same time, once you are down to mapping your expression system to the computational kernels, you can map them either way. For example, once you have identified a vector addition, you can either call 'x = y + z;' or 'viennacl::linalg::avbv(..)'. The former is more stable API-wise. > Is this okay or is this somehow "unstable" or > "might change randomly in future releases"? The backend function names don't have any guarantee on forward-compatibility, but it is very unlikely to change in the ViennaCL 1.x.y release series. FYI: ViennaCL 2.x will provide all functionality via a shared C library in order to make cases such as the one you describe much easier. This means that there will be stable function names for all operations. An optional C++ layer will sit on top, rather than the other way round as it is the case now... Best regards, Karli ------------------------------------------------------------------------------ _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
