Mailman 3 January 2016 - Python-Dev

Re: [Python-Dev] Speeding up CPython 5-10%
by Damien George Jan. 29, 2016

Jan. 29, 2016

Hi Yury, > An off-topic: have you ever tried hg.python.org/benchmarks > or compare MicroPython vs CPython? I'm curious if MicroPython > is faster -- in that case we'll try to copy some optimization > ideas. I've tried a small number of those benchmarks, but not in any rigorous way, and not enough to compare properly with CPython. Maybe one day I (or someone) will get to it and report results :) One thing that makes MP fast is the use of pointer tagging and stuffing of small … [View More]

2 1

FAT Python (lack of) performance
by Victor Stinner Jan. 29, 2016

Jan. 29, 2016

Hi, Summary: FAT Python is not faster, but it will be ;-) -- When I started the FAT Python as a fork of CPython 3.6, I put everything in the same repository. Last weeks, I focused on splitting my giant patch (10k lines) into small reviewable patches. I wrote 3 PEP (509 dict version, 510 function specialziation, 511 code tranformers) and I enhanced the API to make it usable for more use cases than just FAT Python. I also created fatoptimizer (the AST optimizer) and fat (runtime dependency of … [View More]the optimizer) projects on GitHub to separate clearly what should be outside Python core. For all links, see: http://faster-cpython.readthedocs.org/fat_python.html For the fatoptimizer project, my constraint is to be able to run the full Python test suite unmodified. In practice, I have to disable some optimizations by putting a "__fatoptimizer__= {...}" configuration to some test files. For example, I have to disable constant folding on test_bool because it tests that False+2 gives 2 at runtime, whereas the optimizer replaces directly False+2 with 2 during the compilation. Well, test_bool.py is not the best example because all tests pass with the constant folding optimization (if I comment my "__fatoptimizer__={...}" change). This constraint ensures that the optimizer "works" and doesn't break (too much ;-)) the Python semantics, but it's more difficult to implement powerful optimizations. I also found and fixed various kinds of bugs. In my code obviously, but also in the Python core, in various places. Some bugs only concern AST transformers which is a new feature, but I had to fix them. For example, Python didn't support negative line number delta in co_lntotab of code objects, and so line number were all wrong on optimized code. I merged my enhancement in the default branch of CPython (issue #26107). In short, I focused on having something working (respecting the Python semantics), rather than spending time on writing optimizations. -- When I asked explicitly "Is someone opposed to this PEP 509 [dict verion] ?", Barry Warsaw answered that a performance analysis is required. Extract of his mail: "I still think this is maintenance and potential performance overhead we don't want to commit to long term unless it enables significant optimization. Since you probably can't prove that without some experimentation, this API should be provisional." Last week, I ran some benchmarks and I have to admin that I was disappointed. Not only fatoptimizer doesn't make Python faster, but it makes it much slower on some tests! http://fatoptimizer.readthedocs.org/en/latest/benchmarks.html Quickly, I identified a major performance issue when nested functions are specialized, especially in Lib/json/encoder.py (tested by bm_json_v2.py benchmark). I fixed my optimizer to not specialize nested functions anymore. This simple change fixed the main performance issue. Reminder: in performance critical code, don't use nested functions! I will maybe propose patches for Lib/json/encoder.py to stop using nested functions. I only ran benchmarks with the optimizer enabled. I now have to measure the overhead of my patches (PEP 509, 510 and 511) adding the API fat AST optimizers. The overhead must be negligible. For me, it's a requirement of the whole project. Changes must not make Python slower when the optimizer is not used. fatoptimizer is faster on microbenchmarks, but I had to write manually some optimizations: http://fatoptimizer.readthedocs.org/en/latest/microbenchmarks.html IMHO fatoptimizer is not faster on macro benchmarks because it is not smart enough (yet) to generate the most interesting optimizations, like function inlining and specialization for argument types. You can estimate the speedup if you specialize manually your functions. -- Barry also wrote: "Did you address my suggestion on python-ideas to make the new C API optionally compiled in?" Well, it is an option, but I would prefer to have the API for AST optimizer directly built in Python. The first beta version of Python 3.6 is scheduled in September 2016 (deadline for new features in Python 3.6), so I still have a few months to implement more powerful optimizations and prove that it can be faster ;-) Victor [View Less]

16 45

