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::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.
>
>
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.
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
