Re: [Cython] compiler performance issue for extended utility code
Vitja Makarov, 07.10.2011 18:01: 2011/10/7 Stefan Behnel: Vitja Makarov, 06.10.2011 23:12: Here is small comparison on compiling urllib.py with cython: ((e8527c5...)) vitja@mchome:~/work/cython-vitek-git/zzz$ time python ../cython.py urllib.py real0m1.699s user0m1.650s sys 0m0.040s (master) vitja@mchome:~/work/cython-vitek-git/zzz$ time python ../cython.py urllib.py real0m2.830s user0m2.790s sys 0m0.030s It's about 1.5 times slower. That's a pretty serious regression for plain Python code then. Again, this needs proper profiling. I've added return statement on top of CythonScope.test_cythonscope, now I have these timings: (master) vitja@mchome:~/work/cython-vitek-git/zzz$ time python ../cython.py urllib.py real0m1.764s user0m1.700s sys 0m0.060s Ok, then it's only a bug. "create_testscope" is on by default in Main.py, Context.__init__(). I don't know what it does exactly, but my guess is that the option should a) be off by default and b) should rather be passed in by the test runner as part of the compile options rather than being a parameter of the Context class. AFAICT, it's currently only used in TreeFragment.py, where it is being switched off explicitly for parsing code snippets. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] compiler performance issue for extended utility code
On 8 October 2011 08:03, Stefan Behnel wrote: > Vitja Makarov, 07.10.2011 18:01: >>> >>> 2011/10/7 Stefan Behnel: Vitja Makarov, 06.10.2011 23:12: > > Here is small comparison on compiling urllib.py with cython: > > ((e8527c5...)) vitja@mchome:~/work/cython-vitek-git/zzz$ time python > ../cython.py urllib.py > > real 0m1.699s > user 0m1.650s > sys 0m0.040s > (master) vitja@mchome:~/work/cython-vitek-git/zzz$ time python > ../cython.py urllib.py > > real 0m2.830s > user 0m2.790s > sys 0m0.030s > > > It's about 1.5 times slower. That's a pretty serious regression for plain Python code then. Again, this needs proper profiling. >> >> I've added return statement on top of CythonScope.test_cythonscope, >> now I have these timings: >> >> (master) vitja@mchome:~/work/cython-vitek-git/zzz$ time python >> ../cython.py urllib.py >> >> real 0m1.764s >> user 0m1.700s >> sys 0m0.060s > > Ok, then it's only a bug. "create_testscope" is on by default in Main.py, > Context.__init__(). I don't know what it does exactly, but my guess is that > the option should a) be off by default and b) should rather be passed in by > the test runner as part of the compile options rather than being a parameter > of the Context class. AFAICT, it's currently only used in TreeFragment.py, > where it is being switched off explicitly for parsing code snippets. > > Stefan > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > It turns it off to avoid infinite recursion. This basically means that you cannot use stuf from the Cython scope in your Cython utilities. So in your Cython utilities, you have to declare the C version of it (which you declared with the @cname decorator). This is not really something that can just be avoided loading like this. Perhaps one solution could be to load the test scope when you do a lookup in the cython scope for which no entry is found. But really, libcython and serializing entries will solve all this, so I suppose the real question is, do we want to do a release before we support such functionality? Anyway, the cython scope lookup would be a simple hack worth a try. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] compiler performance issue for extended utility code
2011/10/8 mark florisson : > On 8 October 2011 08:03, Stefan Behnel wrote: >> Vitja Makarov, 07.10.2011 18:01: 2011/10/7 Stefan Behnel: > > Vitja Makarov, 06.10.2011 23:12: >> >> Here is small comparison on compiling urllib.py with cython: >> >> ((e8527c5...)) vitja@mchome:~/work/cython-vitek-git/zzz$ time python >> ../cython.py urllib.py >> >> real 0m1.699s >> user 0m1.650s >> sys 0m0.040s >> (master) vitja@mchome:~/work/cython-vitek-git/zzz$ time python >> ../cython.py urllib.py >> >> real 0m2.830s >> user 0m2.790s >> sys 0m0.030s >> >> >> It's about 1.5 times slower. > > That's a pretty serious regression for > plain Python code then. Again, this needs proper profiling. >>> >>> I've added return statement on top of CythonScope.test_cythonscope, >>> now I have these timings: >>> >>> (master) vitja@mchome:~/work/cython-vitek-git/zzz$ time python >>> ../cython.py urllib.py >>> >>> real 0m1.764s >>> user 0m1.700s >>> sys 0m0.060s >> >> Ok, then it's only a bug. "create_testscope" is on by default in Main.py, >> Context.__init__(). I don't know what it does exactly, but my guess is that >> the option should a) be off by default and b) should rather be passed in by >> the test runner as part of the compile options rather than being a parameter >> of the Context class. AFAICT, it's currently only used in TreeFragment.py, >> where it is being switched off explicitly for parsing code snippets. >> >> Stefan >> ___ >> cython-devel mailing list >> cython-devel@python.org >> http://mail.python.org/mailman/listinfo/cython-devel >> > > It turns it off to avoid infinite recursion. This basically means that > you cannot use stuf from the Cython scope in your Cython utilities. So > in your Cython utilities, you have to declare the C version of it > (which you declared with the @cname decorator). > > This is not really something that can just be avoided loading like > this. Perhaps one solution could be to load the test scope when you do > a lookup in the cython scope for which no entry is found. But really, > libcython and serializing entries will solve all this, so I suppose > the real question is, do we want to do a release before we support > such functionality? > Anyway, the cython scope lookup would be a simple hack worth a try. > Does utility code supports something like dependencies? And could that help here? I've also noticed that some utilities are loaded unconditionally perhaps it's better to introduce lazy loading. -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Any news from the IronPython port?
Robert Bradshaw, 19.07.2011 05:57: On Mon, Jul 18, 2011 at 7:45 AM, Jason McCampbell wrote: Definitely not buried for good, though we haven't made a lot of changes recently. :) We used it for porting SciPy to .NET and re-wrote a large number of the SciPy C module implementations in Cython. It is generally stable and produces good code within the set of features that were needed (by no means has feature parity with the CPython version). In general, I have been quite happy with the results given that it is possible to generate interfaces for two Python implementations from a single source. Of course, it is not free. One can, in general, not take a NumPy-heavy Cython file and just generate source code for IronPython. Because IronPython and NumPy for .NET do not share any common C APIs we had to wrap some of the APIs and in other cases switch to using Python notation and/or call the new Python-independent NumPy core API (present only in the refactored version). Overall, I think it's a good start and holds some promise for generating re-targetable native wrappings, but there is still plenty of work to do to make it more accessible. Regards, Jason Thanks for the status update--is the code available somewhere (e.g. as a forked git repo)? Is it something that would be worth merging, or at this point is it mostly hacked up to just do what you need it to for SciPy? The code is here: https://bitbucket.org/cwitty/cython-for-ironpython/overview No idea what the status is, but it hasn't been updated for a while. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] compiler performance issue for extended utility code
On 8 October 2011 13:10, Vitja Makarov wrote: > 2011/10/8 mark florisson : >> On 8 October 2011 08:03, Stefan Behnel wrote: >>> Vitja Makarov, 07.10.2011 18:01: > > 2011/10/7 Stefan Behnel: >> >> Vitja Makarov, 06.10.2011 23:12: >>> >>> Here is small comparison on compiling urllib.py with cython: >>> >>> ((e8527c5...)) vitja@mchome:~/work/cython-vitek-git/zzz$ time python >>> ../cython.py urllib.py >>> >>> real 0m1.699s >>> user 0m1.650s >>> sys 0m0.040s >>> (master) vitja@mchome:~/work/cython-vitek-git/zzz$ time python >>> ../cython.py urllib.py >>> >>> real 0m2.830s >>> user 0m2.790s >>> sys 0m0.030s >>> >>> >>> It's about 1.5 times slower. >> >> That's a pretty serious regression for >> plain Python code then. Again, this needs proper profiling. I've added return statement on top of CythonScope.test_cythonscope, now I have these timings: (master) vitja@mchome:~/work/cython-vitek-git/zzz$ time python ../cython.py urllib.py real 0m1.764s user 0m1.700s sys 0m0.060s >>> >>> Ok, then it's only a bug. "create_testscope" is on by default in Main.py, >>> Context.__init__(). I don't know what it does exactly, but my guess is that >>> the option should a) be off by default and b) should rather be passed in by >>> the test runner as part of the compile options rather than being a parameter >>> of the Context class. AFAICT, it's currently only used in TreeFragment.py, >>> where it is being switched off explicitly for parsing code snippets. >>> >>> Stefan >>> ___ >>> cython-devel mailing list >>> cython-devel@python.org >>> http://mail.python.org/mailman/listinfo/cython-devel >>> >> >> It turns it off to avoid infinite recursion. This basically means that >> you cannot use stuf from the Cython scope in your Cython utilities. So >> in your Cython utilities, you have to declare the C version of it >> (which you declared with the @cname decorator). >> >> This is not really something that can just be avoided loading like >> this. Perhaps one solution could be to load the test scope when you do >> a lookup in the cython scope for which no entry is found. But really, >> libcython and serializing entries will solve all this, so I suppose >> the real question is, do we want to do a release before we support >> such functionality? >> Anyway, the cython scope lookup would be a simple hack worth a try. >> > > Does utility code supports something like dependencies? And could that > help here? Yeah they can have dependencies like normal UtilitieCodes. > I've also noticed that some utilities are loaded unconditionally > perhaps it's better to introduce lazy loading. Well, they shouldn't be. If they are it's generally a bug. I noticed that it happens in the test runner though, although it should create a fresh context with freshly initialized entries. > -- > vitja. > ___ > 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] Can't login into my trac account
Hi! Any news here? 2011/9/28 Robert Bradshaw : > I can't log in either, though I haven't had a chance to investigate. > > On Tue, Sep 27, 2011 at 9:41 AM, Vitja Makarov > wrote: >> Hi! >> >> Today I found that I can't login into my trac account. Is that common >> problem or only mine? >> >> -- >> vitja. >> ___ >> 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 > -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
