[Cython] Cython's view on a common benchmark suite (was: Re: [Speed] Buildbot Status)
Brett Cannon, 01.02.2012 18:25: > to prevent this from either ending up in a dead-end because of this, we > need to first decide where the canonical set of Python VM benchmarks are > going to live. I say hg.python.org/benchmarks for two reasons. One is that > Antoine has already done work there to port some of the benchmarks so there > is at least some there that are ready to be run under Python 3 (and the > tooling is in place to create separate Python 2 and Python 3 benchmark > suites). Two, this can be a test of having the various VM contributors work > out of hg.python.org if we are ever going to break the stdlib out for > shared development. At worst we can simply take the changes made at > pypy/benchmarks that apply to just the unladen benchmarks that exists, and > at best merge the two sets (manually) into one benchmark suite so PyPy > doesn't lose anything for Python 2 measurements that they have written and > CPython doesn't lose any of its Python 3 benchmarks that it has created. > > How does that sound? +1 FWIW, Cython currently uses both benchmark suites, that of PyPy (in Py2.7) and that of hg.python.org (in Py2.7 and 3.3), but without codespeed integration and also without a dedicated server for benchmark runs. So the results are unfortunately not accurate enough to spot minor changes even over time. https://sage.math.washington.edu:8091/hudson/view/bench/ We would like to join in on speed.python.org, once it's clear how the benchmarks will be run and how the data uploads work and all that. It already proved a bit tricky to get Cython integrated with the benchmark runner on our side, and I'm planning to rewrite that integration at some point, but it should already be doable to get "something" to work now. I should also note that we don't currently support the whole benchmark suite, so there must be a way to record individual benchmark results even in the face of failures in other benchmarks. Basically, speed.python.org would be useless for us if a failure in a single benchmark left us without any performance data at all, because it will still take us some time to get to 100% compliance and we would like to know if anything on that road has a performance impact. Currently, we apply a short patch that adds a try-except to the benchmark runner's main loop before starting the measurements, because otherwise it would just bail out completely on a single failure. Oh, and we also patch the benchmarks to remove references to __file__ because of CPython issue 13429, although we may be able to work around that at some point, specifically when doing on-the-fly compilation during imports. http://bugs.python.org/issue13429 Also note that benchmarks that only test C implemented stdlib modules (re, pickle, json) are useless for Cython because they would only end up timing the exact same code as for plain CPython. Another test that is useless for us is the "mako" benchmark, because most of what it does is to run generated code. There is currently no way for Cython to hook into that, so we're out of the game here. We also don't care about program startup tests, obviously, because we know that Cython's compiler overhead plus an optimising gcc run will render them meaningless anyway. I like the fact that there's still an old hg_startup timing result lingering around from the time before I disabled that test, telling us that Cython runs it 99.68% slower than CPython. Got to beat that. 8-) Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] memoryview slices can't be None?
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
Re: [Cython] [cython-users] Re: How to find out where an AttributeError is ignored
On 1 February 2012 18:50, Robert Bradshaw wrote: > On Tue, Jan 31, 2012 at 8:30 AM, mark florisson > wrote: >> On 31 January 2012 02:12, Robert Bradshaw >> wrote: >>> On Fri, Jan 27, 2012 at 1:01 PM, Stefan Behnel wrote: Dag Sverre Seljebotn, 27.01.2012 21:03: > On 01/27/2012 05:58 PM, Stefan Behnel wrote: >> mark florisson, 27.01.2012 17:30: >>> On 27 January 2012 16:22, mark florisson >>> wrote: On 27 January 2012 15:47, Simon King wrote: > Hi all, > > I am still *very* frustrated about the fact that Cython does not tell > where the error occurs. Since about one week, I am adding lots and > lots of lines into Sage that write a log into some file, so that I get > at least some idea where the error occurs. But still: Even these > extensive logs do not provide a hint on what exactly is happening. > > How can I patch Cython such that some more information on the location > of the error is printed? I unpacked Sage's Cython spkg, and did "grep > - > R ignored .", but the code lines containing the word "ignored" did not > seem to be the lines that are responsible for printing the warning > message > Exception AttributeError: 'PolynomialRing_field_with_category' > object has no attribute '_modulus' in ignored > > Can you point me to the file in Sage's Cython spkg which is > responsible for printing the warning? > > Best regards, > Simon These messages are written by PyErr_WriteUnraisable, which is a CPython C API function that writes unraisable exceptions. There are typically two reasons for unraisable exceptions: 1) as Robert mentioned, a function that does not allow propagation of exceptions, e.g. cdef int func(): raise Exception Here there is no way to propagate the raised exception, so instead one should write something like cdef int func() except -1: ... Alternatively one may use 'except *' in case there is no error indicator and Cython should always check, or "except ? -1" which means "-1 may or may not indicate an error". 2) in deallocators or finalizers (e.g. __dealloc__ or __del__) For functions the right thing is to add an except clause, for finalizers and destructors one could use the traceback module, e.g. try: ... except: traceback.print_exc() If this all still doesn't help, try setting a (deferred) breakpoint on __Pyx_WriteUnraisable or PyErr_WriteUnraisable. >>> >>> Actually, I don't see why the default is to write unraisable >>> exceptions. Instead Cython could detect that exceptions may propagate >>> and have callers do the check (i.e. make it implicitly "except *"). > > As for speed, there's optimizations on this, e.g., "except? 32434623" if > the return type is int, "except? 0xf..." if the return type is a > pointer. > > And for floating point, we could make our own NaN -- that's obscure enough > that it could probably be made "except cython.cython_exception_nan" by > default, not "except? cython.cython_exception_nan". The problem with that is that we can't be sure that Cython will be the only caller. So exceptions may still not propagate in cases, and users will have to know about these "obscure" values and that they must deal with them manually then. You could add that we'd just have to disable this when user code takes a pointer from a function, but then, how many rules are there that users will have to learn and remember after such a change? And what's that for a language that changes the calling semantics of a function because way down in the code someone happens to take a pointer to it? >>> Was this not implemented because Cython only knows whether functions >>> may propagate exceptions at code generation time by looking at the >>> presence of an error label? >>> Maybe it could keep code insertion points around for every call to >>> such a potential function and if the function uses the error label >>> have the caller perform the check? Although I do forsee problems for >>> external such functions... maybe Cython could have it's own >>> threadstate regardless of the GIL which would indicate whether an >>> error has occurred? e.g. CyErr_Occurred()? >> >> Yep, those are the kind of reasons why writing unraisable exceptions is >> the >> default. > > Still, I wasn't really advocating this behaviour, just indicating that it's hard
Re: [Cython] memoryview slices can't be None?
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 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)? ___ 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 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.) 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
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. > > 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. With initialized slices the control flow knows when the slices are initialized, or when they might not be (and it can raise a compile-time or runtime error, instead of a segfault if you're lucky). I'm fine with implementing the behaviour, I just always left it at the bottom of my todo list. > 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
