Re: [Cython] speed.pypy.org
Robert Bradshaw, 26.04.2011 19:52: On Tue, Apr 26, 2011 at 7:50 AM, Stefan Behnel wrote: Stefan Behnel, 15.04.2011 22:20: Stefan Behnel, 11.04.2011 15:08: I'm currently discussing with Maciej Fijalkowski (PyPy) how to get Cython running on speed.pypy.org (that's what I wrote "cythonrun" for). If it works out well, we may have it up in a couple of days. ... or maybe not. It may take a little longer due to lack of time on his side. I would expect that Cython won't be a big winner in this game, given that it will only compile plain untyped Python code. It's also going to fail entirely in some of the benchmarks. But I think it's worth having it up there, simply as a way for us to see where we are performance-wise and to get quick (nightly) feed-back about optimisations we try. The benchmark suite is also a nice set of real-world Python code that will allow us to find compliance issues. Ok, here's what I have so far. I fixed a couple of bugs in Cython and got at least some of the benchmarks running. Note that they are actually simple ones, only a single module. Basically all complex benchmarks fail due to known bugs, such as Cython def functions not accepting attribute assignments (e.g. on wrapping). There's also a problem with code that uses platform specific names conditionally, such as WindowsError when running on Windows. Cython complains about non-builtin names here. I'm considering to turn that into a visible warning instead of an error, so that the name would instead be looked up dynamically to let the code fail at runtime *iff* it reaches the name lookup. Anyway, here are the numbers. I got them with "auto_cpdef" enabled, although that doesn't even seem to make that a big difference. The baseline is a self-compiled Python 2.7.1+ (about a month old). [numbers stripped] And here's the shiny graph: https://sage.math.washington.edu:8091/hudson/job/cython-devel-benchmarks-py27/lastSuccessfulBuild/artifact/chart.html It gets automatically rebuilt by this Hudson job: https://sage.math.washington.edu:8091/hudson/job/cython-devel-benchmarks-py27/ Cool. Any history stored/displayed? No. Also, the variances are rather large depending on the load of the machine. Hudson/Jenkins and all its subprocesses run with a high CPU niceness and I/O niceness, so don't expect reproducible results. Actually, if we want a proper history, I'd suggest a separate codespeed installation somewhere. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] Compiler error when @staticmethod is used in cdef class
Hello, I am using Cython 0.14.1 with Python 2.7.1 on OSX 10.6.7 The following code: --- cdef class Test: @staticmethod def func(): print "Static method" --- gives error when being cythoned: "Method func has wrong number of arguments (0 declared, 1 or more expected)" And if one adds some parameters to this method (like "def func(a, b):"), cython crashes with exception: --- ... long stack trace ... File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/Cython-0.14-py2.7-macosx-10.6-intel.egg/Cython/Compiler/TypeSlots.py", line 100, in fixed_arg_type return self.format_map[self.fixed_arg_format[i]] KeyError: 'T' --- So, is there a way to create static methods in cdef classes? This workaround seems to work, but it is a bit ugly: --- def func(a, b): print "Static method" cdef class Test: func = func --- Best regards, Bogdan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Compiler error when @staticmethod is used in cdef class
On 27 April 2011 12:45, Bogdan Opanchuk wrote: > Hello, > > I am using Cython 0.14.1 with Python 2.7.1 on OSX 10.6.7 > > The following code: > --- > cdef class Test: > @staticmethod > def func(): > print "Static method" > --- > gives error when being cythoned: "Method func has wrong number of > arguments (0 declared, 1 or more expected)" > > And if one adds some parameters to this method (like "def func(a, > b):"), cython crashes with exception: > --- > ... long stack trace ... > File > "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/Cython-0.14-py2.7-macosx-10.6-intel.egg/Cython/Compiler/TypeSlots.py", > line 100, in fixed_arg_type > return self.format_map[self.fixed_arg_format[i]] > KeyError: 'T' > --- > > So, is there a way to create static methods in cdef classes? This > workaround seems to work, but it is a bit ugly: > --- > def func(a, b): > print "Static method" > > cdef class Test: > func = func > --- > > Best regards, > Bogdan > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > This issue has bugged my from the fist day I've started to use Cython. However, never got time to look for a fix. Moreover, I think using @classmethod is better than @staticmethod. @classmethod gives you some extra context (the class) that could be useful in the case of inheritance, specially if your method is a factory function. So, as a workaround, try to use @classmethod, from an API point of view they are very similar, and you can take advantage of @classmethod extra context in the future. -- Lisandro Dalcin --- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169 ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] speed.pypy.org
On Wed, Apr 27, 2011 at 12:45 AM, Stefan Behnel wrote: > Robert Bradshaw, 26.04.2011 19:52: >> >> On Tue, Apr 26, 2011 at 7:50 AM, Stefan Behnel wrote: >>> >>> Stefan Behnel, 15.04.2011 22:20: Stefan Behnel, 11.04.2011 15:08: > > I'm currently discussing with Maciej Fijalkowski (PyPy) how to get > Cython > running on speed.pypy.org (that's what I wrote "cythonrun" for). If it > works out well, we may have it up in a couple of days. ... or maybe not. It may take a little longer due to lack of time on his side. > I would expect that Cython won't be a big winner in this game, given > that > it will only compile plain untyped Python code. It's also going to fail > entirely in some of the benchmarks. But I think it's worth having it up > there, simply as a way for us to see where we are performance-wise and > to > get quick (nightly) feed-back about optimisations we try. The benchmark > suite is also a nice set of real-world Python code that will allow us > to > find compliance issues. Ok, here's what I have so far. I fixed a couple of bugs in Cython and got at least some of the benchmarks running. Note that they are actually simple ones, only a single module. Basically all complex benchmarks fail due to known bugs, such as Cython def functions not accepting attribute assignments (e.g. on wrapping). There's also a problem with code that uses platform specific names conditionally, such as WindowsError when running on Windows. Cython complains about non-builtin names here. I'm considering to turn that into a visible warning instead of an error, so that the name would instead be looked up dynamically to let the code fail at runtime *iff* it reaches the name lookup. Anyway, here are the numbers. I got them with "auto_cpdef" enabled, although that doesn't even seem to make that a big difference. The baseline is a self-compiled Python 2.7.1+ (about a month old). >>> >>> [numbers stripped] >>> >>> And here's the shiny graph: >>> >>> >>> https://sage.math.washington.edu:8091/hudson/job/cython-devel-benchmarks-py27/lastSuccessfulBuild/artifact/chart.html >>> >>> It gets automatically rebuilt by this Hudson job: >>> >>> >>> https://sage.math.washington.edu:8091/hudson/job/cython-devel-benchmarks-py27/ >> >> Cool. Any history stored/displayed? > > No. Also, the variances are rather large depending on the load of the > machine. Of course, that would make the history rather than a snapshot all the more useful. > Hudson/Jenkins and all its subprocesses run with a high CPU > niceness and I/O niceness, so don't expect reproducible results. > > Actually, if we want a proper history, I'd suggest a separate codespeed > installation somewhere. Makes sense. How many CPU-hours does it take? If it's not to intensive, we could probably run it, say, daily as a normal-priority job. - Robert ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] speed.pypy.org
Robert Bradshaw, 27.04.2011 19:08: On Wed, Apr 27, 2011 at 12:45 AM, Stefan Behnel wrote: Actually, if we want a proper history, I'd suggest a separate codespeed installation somewhere. Makes sense. How many CPU-hours does it take? Including the Cython build, it's more like 25 minutes currently, given that we only support a smaller part of the benchmark suite. It will obviously take longer when we start supporting the larger benchmarks, such as Django templates or Twisted. If it's not to intensive, we could probably run it, say, daily as a normal-priority job. We could certainly do that for now, and check again when we see that it starts running substantially longer. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
