Cf4ocl Brings Object-Oriented API TO OpenCL

[phoronix]

Phoronix: Cf4ocl Brings Object-Oriented API TO OpenCL

The Cf4ocl project is a GPLv3/LGPLv3 initiative to provide an object-oriented interface to the OpenCL API that's OpenCL version independent...

http://www.phoronix.com/vr.php?view=MTgxMzg

[rohcQaH]

And there I've been using openCL's official object oriented C++ API, with resource tracking and automatic freeing, with exceptions and everything.

If only I had known that there is a layer on top of that where I can use an "object oriented interface" by calling ccl_XX_new and ccl_XX_destroy manually each time, where I can have "user-friendly error management" by passing pointers to an error object to each function and manually checking it afterwards.


Is this a joke or are there some unadvertised features that could justify the horrible API?

[carewolf]

And there I've been using openCL's official object oriented C++ API, with resource tracking and automatic freeing, with exceptions and everything.

If only I had known that there is a layer on top of that where I can use an "object oriented interface" by calling ccl_XX_new and ccl_XX_destroy manually each time, where I can have "user-friendly error management" by passing pointers to an error object to each function and manually checking it afterwards.


Is this a joke or are there some unadvertised features that could justify the horrible API?

Both. It is a C api. Thereby a joke in itself, but justified to the fanatics.

[fakenmc]

And there I've been using openCL's official object oriented C++ API, with resource tracking and automatic freeing, with exceptions and everything.

If only I had known that there is a layer on top of that where I can use an "object oriented interface" by calling ccl_XX_new and ccl_XX_destroy manually each time, where I can have "user-friendly error management" by passing pointers to an error object to each function and manually checking it afterwards.


Is this a joke or are there some unadvertised features that could justify the horrible API?

Dear rohcQah,

I'm the main author of cf4ocl. Thank you for your feedback. However, I'm afraid you missed the point. This is a C framework, thus it brings the advertised features to the C programming language. C++ support comes for free, as you can directly use C libraries from C++. However, for those who exclusively use C++, I'm the first to suggest the official C++ API - even though cf4ocl may still be useful in very specific scenarios (e.g. platform/device-independent profiling, OpenCL version independence, simpler migration between C and C++ projects, consistency).

If your criticism is concerned with cf4ocl being (also) ?advertised? as a C++ library, I accept that argument, and we may eventually change this ?advertisement? if more people give us similar feedback.

If you believe we should all use C++ instead of C, well, that's a long debate which there is no point for me getting into. There a lot of informative and not so informative discussions out there on the web. Why don't we all use Python and the excellent PyOpenCL API instead? It's much simpler and productive than the C++ API, and the real performance gains are in the OpenCL kernels anyway.

cf4ocl simplifies the OpenCL host C API using an approach based on PyOpenCL, while being based on GLib (probably the most used C library ever) and the best practices of the C programming language. Namely, error management is based on GLib error management. If you find these APIs and C best practices are all horrible, you'll certainly find cf4ocl horrible too. Well, the official OpenCL host C API is extremely verbose and quite horrible to use directly, so I'll have to agree with you on that (although I understand why people at Khronos made it that way). Probably that's why cf4ocl and other C wrappers* exist in the first place.

This is an academic project, with several people using it, benefiting from it and giving feedback. Mostly, people have found cf4ocl to be more useful and complete than other OpenCL C wrappers*, to which cf4ocl should be compared, favorably or otherwise. I hope I was able to clarify you. If not, a paper will be published in a (proper) peer-reviewed scientific journal in the near future, which may dispel any doubts you may still have.

Best regards

fakenmc

* Talking of other OpenCL C wrappers, I would very much like to see an independent comparison of these, e.g. SimpleCL, OpenCL utility library, CLU, OCL-MLA, cf4ocl, STDCL, and other ?jokes? out there.

[fakenmc]

Both. It is a C api. Thereby a joke in itself, but justified to the fanatics.

Ok, so this is merely a discussion of which programming language is "best"? Why do people still bother with these types of discussions? All languages have their usefulness. For example, C++ is very useful programming language, and with boost, you get enormous power and control. I usually preferred Java for larger projects (had a couple of old FOSS projects written in Java), but I think in recent years C++ has evolved and aged better. For web development I prefer PHP to Java's overly complex approach (namely deployment). And for implementing stuff really fast, we have Python. C is simpler (in terms of language features), but the final code ends up being much more verbose than C++. However, for lower-level library code and cross-platform compatibility it's still very useful.

I honestly don't see the point in calling "fanatics" to people who might prefer a language over another. I also don't see the point of calling a "joke" to any kind of FOSS, as niche or specific it might be. What is expected to be accomplished with this?

[fakenmc]

And there I've been using openCL's official object oriented C++ API, with resource tracking and automatic freeing, with exceptions and everything.

If only I had known that there is a layer on top of that where I can use an "object oriented interface" by calling ccl_XX_new and ccl_XX_destroy manually each time, where I can have "user-friendly error management" by passing pointers to an error object to each function and manually checking it afterwards.


Is this a joke or are there some unadvertised features that could justify the horrible API?

