[Cython] OpenCL support

[mark florisson]

On 7 February 2012 18:01, mark florisson <markflorisson88 at gmail.com> wrote:
> On 7 February 2012 17:22, Dimitri Tcaciuc <dtcaciuc at gmail.com> wrote:
>> On Tue, Feb 7, 2012 at 5:52 AM, Sturla Molden <sturla at molden.no> wrote:
>>> On 05.02.2012 23:39, Dimitri Tcaciuc wrote:
>>>
>>>> 3. Does it make sense to make OpenCL more explicit?
>>>
>>>
>>> No, it takes the usefuness of OpenCL away, which is that kernels are text
>>> strings and compiled at run-time.
>>
>> I'm not sure I understand you, maybe you could elaborate on that? By
>> "explicit" I merely meant that the user will explicitly specify that
>> they're working on OpenCL-enabled array or certain bit of Cython code
>> will get compiled into OpenCL program etc.
>
> I gave that some thought as well, like 'cdef double[::view.gpu, :]
> myarray', which would mean that the data is on the gpu. Generally
> though, I think it kind of defeats the purpose. E.g. if you have small
> arrays you probably don't want anything to be on the gpu, whereas if
> you have larger ones and sufficient computation operating on them, it
> might be worthwhile. The point is, as a user you don't care, you want
> your runtime to make a sensible decision. If you don't want anything
> to do with OpenCL, you can disable it, or if you want to only ever
> stay on the CPU, you could "pin" it there.

As for code regions, only operations on memoryview slices (most
notably vector operations) and prange sections would be compiled (and
only if possible at all). Maybe normal loops could be compiled as
well, but it's best to start with prange only.

>>>
>>>> Heuristics and
>>>> automatic switching between, say, CPU and GPU is great for eg. Sage
>>>> users, but maybe not so much if you know exactly what you're doing
>>>> with your machine resources. E.g just having a library with thin
>>>> cython-adapted wrappers would be awesome. I imagine this can be
>>>> augmented by arrays having a knowledge of device-side/client-side
>>>> (which would go towards addressing the issue 1. above)
>>>
>>>
>>> Just use PyOpenCL and manipulate kernels as text. Python is excellent for
>>> that - Cython is not needed. If you think using Cython instead of Python
>>> (PyOpenCL and NumPy) will be important, you don't have a CPU bound problem
>>> that warrants the use of OpenCL.
>>
>> Again, not sure what you mean here. As I mentioned in the thread,
>> PyOpenCL worked quite fine, however if Cython is getting OpenCL
>> support, I'd much rather use that than keeping a dependency on another
>> library.
>>
>>> Sturla
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> cython-devel mailing list
>>> cython-devel at python.org
>>> http://mail.python.org/mailman/listinfo/cython-devel
>> _______________________________________________
>> cython-devel mailing list
>> cython-devel at python.org
>> http://mail.python.org/mailman/listinfo/cython-devel