Buildbot timing out - test suite failure - test_socket issue with UDP6?
by Chris Angelico Jan. 29, 2016

Jan. 29, 2016

I just had a major crash on the system that hosts the angelico-debian-amd64 buildbot, and as usual, checked it carefully after bringing everything up. It seems now to be timing out after an hour of operation: http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/… This is happening across all the 3.* branches on my buildbot, but NOT on 2.7, and not on any other buildbots. That makes it look like some kind of config problem at my end. In seeking to diagnose it, I … [View More]

4 9

Re: [Python-Dev] [Python-checkins] BAD Benchmark Results for Python Default 2016-01-26
by Stefan Krah Jan. 28, 2016

Jan. 28, 2016

IMO the timings of the benchmark suite are a bit unstable -- this is not the fault of Intel's setup, I noticed it also when running the suite myself. On Tue, Jan 26, 2016 at 06:48:54PM +0000, Stewart, David C wrote: > Wow, what happened to Python default to cause such a regression? > > > > > On 1/26/16, 7:31 AM, "lp_benchmark_robot" <lp_benchmark_robot(a)intel.com> wrote: > > >Results for project Python default, build date 2016-01-26 03:07:40 +0000 > &… [View More]gt;commit: cbd4a6a2657e > >previous commit: f700bc0412bc > >revision date: 2016-01-26 02:54:37 +0000 > >environment: Haswell-EP > > cpu: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB > > mem: 128 GB > > os: CentOS 7.1 > > kernel: Linux 3.10.0-229.4.2.el7.x86_64 > > > >Baseline results were generated using release v3.4.3, with hash b4cbecbc0781 > >from 2015-02-25 12:15:33+00:00 > > > >---------------------------------------------------------------------------------- > > benchmark relative change since change since current rev run > > std_dev* last run baseline with PGO > >---------------------------------------------------------------------------------- > >:-) django_v2 0.21% -2.93% 8.95% 16.19% > >:-| pybench 0.10% 0.05% -1.87% 5.40% > >:-( regex_v8 2.72% -0.02% -4.67% 4.57% > >:-| nbody 0.13% -0.92% -1.33% 7.40% > >:-| json_dump_v2 0.20% 0.87% -1.59% 11.48% > >:-| normal_startup 0.90% -0.57% 0.10% 5.35% > >---------------------------------------------------------------------------------- > >* Relative Standard Deviation (Standard Deviation/Average) > > > >If this is not displayed properly please visit our results page here: http://languagesperformance.intel.com/bad-benchmark-results-for-python-defa… > > > >Note: Benchmark results are measured in seconds. > > > >Subject Label Legend: > >Attributes are determined based on the performance evolution of the workloads > >compared to the previous measurement iteration. > >NEUTRAL: performance did not change by more than 1% for any workload > >GOOD: performance improved by more than 1% for at least one workload and there > >is no regression greater than 1% > >BAD: performance dropped by more than 1% for at least one workload and there is > >no improvement greater than 1% > >UGLY: performance improved by more than 1% for at least one workload and also > >dropped by more than 1% for at least one workload > > > > > >Our lab does a nightly source pull and build of the Python project and measures > >performance changes against the previous stable version and the previous nightly > >measurement. This is provided as a service to the community so that quality > >issues with current hardware can be identified quickly. > > > >Intel technologies' features and benefits depend on system configuration and may > >require enabled hardware, software or service activation. Performance varies > >depending on system configuration. > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > https://mail.python.org/mailman/listinfo/python-checkins [View Less]

1 0

Re: [Python-Dev] Speeding up CPython 5-10%
by Damien George Jan. 28, 2016

Jan. 28, 2016

