Re: [ViennaCL-devel] OpenCL C++ API
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::infoCL_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::infoVIENNACL_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)
Re: [ViennaCL-devel] OpenCL C++ API
Hi,
2014-04-29 16:54 GMT+02:00 Karl Rupp r...@iue.tuwien.ac.at:
Hi,
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::infoCL_DEVICE_NAME(viennacl::ocl::device const d);
instead of
viennacl::ocl::device::name() ?
Yes, we discussed that. The reason is that with info() one cannot buffer
the results.
Perhaps we could rename it so that the call becomes
viennacl::ocl::infoVIENNACL_DEVICE_NAME(viennacl::ocl::device const
), so that VIENNACL_DEVICE_NAME could be used with CUDA/OpenMP devices
too if ever needed.
I think that's never needed.
- 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}::*().
Yes and no. We might save some milliseconds from this, but it's getting
harder for us to document and users will have a harder time finding it.
Also, return values cannot be buffered, see above. That was the point of
dropping infos. I can dig out the other thread if you like.
- 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%.
Yes, it was a warning in the OpenCL 1.1 headers, which is fixed in OpenCL
1.2. This was in a trivial C-header. You can imagine how things can get
worse with C++.
- 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)
This sounds to me like the OpenCL C++ API won't make a difference here ;-)
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.
To get informations such as NUMA-domains, we might even have to resort
Re: [ViennaCL-devel] OpenCL C++ API
Hi, See above :-) There are good reasons for dropping infos(), particularly as we cannot assume that each OpenCL SDK returns the requested information as rapidly as we might need it. Hmm, then a good solution would be to internally use infos whenever a viennacl::ocl object is not yet created or cached ; it would centralize the C API calls into the infos.hpp header instead of the class definitions. I can do that, and add similar methods for ocl::program and ocl::kernel if needed. we agreed that we will get rid of infos entirely once all other classes get the respective members. Why should we torture the compiler with member functions, which redirect to a templated function just to call a C routine? If you want to use infos as a convenience layer which gets instantiated for a few types, I'm okay with that. But unconditionally using it in all member functions to come will certainly not result in the reduced compilation times you were suggesting initially. ;-) 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
