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::info<CL_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::info<VIENNACL_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
to libraries such as hwloc, yes.
> 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?
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.
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
