Hi,
2014-04-29 15:59 GMT+02:00 Karl Rupp <r...@iue.tuwien.ac.at>:
> 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.
>
Actually, I think that most of the code bloat comes from the ClGet*Info()
calls. There are dozens of methods in ocl::device() to handle this, while
this could be simply handled using a proper templated method. I notice that
I already did that work in viennacl/ocl/infos.hpp but that it is somewhat
not used. Is there any drawback with using :
viennacl::ocl::info<CL_DEVICE_NAME>(viennacl::ocl::device const & d);
instead of
viennacl::ocl::device::name() ?
Perhaps we could rename it so that the call becomes
viennacl::ocl::info<VIENNACL_DEVICE_NAME>(viennacl::ocl::device const &),
so that VIENNACL_DEVICE_NAME could be used with CUDA/OpenMP devices too if
ever needed.
>
>
>
> 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.
Oh, yes, that's right. ViennaCL is already using an exception-based
mechanism, but this would be of course easier to change it ourself if we
ever need it.
>
>
> -> 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?
>
>
I have just noticed that these maybe extensions, such as :
CL_PLATFORM_NOT_FOUND_KHR
I'll look into that.
>
>
> -> 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's true, most of the time is spent in template instantiation rather than
parsing. I remember having benchmarked it on an older version of ViennaCL.
I think that 1000 lines could be saved by using viennacl::ocl::infos<>
instead of viennacl::ocl::{device|program|kernel|chocolatebar}::*().
>
>
> -> 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.
>
>
We actually had a warning in cl.h recently (or was it in cl.hpp?), didn't
we? :P So we might have to deal with warnings in cl.h as well. I agree that
we don't want a riot with angry people shouting "We are the 1%".
>
>
> -> 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.
Actually, I came accross a lot of inconveniences while plugging a simple
caching mechanism into viennacl::ocl::context::add_program(). It's not at
all about the generator ;) The inconveniences however had to do with
unintegrated use of STL vectors and cumbersome clGet*Info. Adding methods
would not have solved the problem because the corresponding viennacl
objects were not created at this point (but the cl handles were)
>
>
> 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 :-)
>
I think you're right... Plus, we need information such as the device
macro-architecture, which will probably never be provided by the OpenCL
standards.
I'm however in favor of a small refactoring which would involve using
viennacl::ocl::infos<> instead of the corresponding methods. What do you
think about it?
Philippe
>
> 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
