Re: [Cython] 0.16 release
On Sat, Feb 4, 2012 at 10:49 AM, Vitja Makarov wrote: > 2012/1/31 Robert Bradshaw : >> On Sat, Jan 28, 2012 at 8:05 AM, Vitja Makarov >> wrote: >>> 2012/1/26 Jason Grout : On 1/25/12 11:39 AM, Robert Bradshaw wrote: > > install > > https://sage.math.washington.edu:8091/hudson/view/ext-libs/job/sage-build/lastSuccessfulBuild/artifact/cython-devel.spkg > by downloading it and running "sage -i cython-devel.spkg" In fact, you could just do sage -i https://sage.math.washington.edu:8091/hudson/view/ext-libs/job/sage-build/lastSuccessfulBuild/artifact/cython-devel.spkg and Sage will (at least, should) download it for you, so that's even one less step! Jason >>> >>> Thanks for detailed instruction! I've successfully built it. >>> >>> "sage -t -gdb ./" doesn't work, is that a bug? >>> >>> vitja@mchome:~/Downloads/sage-4.8$ ./sage -t -gdb >>> devel/sage/sage/combinat/sf/macdonald.py >>> sage -t -gdb "devel/sage/sage/combinat/sf/macdonald.py" >>> >>> Type r at the (gdb) prompt to run the doctests. >>> Type bt if there is a crash to see a traceback. >>> >>> gdb --args python /home/vitja/.sage//tmp/macdonald_6182.py >>> starting cmd gdb --args python /home/vitja/.sage//tmp/macdonald_6182.py >>> ImportError: No module named site >>> [0.2 s] >>> >>> -- >>> The following tests failed: >>> >>> >>> sage -t -gdb "devel/sage/sage/combinat/sf/macdonald.py"release >>> Total time for all tests: 0.2 seconds >> >> Yes, that's a bug. >> >>> I've found another way to run tests (using sage -sh and then direct >>> python ~/.sage/tmp/...py) >>> >>> So I found one of the problems. Here is minimal cython example: >>> >>> def foo(values): >>> return (0,)*len(values) >>> foo([1,2,3]) >>> >>> len(values) somehow is passed as an integer to PyObject_Multiply() >> >> Yeah, that's a bug too :). > > I've fixed tuple mult_factor bug here: > > https://github.com/cython/cython/commit/2d4b85dbcef885fbdaf6a3b2daef7a017184a56f > > No more segfaults in sage-tests but still 7 errors. > Thanks! I've looked into the other errors and I think it boils down to our use of --disable-function-redefinition being incompatible with how decorators work. Of course that was just a hack, so I've fixed sage to build/startup without using that flag, but there's some strangeness with import order now that I haven't had time to resolve yet. ___ 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 4 February 2012 19:39, Dag Sverre Seljebotn wrote: > On 02/03/2012 07:26 PM, mark florisson wrote: >> >> On 3 February 2012 18:15, Dag Sverre Seljebotn >> wrote: >>> >>> On 02/03/2012 07:07 PM, mark florisson wrote: On 3 February 2012 18:06, mark florisson wrote: > > > On 3 February 2012 17:53, Dag Sverre Seljebotn > wrote: >> >> >> On 02/03/2012 12:09 AM, 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. 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.) >>> >>> >>> >>> >>> No, it was just a contrived example. >>> 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... >>> >>> The problem with none checking is that it has to occur at every >>> point. >> >> >> >> >> Well, using control flow analysis etc. it doesn't really. E.g., >> >> for i in range(a.shape[0]): >> print i >> a[i] *= 3 >> >> can be unrolled and none-checks inserted as >> >> print 0 >> if a is None: raise >> a[0] *= 3 >> for i in range(1, a.shape[0]): >> print i >> a[i] *= 3 # no need for none-check >> >> It's very similar to what you'd want to do to pull boundschecking out >> of >> the >> loop... >> > > Oh, definitely. Both optimizations may not always be possible to do, > though. The optimization (for boundschecking) is easier for prange() > than range(), as you can immediately raise an exception as the > exceptional condition may be issued at any iteration. What do you do > with bounds checking when some accesses are in-bound, and some are > out-of-bound? Do you immediately raise the exception? Are we fine with > aborting (like Fortran compilers do when you ask them for bounds > checking)? And
[Cython] OpenCL support
Hey, I created a CEP for opencl support: http://wiki.cython.org/enhancements/opencl What do you think? Mark ___ 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 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. > 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
Re: [Cython] OpenCL support
Mark, Couple of thoughts based on some experience with OpenCL... 1. This may be going outside the proposed purpose, but some algorithms such as molecular simulations can benefit from a fairly large amount of constant data loaded at the beginning of the program and persisted in between invocations of a function. If I understand the proposal, entire program would need to be within one `with` block, which would certainly be limiting to the architecture. Eg. # run.py from cython_module import Evaluator # Arrays are loaded into device memory here x = Evaluator(params...) for i in range(N): # Calculations are performed with # mostly data in the device memory data_i = x.step() ... 2. AFAIK, given a device, OpenCL basically takes it over (which would be eg. 8 cores on 2 CPU x 4 cores machine), so I'm not sure how `num_cores` parameter would work here. There's the fission extension that allows you to selectively run on a portion of the device, but the idea is that you're still dedicating entire device to your process, but merely giving more organization to your processing tasks, where you have to specify the core numbers you want to use. I may very well be wrong here, bashing is welcome :) 3. Does it make sense to make OpenCL more explicit? 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) Cheers, Dimitri. On Sun, Feb 5, 2012 at 1:57 PM, mark florisson wrote: > Hey, > > I created a CEP for opencl support: http://wiki.cython.org/enhancements/opencl > What do you think? > > Mark > ___ > 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 5 February 2012 22:39, Dimitri Tcaciuc wrote: > Mark, > > Couple of thoughts based on some experience with OpenCL... > > 1. This may be going outside the proposed purpose, but some algorithms > such as molecular simulations can benefit from a fairly large amount > of constant data loaded at the beginning of the program and persisted > in between invocations of a function. If I understand the proposal, > entire program would need to be within one `with` block, which would > certainly be limiting to the architecture. Eg. > > # run.py > from cython_module import Evaluator > > # Arrays are loaded into device memory here > x = Evaluator(params...) > for i in range(N): > # Calculations are performed with > # mostly data in the device memory > data_i = x.step() > ... The point of the proposal is that the slices will actually stay on the GPU as long as possible, until they absolutely need to be copied back (e.g. when you go back to NumPy-land). You can do anything you want in-between (outside any parallel section), e.g. call other functions that run on the CPU, call python functions, whatever. When you continue processing data that is still on the GPU, it will simply continue from there. But point taken, the compiler could think "oh but this is not too much work, and I have more data in main memory than on the GPU, so let me use the CPU and copy that constant data back". So perhaps the pinning should not just work for main memory, stuff could also be pinned on the GPU. Then if there is a "pinning conflict" Cython would raise an exception. > 2. AFAIK, given a device, OpenCL basically takes it over (which would > be eg. 8 cores on 2 CPU x 4 cores machine), so I'm not sure how > `num_cores` parameter would work here. There's the fission extension > that allows you to selectively run on a portion of the device, but the > idea is that you're still dedicating entire device to your process, > but merely giving more organization to your processing tasks, where > you have to specify the core numbers you want to use. I may very well > be wrong here, bashing is welcome :) Oh, yes. I think the num_threads clause could simply be ignored in that context, it's only supposed to be an upper limit. Scheduling hints like chunksize could also be ignored :) > 3. Does it make sense to make OpenCL more explicit? 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) Hm, there are several advantages to supporting this in the language. One is that you can support parallel sections, and that your code can transparently execute in parallel on whatever device the compiler and runtime think will be best. Excluding the cython.parallel stuff I don't think there is enough room for a library, you might as well use pyopencl directly in that case right? Not OpenCL perse, but part of that will also solve the numpy-temporary problem, which we have numexpr for. But it would be more convenient to express oneself natively in the programming language of choice (Cython :). > Cheers, > > > Dimitri. > > On Sun, Feb 5, 2012 at 1:57 PM, mark florisson > wrote: >> Hey, >> >> I created a CEP for opencl support: >> http://wiki.cython.org/enhancements/opencl >> What do you think? >> >> Mark >> ___ >> 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
mark florisson, 06.02.2012 00:12: > On 5 February 2012 22:39, Dimitri Tcaciuc wrote: >> 3. Does it make sense to make OpenCL more explicit? 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) > > Hm, there are several advantages to supporting this in the language. ... and there's always the obvious disadvantage of making the language too complex and magic to learn and understand. Worth balancing. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
