Hi, > So I can't help but to bring up this topic :) Is there any reason why > we're using the OpenCL C API instead of the C++ one?
Yes, the reason is simple: The C++ API was standardized quite some time *after* the development of ViennaCL started. > It seems like we could save several thousands of lines of code (and gain > a lot of clarity) by using the C++ API directly. Well, I'm not so sure about that actually. I'd more conservatively estimate it in the range of hundreds. > Of course, we would > keep the ocl::device/context/whatever. I see a couple of reasons why we > would want to do that: > -> For now, we have to use VIENNACL_ERR_CHECK(err) after each internal > call to the C API. Since it's cumbersome, i've noticed that there are a > lot of places in the code where we would just ignore some error checking > for the sake of clarity. If we used the C++ API, then we could use the > C++ exceptions internally and wouldn't have to bother with all these > error checking. As you certainly know, I'd like the ViennaCL core to open up to other languages with version 2.0.0, eventually making it a C shared library with a C++ layer on top. Introducing a C++ exception-based error handling at this stage looks like a step in the wrong direction under these long-term perspectives. > -> It seems like the list of the ViennaCL exception is not up-to-date. > If we forget to handle a case, then we get ocl::unknown_error, while the > error is properly handled by the OpenCL C++ API. Which cases aren't covered now? > -> We could save literally thousands of lines of code. I'm ready to bet > that it could relieve the compiler and reduce the compilation times Hundreds ;-) I bet against your bet that compilation times reduce notably for two reasons: - the OpenCL C++ API just adds yet another type-hierarchy - most of the compilation time is spent in other parts of the library However, feel free to prove me wrong ;-) > -> It would be easier to maintain. There is a whole community bugfixing > the cl.hpp file, and we are more likely to have bugs in our C calls > rather than our C++ calls How do you intend to deal with bugs or warnings obtained from cl.hpp? We can handle all bugs and warnings in our codes, but we might have a hard time dealing with warnings or even errors in older versions of cl.hpp. Yes, it won't be noticed by 99% of our users, but I also care about the remaining one percent. > -> It doesn't add any external dependency. True. > -> I think that when we need to deal with more complicated things such > as multiple devices, we'll gain in productivity and robustness by using > the C++ API. Robustness might be true. In which way are we going to gain in productivity? I understand that you may gain in productivity when dealing with the generator, but most other parts of ViennaCL are sitting on top of a backend-agnostic layer, not getting in touch with OpenCL directly. So the question is whether you consider the additional effort of replacing the current use of the C-API worth it. > On the other hand, I cannot see any functionnality in the C API which > isn't wrapped in the C++ one. It sure would take quite a bit of work, > but I'm ready to handle it myself if there is no objection. I'm not objecting to a change, but I also want to submit that I don't think it is worth the effort. If you're fine with the effort (including the testing and bugfixes to bring it to a state comparable to the current), please go ahead :-) Best regards, Karli ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
