Re: [Cython] OpenCL support
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. 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. Sturla ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] OpenCL support
On Tue, Feb 7, 2012 at 5:52 AM, Sturla Molden 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. > >> 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@python.org > http://mail.python.org/mailman/listinfo/cython-devel ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] OpenCL support
On 7 February 2012 13:52, Sturla Molden 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 don't know why you think that is necessary. Obviously Cython's translated opencl would also be compiled at runtime (or loaded from a cache). If you mean you can't do string interpolation, I don't see why you would need that. >> 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. > > Sturla > That is not very constructive input. If you use PyOpenCL you have to basically rethink and rewrite your kernels just for OpenCL. That is far from trivial and there is not much pyopencl does to keep you away from the pain of OpenCL and general GPU computing. There are existing approaches (compiler directives for C or Fortran) to do similar things, and an OpenMP (sub-)committee is working on adding/defining such features to the standard. Why? Because GPU programming is still a major pain in the ass. And although automatic translation will probably not yield the best performance for your particular hardware as a handwritten version, it will have saved you hours of coding and possibly rewriting. > > > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] OpenCL support
On 07.02.2012 18:22, Dimitri Tcaciuc wrote: I'm not sure I understand you, maybe you could elaborate on that? OpenCL code is a text string that is compiled when the program runs. So it can be generated from run-time data. Think of it like dynamic HTML. 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. You can use PyOpenCL or OpenCL C or C++ headers with Cython. The latter you just use as you would with any other C or C++ library. You don't need to change the compiler to use a library: It seems like you think OpenCL is compiled from code when you build the program. It is actually compiled from text strings when you run the program. It is meaningless to ask if Cython supports OpenCL because Cython supports any C library. Sturla ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] OpenCL support
On 7 February 2012 17:22, Dimitri Tcaciuc wrote: > On Tue, Feb 7, 2012 at 5:52 AM, Sturla Molden 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. >> >>> 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@python.org >> http://mail.python.org/mailman/listinfo/cython-devel > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] OpenCL support
On 7 February 2012 18:01, mark florisson wrote: > On 7 February 2012 17:22, Dimitri Tcaciuc wrote: >> On Tue, Feb 7, 2012 at 5:52 AM, Sturla Molden 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@python.org >>> http://mail.python.org/mailman/listinfo/cython-devel >> ___ >> cython-devel mailing list >> cython-devel@python.org >> http://mail.python.org/mailman/listinfo/cython-devel ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] OpenCL support
On 7 February 2012 17:58, Sturla Molden wrote: > On 07.02.2012 18:22, Dimitri Tcaciuc wrote: > >> I'm not sure I understand you, maybe you could elaborate on that? > > > OpenCL code is a text string that is compiled when the program runs. So it > can be generated from run-time data. Think of it like dynamic HTML. > > >> 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. > > > You can use PyOpenCL or OpenCL C or C++ headers with Cython. The latter you > just use as you would with any other C or C++ library. You don't need to > change the compiler to use a library: It seems like you think OpenCL is > compiled from code when you build the program. It is actually compiled from > text strings when you run the program. It is meaningless to ask if Cython > supports OpenCL because Cython supports any C library. > Sturla, in general we appreciate your input, you usually have useful things to say. But I really don't believe you have read the CEP, so please do, and then comment on what is proposed there if you want. Here is the link: http://wiki.cython.org/enhancements/opencl > Sturla > > > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] memoryview slices can't be None?
On 5 February 2012 22:03, mark florisson wrote: > On 2 February 2012 21:38, Dag Sverre Seljebotn > wrote: >> On 02/02/2012 10:16 PM, mark florisson wrote: >>> >>> On 2 February 2012 12:19, Dag Sverre Seljebotn >>> wrote: I just realized that cdef int[:] a = None raises an exception; even though I'd argue that 'a' is of the "reference" kind of type where Cython usually allow None (i.e., "cdef MyClass b = None" is allowed even if type(None) is NoneType). Is this a bug or not, and is it possible to do something about it? Dag Sverre ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel >>> >>> >>> Yeah I disabled that quite early. It was supposed to be working but >>> gave a lot of trouble in cases (segfaults, mainly). At the time I was >>> trying to get rid of all the segfaults and get the basic functionality >>> working, so I disabled it. Personally, I have never liked how things >> >> >> Well, you can segfault quite easily with >> >> cdef MyClass a = None >> print a.field >> >> so it doesn't make sense to slices different from cdef classes IMO. >> >> >>> can be None unchecked. I personally prefer to write >>> >>> cdef foo(obj=None): >>> cdef int[:] a >>> if obj is None: >>> obj = ... >>> a = obj >>> >>> Often you forget to write 'not None' when declaring the parameter (and >>> apparently that it only allowed for 'def' functions). >>> >>> As such, I never bothered to re-enable it. However, it does support >>> control flow with uninitialized slices, and will raise an error if it >>> is uninitialized. Do we want this behaviour (e.g. for consistency)? >> >> >> When in doubt, go for consistency. So +1 for that reason. I do believe that >> setting stuff to None is rather vital in Python. > > Yeah I think we should go back to this discussion :) Checking for None > and allowing slices to be None is simply very convenient, and doesn't > involve any drastic changes. I was never really against it, I just > never got around to implementing it. We should now be able to use None memoryview slices: https://github.com/markflorisson88/cython/commit/a24495ac1348926af5e085334c4e6a960e723f87 They also coerce back to None when coercing to object. >> What I typically do is more like this: >> >> def f(double[:] input, double[:] out=None): >> if out is None: >> out = np.empty_like(input) >> ... >> >> Having to use another variable name is a bit of a pain. (Come on -- do you >> use "a" in real code? What do you actually call "the other obj"? I sometimes >> end up with "out_" and so on, but it creates smelly code quite quickly.) >> >> It's easy to segfault with cdef classes anyway, so decent nonechecking >> should be implemented at some point, and then memoryviews would use the same >> mechanisms. Java has decent null-checking... >> >> >> Dag Sverre >> ___ >> cython-devel mailing list >> cython-devel@python.org >> http://mail.python.org/mailman/listinfo/cython-devel ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