Dear rohcQah,

I'm the main author of cf4ocl. Thank you for your feedback. However, I'm afraid you missed the point. This is a C framework, thus it brings the advertised features to the C programming language. C++ support comes for free, as you can directly use C libraries from C++. However, for those who exclusively use C++, I'm the first to suggest the official C++ API - even though cf4ocl may still be useful in very specific scenarios (e.g. platform/device-independent profiling, OpenCL version independence, simpler migration between C and C++ projects, consistency).

If your criticism is concerned with cf4ocl being (also) “advertised” as a C++ library, I accept that argument, and may eventually change this “advertisement” if more people give us similar feedback.

If you believe we should all use C++ instead of C, well, that's a long debate which there is no point for me getting into. Why don't we all use Python and the excellent PyOpenCL API instead? It's much simpler and productive than the C++ API, and the real performance gain are in the OpenCL kernels anyway.

cf4ocl simplifies the OpenCL host C API using an approach inspired by PyOpenCL, while being based on GLib (probably the most used C library ever) and the best practices of the C programming language. Namely, error management is based on GLib error management. If you find these APIs and C best practices are all horrible, you'll certainly find cf4ocl horrible too. Well, the official OpenCL host C API is extremely verbose and quite horrible to use directly, so I'll have to agree with you on that (although I understand why people at Khronos made it that way). Probably that's why cf4ocl and other C wrappers* exist in the first place.

This is an academic project, with several people using it, benefiting from it and giving feedback. Mostly, people have found cf4ocl to be more useful and complete than other OpenCL C wrappers*, to which cf4ocl should be compared, favorably or otherwise. I hope I was able to clarify you. If not, a paper will be published in a (proper) peer-reviewed scientific journal in the near future, which may dispel any doubts you may still have.

Best regards

fakenmc

* Talking of other OpenCL C wrappers, I would very much like to see an independent comparison of these, e.g. SimpleCL, OpenCL utility library, CLU, OCL-MLA, cf4ocl, STDCL, and other “jokes” out there.

[rohcQaH]

However, for those who exclusively use C++, I'm the first to suggest the official C++ API - even though cf4ocl may still be useful in very specific scenarios (e.g. platform/device-independent profiling, OpenCL version independence, simpler migration between C and C++ projects, consistency).

Fair enough.

If your criticism is concerned with cf4ocl being (also) ?advertised? as a C++ library, I accept that argument, and we may eventually change this ?advertisement? if more people give us similar feedback.

mostly. I don't trust michael's headlines, so I checked the project's website. I still don't know why I'd want it, and the examples I checked didn't strike me as particularly impressive either. Maybe a better introduction on the website could be helpful.

If you believe we should all use C++ instead of C, well, that's a long debate which there is no point for me getting into. There a lot of informative and not so informative discussions out there on the web. Why don't we all use Python and the excellent PyOpenCL API instead? It's much simpler and productive than the C++ API, and the real performance gains are in the OpenCL kernels anyway.

Don't be so quick to judge. In my current project, the only language that can guarantee high performance is C++.

We have large data objects with different precision. For the sake of the argument, let's say they're simple vector<char>, vector<int>, vector<double> etc. Just storing all numbers as double is slow and memory hungry. But differentiating between the types is only feasible with template programming:
template<typename T> do_something(vector<T> &vec) { ...}
instantiates the function once for each precision.
We can also use opencl on them, by the magic of "typedef char VECTOR_TYPE", but as you know, not every operation on data (even vector data) is a good fit for the GPU. We need both CPU and GPU based high-performance functions, and the only language that can do both is C++.

If you find these APIs and C best practices are all horrible, you'll certainly find cf4ocl horrible too.

I find any API with manual error checking and manual resource cleanup to be needlessly verbose and error-prone. I understand that it's the best C can offer, but that's a restriction I would not voluntarily place on myself. But it's your project, it's your choice.


Thanks for taking the time to reply.

[fakenmc]

Fair enough.

mostly. I don't trust michael's headlines, so I checked the project's website. I still don't know why I'd want it, and the examples I checked didn't strike me as particularly impressive either. Maybe a better introduction on the website could be helpful.


Don't be so quick to judge. In my current project, the only language that can guarantee high performance is C++.

We have large data objects with different precision. For the sake of the argument, let's say they're simple vector<char>, vector<int>, vector<double> etc. Just storing all numbers as double is slow and memory hungry. But differentiating between the types is only feasible with template programming:
template<typename T> do_something(vector<T> &vec) { ...}
instantiates the function once for each precision.
We can also use opencl on them, by the magic of "typedef char VECTOR_TYPE", but as you know, not every operation on data (even vector data) is a good fit for the GPU. We need both CPU and GPU based high-performance functions, and the only language that can do both is C++.


I find any API with manual error checking and manual resource cleanup to be needlessly verbose and error-prone. I understand that it's the best C can offer, but that's a restriction I would not voluntarily place on myself. But it's your project, it's your choice.


Thanks for taking the time to reply.

Thank you for the reply and for the feedback. We'll take it into account.

Best regards,

fakenmc