Hi Yuri, I think these are great ideas to speed up CPython. They are probably the simplest yet most effective ways to get performance improvements in the VM. MicroPython has had LOAD_METHOD/CALL_METHOD from the start (inspired by PyPy, and the main reason to have it is because you don't need to allocate on the heap when doing a simple method call). The specific opcodes are: LOAD_METHOD # same behaviour as you propose CALL_METHOD # for calls with positional and/or keyword args … [View More]

3 3

Re: [Python-Dev] Speeding up CPython 5-10%
by Damien George Jan. 28, 2016

Jan. 28, 2016

Hi Yury, (Sorry for misspelling your name previously!) > Yes, we'll need to add CALL_METHOD{_VAR|_KW|etc} opcodes to optimize all > kind of method calls. However, I'm not sure how big the impact will be, > need to do more benchmarking. I never did such fine grained analysis with MicroPython. I don't think there are many uses of * and ** that it'd be worth it, but definitely there are lots of uses of plain keywords. Also, you'd want to consider how simple/complex it is to treat … [View More]all these different opcodes in the compiler. For us, it's simpler to treat everything the same. Otherwise your LOAD_METHOD part of the compiler will need to peek deep into the AST to see what kind of call it is. > BTW, how do you benchmark MicroPython? Haha, good question! Well, we use Pystone 1.2 (unmodified) to do basic benchmarking, and find it to be quite good. We track our code live at: http://micropython.org/resources/code-dashboard/ You can see there the red line, which is the Pystone result. There was a big jump around Jan 2015 which is when we introduced opcode dictionary caching. And since then it's been very gradually increasing due to small optimisations here and there. Pystone is actually a great benchmark for embedded systems because it gives very reliable results there (almost zero variation across runs) and if we can squeeze 5 more Pystones out with some change then we know that it's a good optimisation (for efficiency at least). For us, low RAM usage and small code size are the most important factors, and we track those meticulously. But in fact, smaller code size quite often correlates with more efficient code because there's less to execute and it fits in the CPU cache (at least on the desktop). We do have some other benchmarks, but they are highly specialised for us. For example, how fast can you bit bang a GPIO pin using pure Python code. Currently we get around 200kHz on a 168MHz MCU, which shows that pure (Micro)Python code is about 100 times slower than C. > That's a neat idea! You're right, it does require bytecode to become > writeable. I considered implementing a similar strategy, but this would > be a big change for CPython. So I decided to minimize the impact of the > patch and leave the opcodes untouched. I think you need to consider "big" changes, especially ones like this that can have a great (and good) impact. But really, this is a behind-the-scenes change that *should not* affect end users, and so you should not have any second thoughts about doing it. One problem I see with CPython is that it exposes way too much to the user (both Python programmer and C extension writer) and this hurts both language evolution (you constantly need to provide backwards compatibility) and ability to optimise. Cheers, Damien. [View Less]

2 1

Re: [Python-Dev] [Python-checkins] Daily reference leaks (cbd4a6a2657e): sum=134
by Brett Cannon Jan. 27, 2016

Jan. 27, 2016

Looks like Victor's ast.Constant change introduced a refleak. On Tue, 26 Jan 2016 at 00:47 <solipsis(a)pitrou.net> wrote: > results for cbd4a6a2657e on branch "default" > -------------------------------------------- > > test_ast leaked [39, 39, 39] references, sum=117 > test_ast leaked [5, 5, 5] memory blocks, sum=15 > test_collections leaked [-2, 0, 0] references, sum=-2 > test_functools leaked [0, 2, 2] memory blocks, sum=4 > > > Command line was: ['./… [View More]

2 1

Hoping to Find a Mentor
by Truong Nguyen Jan. 27, 2016

Jan. 27, 2016

Dear Everyone, My name is Truong Nguyen and I like web development. I'm writing hoping to find a mentor (who likes to teach), and opportunity to contribute to the python.org website to gain skills in full stack development. Python Software Foundation interest me because the language is used in a wide variety of fields. My background is not in computer science, but I've earned a B.S. in Applied Mathematics and have an equivalent minor in computer science. I did front end project with HTML, CSS3 … [View More]

1 0

Code formatter bot
by francismb Jan. 26, 2016

Jan. 26, 2016

Dear Core-Devs, what's your opinion about a code-formatter bot for cpython. Pros, Cons, where could be applicable (new commits, new workflow, it doesn't make sense), ... - At least it should follow PEP 7 ;-) - ... Thanks in advance, francis

7 10

do people use sys._mercurial?
by Brett Cannon Jan. 25, 2016

Jan. 25, 2016

Since we are going to be switching over to Git, sys._mercurial is going to be made to return a dummy value of `('CPython', '', '')` once we switch to Git. But my question is do we bother to replace it with sys._git? I wanted to make sure that the effort is worth it to keep changing these VCS-specific attributes every time we change our VCS (and no, we are not going to adopt a generic one; already had that debate). So do please speak up if you actually have found value from sys._mercurial.

6 12