Hey, >> I started going through the code, and you're right, the change isn't >> very large. But it makes sense to split it up as you describe, to keep >> the different semantics different, and same semantics shared (ie, to >> make sure the concepts are as clear as possible). I also have another >> motivation for splitting it up: it would make mapping NumPy/Python >> scalar types to ViennaCL types much more natural, and I could avoid a >> lot of duplication. > > I had a go at patching ViennaCL as I described, and pushed up the two > revisions to my pyviennacl repo on github. A patch, excluding the bits > touching pyvienacl and the CMake stuff for my system, is attached > below. I didn't add any extra types or enums, so there's nothing > grouping SYMBOLIC_VECTOR_TYPE_FAMILY with VECTOR_TYPE_FAMILY; it didn't > seem necessary to clear up the code in that way. Of course, everything > compiles as before; but I wasn't sure how to run the tests (despite > figuring it out before), so I haven't checked those for runtime errors.. > > Oddly, when I fixed up my wrapper to deal with the changes, I noticed a > slight decrease in overhead (~10-20us).. > > Anyway, do tell me your thoughts.
Thanks, I applied this already. Tests still pass. You can easily test this yourself by 'make'ing inside build/tests/ and then calling the respective executables. The scheduler tests are scheduler_vector-test-cpu scheduler_vector-test-opencl scheduler_vector-test-cuda scheduler_matrix-test-cpu scheduler_matrix-test-opencl scheduler_matrix-test-cuda with CUDA and OpenCL tests only available with the actual backend enabled. For the scheduler it should suffice to test only one of the backends, though... @Philippe: Please pull the changes into your generator code. I'm still interested in your opinion on the SYMBOLIC_VECTOR and whether you need a separate enum value for this. Best regards, Karli ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
