Python-Dev January 2016

python-dev@python.org

75 participants
46 discussions

congrats on 3.5! Alas, windows 7 users are having problems installing it

by Laura Creighton

webmaster has already heard from 4 people who cannot install it. I sent them to the bug tracker or to python-list but they seem not to have gone either place. Is there some guide I should be sending them to, 'how to debug installation problems'? Laura

8 months, 2 weeks

Speeding up CPython 5-10%

by Yury Selivanov

Hi, tl;dr The summary is that I have a patch that improves CPython performance up to 5-10% on macro benchmarks. Benchmarks results on Macbook Pro/Mac OS X, desktop CPU/Linux, server CPU/Linux are available at [1]. There are no slowdowns that I could reproduce consistently. There are twodifferent optimizations that yield this speedup: LOAD_METHOD/CALL_METHOD opcodes and per-opcode cache in ceval loop. LOAD_METHOD & CALL_METHOD ------------------------- We had a lot of conversations with Victor about his PEP 509, and he sent me a link to his amazing compilation of notes about CPython performance [2]. One optimization that he pointed out to me was LOAD/CALL_METHOD opcodes, an idea first originated in PyPy. There is a patch that implements this optimization, it's tracked here: [3]. There are some low level details that I explained in the issue, but I'll go over the high level design in this email as well. Every time you access a method attribute on an object, a BoundMethod object is created. It is a fairly expensive operation, despite a freelist of BoundMethods (so that memory allocation is generally avoided). The idea is to detect what looks like a method call in the compiler, and emit a pair of specialized bytecodes for that. So instead of LOAD_GLOBAL/LOAD_ATTR/CALL_FUNCTION we will have LOAD_GLOBAL/LOAD_METHOD/CALL_METHOD. LOAD_METHOD looks at the object on top of the stack, and checks if the name resolves to a method or to a regular attribute. If it's a method, then we push the unbound method object and the object to the stack. If it's an attribute, we push the resolved attribute and NULL. When CALL_METHOD looks at the stack it knows how to call the unbound method properly (pushing the object as a first arg), or how to call a regular callable. This idea does make CPython faster around 2-4%. And it surely doesn't make it slower. I think it's a safe bet to at least implement this optimization in CPython 3.6. So far, the patch only optimizes positional-only method calls. It's possible to optimize all kind of calls, but this will necessitate 3 more opcodes (explained in the issue). We'll need to do some careful benchmarking to see if it's really needed. Per-opcode cache in ceval ------------------------- While reading PEP 509, I was thinking about how we can use dict->ma_version in ceval to speed up globals lookups. One of the key assumptions (and this is what makes JITs possible) is that real-life programs don't modify globals and rebind builtins (often), and that most code paths operate on objects of the same type. In CPython, all pure Python functions have code objects. When you call a function, ceval executes its code object in a frame. Frames contain contextual information, including pointers to the globals and builtins dict. The key observation here is that almost all code objects always have same pointers to the globals (the module they were defined in) and to the builtins. And it's not a good programming practice to mutate globals or rebind builtins. Let's look at this function: def spam(): print(ham) Here are its opcodes: 2 0 LOAD_GLOBAL 0 (print) 3 LOAD_GLOBAL 1 (ham) 6 CALL_FUNCTION 1 (1 positional, 0 keyword pair) 9 POP_TOP 10 LOAD_CONST 0 (None) 13 RETURN_VALUE The opcodes we want to optimize are LAOD_GLOBAL, 0 and 3. Let's look at the first one, that loads the 'print' function from builtins. The opcode knows the following bits of information: - its offset (0), - its argument (0 -> 'print'), - its type (LOAD_GLOBAL). And these bits of information will *never* change. So if this opcode could resolve the 'print' name (from globals or builtins, likely the latter) and save the pointer to it somewhere, along with globals->ma_version and builtins->ma_version, it could, on its second call, just load this cached info back, check that the globals and builtins dict haven't changed and push the cached ref to the stack. That would save it from doing two dict lookups. We can also optimize LOAD_METHOD. There are high chances, that 'obj' in 'obj.method()' will be of the same type every time we execute the code object. So if we'd have an opcodes cache, LOAD_METHOD could then cache a pointer to the resolved unbound method, a pointer to obj.__class__, and tp_version_tag of obj.__class__. Then it would only need to check if the cached object type is the same (and that it wasn't modified) and that obj.__dict__ doesn't override 'method'. Long story short, this caching really speeds up method calls on types implemented in C. list.append becomes very fast, because list doesn't have a __dict__, so the check is very cheap (with cache). A straightforward way to implement such a cache is simple, but consumes a lot of memory, that would be just wasted, since we only need such a cache for LOAD_GLOBAL and LOAD_METHOD opcodes. So we have to be creative about the cache design. Here's what I came up with: 1. We add a few fields to the code object. 2. ceval will count how many times each code object is executed. 3. When the code object is executed over ~900 times, we mark it as "hot". We also create an 'unsigned char' array "MAPPING", with length set to match the length of the code object. So we have a 1-to-1 mapping between opcodes and MAPPING array. 4. Next ~100 calls, while the code object is "hot", LOAD_GLOBAL and LOAD_METHOD do "MAPPING[opcode_offset()]++". 5. After 1024 calls to the code object, ceval loop will iterate through the MAPPING, counting all opcodes that were executed more than 50 times. 6. We then create an array of cache structs "CACHE" (here's a link to the updated code.h file: [6]). We update MAPPING to be a mapping between opcode position and position in the CACHE. The code object is now "optimized". 7. When the code object is "optimized", LOAD_METHOD and LOAD_GLOBAL use the CACHE array for fast path. 8. When there is a cache miss, i.e. the builtins/global/obj.__dict__ were mutated, the opcode marks its entry in 'CACHE' as deoptimized, and it will never try to use the cache again. Here's a link to the issue tracker with the first version of the patch: [5]. I'm working on the patch in a github repo here: [4]. Summary ------- There are many things about this algorithm that we can improve/tweak. Perhaps we should profile code objects longer, or account for time they were executed. Maybe we shouldn't deoptimize opcodes on their first cache miss. Maybe we can come up with better data structures. We also need to profile the memory and see how much more this cache will require. One thing I'm certain about, is that we can get a 5-10% speedup of CPython with relatively low memory impact. And I think it's worth exploring that! If you're interested in these kind of optimizations, please help with code reviews, ideas, profiling and benchmarks. The latter is especially important, I'd never imagine how hard it is to come up with a good macro benchmark. I also want to thank my company MagicStack (magic.io) for sponsoring this work. Thanks, Yury [1] https://gist.github.com/1st1/aed69d63a2ff4de4c7be [2] http://faster-cpython.readthedocs.org/index.html [3] http://bugs.python.org/issue26110 [4] https://github.com/1st1/cpython/tree/opcache2 [5] http://bugs.python.org/issue26219 [6] https://github.com/python/cpython/compare/master...1st1:opcache2?expand=1#d…

4 years

PEP 506 secrets module

by Steven D'Aprano

Hi, As extensively discussed on Python-Ideas, the secrets module and PEP 506 is (I hope) ready for pronouncement. https://www.python.org/dev/peps/pep-0506/ There is code and tests here: https://bitbucket.org/sdaprano/secrets or you can run hg clone https://sdaprano@bitbucket.org/sdaprano/secrets The code is written for and tested on Python 2.6, 2.7, 3.1 - 3.4. -- Steve

4 years, 1 month

More optimisation ideas

by Steve Dower

Since we're all talking about making Python faster, I thought I'd drop some previous ideas I've had here in case (1) someone wants to actually do them, and (2) they really are new ideas that haven't failed in the past. Mostly I was thinking about startup time. Here are the list of modules imported on clean startup on my Windows, US-English machine (from -v and cleaned up a bit): import _frozen_importlib import _imp import sys import '_warnings' import '_thread' import '_weakref' import '_frozen_importlib_external' import '_io' import 'marshal' import 'nt' import '_thread' import '_weakref' import 'winreg' import 'zipimport' import '_codecs' import 'codecs' import 'encodings.aliases' import 'encodings' import 'encodings.mbcs' import '_signal' import 'encodings.utf_8' import 'encodings.latin_1' import '_weakrefset' import 'abc' import 'io' import 'encodings.cp437' import 'errno' import '_stat' import 'stat' import 'genericpath' import 'ntpath' import '_collections_abc' import 'os' import '_sitebuiltins' import 'sysconfig' import '_locale' import '_bootlocale' import 'encodings.cp1252' import 'site' Obviously the easiest first thing is to remove or delay unnecessary imports. But a while ago I used a native profiler to trace through this and the most impactful modules were the encodings: import 'encodings.mbcs' import 'encodings.utf_8' import 'encodings.latin_1' import 'encodings.cp437' import 'encodings.cp1252' While I don't doubt that we need all of these for *some* reason, aliases, cp437 and cp1252 are relatively expensive modules to import. Mostly due to having large static dictionaries or data structures generated on startup. Given this is static and mostly read-only information[1], I see no reason why we couldn't either generate completely static versions of them, or better yet compile the resulting data structures into the core binary. ([1]: If being able to write to some of the encoding data is used by some people, I vote for breaking that for 3.6 and making it read-only.) This is probably the code snippet that bothered me the most: ### Encoding table encoding_table=codecs.charmap_build(decoding_table) It shows up in many of the encodings modules, and while it is not a bad function in itself, we are obviously generating a known data structure on every startup. Storing these in static data is a tradeoff between disk space and startup performance, and one I think it likely to be worthwhile. Anyway, just an idea if someone wants to try it and see what improvements we can get. I'd love to do it myself, but when it actually comes to finding time I keep coming up short. Cheers, Steve P.S. If you just want to discuss optimisation techniques or benchmarking in general, without specific application to CPython 3.6, there's a whole internet out there. Please don't make me the cause of a pointless centithread. :)

4 years, 3 months

just a friendly developer

by ty armour

I am looking for tutorials on basically how to write the python language. As well I want to know how to write wrappers for things like alsa and directx and coreaudio and jackd and pulseaudio. I would be looking to write wrappers for coreaudio in mac and coreaudio for windows as well as alsa. i think it would benefit you to have this information. I am looking to aid in development of computers and languages and tutorials on how to write the actual python language would be super useful. but yeah im looking to write applications like guitarix rakarrack blender ardour lmms. I am also going to build my own computers so these tutorials would help a lot. anyhow thanks for your time

4 years, 4 months

Fun with ancient unsupported platforms

by Larry Hastings

Check out and cd into Python trunk. % grep -Ri win16 * | wc 10 66 625 % grep -Ri nextstep | wc 23 119 1328 % grep -Ri rhapsody * | wc 47 269 3390 % grep -Ri msdos * | wc 56 381 3895 % grep -Ri ms-dos * | wc 20 180 1425 win16! *laughs* *wipes tear from eye* It's currently 2016. Perhaps it's time to remove all vestiges of these unsupported operating systems nobody's cared about since a year that started with a '1'? //arry/ p.s. I suspect some of the uses of "rhapsody" are actually live code used for OS X. So this isn't necessarily dead code, some of it is merely long-out-of-date comments. p.p.s. At least there were no references to "taligent", "copland", or "gershwin"...!

4 years, 4 months

How to resolve distinguishing between documentation and implementation

by Serhiy Storchaka

How to resolve distinguishing between documentation and implementation if current implementation is incorrect, but third-party code can implicitly depends on it? For example see issue26198. Currently buffer overflow of predefined buffer for "es#" and "et#" format units causes TypeError (with misleading message, but this is other story). The correct and *documented* exception is ValueError. User code can depend on current behavior, because TypeError is what is raised now for this type of errors, and this is what is raised for other types of errors. Unlikely authors of such code read the documentation, otherwise this issue would be reported earlier. On other hand, looks these format units are rarely used with predefined buffer (never in the stdlib since 3.5). I think it is obvious that the code in the development branch should be changed to produce documented and more logical exception. But what about bugfix releases? Changing the documentation would be misleading, changing the code can break existing code (unlikely, but).

4 years, 4 months

Summary of Python tracker Issues

by Python tracker

ACTIVITY SUMMARY (2016-01-22 - 2016-01-29) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 5381 (+27) closed 32615 (+30) total 37996 (+57) Open issues with patches: 2359 Issues opened (39) ================== #26182: Deprecation warnings for the future async and await keywords http://bugs.python.org/issue26182 opened by marco.buttu #26184: raise an error when create_module() is not defined by exec_mod http://bugs.python.org/issue26184 opened by brett.cannon #26185: zipfile.ZipInfo slots can raise unexpected AttributeError http://bugs.python.org/issue26185 opened by Matthew Zipay #26186: LazyLoader rejecting use of SourceFileLoader http://bugs.python.org/issue26186 opened by brett.cannon #26187: sqlite3 trace callback prints duplicate line http://bugs.python.org/issue26187 opened by palaviv #26188: Provide more helpful error message when `await` is called insi http://bugs.python.org/issue26188 opened by Nicholas Chammas #26192: python3 k1om dissociation permanence: libffi http://bugs.python.org/issue26192 opened by mancoast #26193: python3 k1om dissociation permanence: readelf http://bugs.python.org/issue26193 opened by mancoast #26194: Undefined behavior for deque.insert() when len(d) == maxlen http://bugs.python.org/issue26194 opened by rhettinger #26195: Windows frozen .exe multiprocessing.Queue access is denied exc http://bugs.python.org/issue26195 opened by alex_python_org #26198: PyArg_ParseTuple with format "et#" and "es#" detects overflow http://bugs.python.org/issue26198 opened by hniksic #26200: SETREF adds unnecessary work in some cases http://bugs.python.org/issue26200 opened by rhettinger #26204: compiler: ignore constants used as statements? (don't emit LOA http://bugs.python.org/issue26204 opened by haypo #26205: Inconsistency concerning nested scopes http://bugs.python.org/issue26205 opened by Roscoe R. Higgins #26207: distutils msvccompiler fails due to mspdb140.dll error on debu http://bugs.python.org/issue26207 opened by haypo #26208: decimal C module's exceptions don't match the Python version http://bugs.python.org/issue26208 opened by encukou #26209: TypeError in smtpd module with string arguments http://bugs.python.org/issue26209 opened by lorenzo.ancora #26210: `HTMLParser.handle_data` may be invoked although `HTMLParser.r http://bugs.python.org/issue26210 opened by Hibou57 #26212: Python with ncurses6.0 will not load _curses module on Solaris http://bugs.python.org/issue26212 opened by jonesrw #26213: Document BUILD_*_UNPACK opcodes http://bugs.python.org/issue26213 opened by brett.cannon #26214: textwrap should minimize number of breaks in extra long words http://bugs.python.org/issue26214 opened by Tuomas Salo #26215: Make GC_Head a compile-time option http://bugs.python.org/issue26215 opened by yuriy_levchenko #26216: run runtktests.py error when test tkinter http://bugs.python.org/issue26216 opened by allensll #26218: Set PrependPath default to true http://bugs.python.org/issue26218 opened by Wallison Resende Santos #26219: implement per-opcode cache in ceval http://bugs.python.org/issue26219 opened by yselivanov #26221: asynco run_in_executor swallows StopIteration http://bugs.python.org/issue26221 opened by ikelly #26222: Missing code in linux_distribution python 2.7.11 http://bugs.python.org/issue26222 opened by Rasmus Rynning Rasmussen #26223: decimal.to_eng_string() does not implement engineering notatio http://bugs.python.org/issue26223 opened by serge.stroobandt #26224: Add "version added" for documentation of asyncio.timeout for d http://bugs.python.org/issue26224 opened by Udi Oron #26225: New misleading wording in execution model documenation http://bugs.python.org/issue26225 opened by abarnert #26226: Various test suite failures on Windows http://bugs.python.org/issue26226 opened by ebarry #26228: pty.spawn hangs on FreeBSD 9.3, 10.x http://bugs.python.org/issue26228 opened by chris.torek #26229: Make number serialization ES6/V8 compatible http://bugs.python.org/issue26229 opened by anders.rundgren.net(a)gmail.com #26231: HTTPResponse.close() should consume all remaining data in body http://bugs.python.org/issue26231 opened by Jacky #26233: select.epoll.poll() should avoid calling malloc() each time http://bugs.python.org/issue26233 opened by haypo #26234: The typing module includes 're' and 'io' in __all__ http://bugs.python.org/issue26234 opened by gvanrossum #26235: argparse docs: Positional * argument in mutually exclusive gro http://bugs.python.org/issue26235 opened by paul.j3 #26236: urllib2 initiate irregular call to gethostbyaddr http://bugs.python.org/issue26236 opened by juliadolgova #26238: httplib use wrong hostname in https request with SNI support http://bugs.python.org/issue26238 opened by lvhancy Most recent 15 issues with no replies (15) ========================================== #26238: httplib use wrong hostname in https request with SNI support http://bugs.python.org/issue26238 #26236: urllib2 initiate irregular call to gethostbyaddr http://bugs.python.org/issue26236 #26235: argparse docs: Positional * argument in mutually exclusive gro http://bugs.python.org/issue26235 #26224: Add "version added" for documentation of asyncio.timeout for d http://bugs.python.org/issue26224 #26216: run runtktests.py error when test tkinter http://bugs.python.org/issue26216 #26214: textwrap should minimize number of breaks in extra long words http://bugs.python.org/issue26214 #26209: TypeError in smtpd module with string arguments http://bugs.python.org/issue26209 #26200: SETREF adds unnecessary work in some cases http://bugs.python.org/issue26200 #26195: Windows frozen .exe multiprocessing.Queue access is denied exc http://bugs.python.org/issue26195 #26193: python3 k1om dissociation permanence: readelf http://bugs.python.org/issue26193 #26192: python3 k1om dissociation permanence: libffi http://bugs.python.org/issue26192 #26187: sqlite3 trace callback prints duplicate line http://bugs.python.org/issue26187 #26185: zipfile.ZipInfo slots can raise unexpected AttributeError http://bugs.python.org/issue26185 #26184: raise an error when create_module() is not defined by exec_mod http://bugs.python.org/issue26184 #26176: EmailMessage example doesn't work http://bugs.python.org/issue26176 Most recent 15 issues waiting for review (15) ============================================= #26233: select.epoll.poll() should avoid calling malloc() each time http://bugs.python.org/issue26233 #26228: pty.spawn hangs on FreeBSD 9.3, 10.x http://bugs.python.org/issue26228 #26224: Add "version added" for documentation of asyncio.timeout for d http://bugs.python.org/issue26224 #26219: implement per-opcode cache in ceval http://bugs.python.org/issue26219 #26204: compiler: ignore constants used as statements? (don't emit LOA http://bugs.python.org/issue26204 #26198: PyArg_ParseTuple with format "et#" and "es#" detects overflow http://bugs.python.org/issue26198 #26194: Undefined behavior for deque.insert() when len(d) == maxlen http://bugs.python.org/issue26194 #26192: python3 k1om dissociation permanence: libffi http://bugs.python.org/issue26192 #26185: zipfile.ZipInfo slots can raise unexpected AttributeError http://bugs.python.org/issue26185 #26177: tkinter: Canvas().keys returns empty strings. http://bugs.python.org/issue26177 #26175: Fully implement IOBase abstract on SpooledTemporaryFile http://bugs.python.org/issue26175 #26173: test_ssl.bad_cert_test() exception handling http://bugs.python.org/issue26173 #26168: Py_BuildValue may leak 'N' arguments on PyTuple_New failure http://bugs.python.org/issue26168 #26167: Improve copy.copy speed for built-in types (list/set/dict) http://bugs.python.org/issue26167 #26145: PEP 511: Add sys.set_code_transformers() http://bugs.python.org/issue26145 Top 10 most discussed issues (10) ================================= #26194: Undefined behavior for deque.insert() when len(d) == maxlen http://bugs.python.org/issue26194 17 msgs #26207: distutils msvccompiler fails due to mspdb140.dll error on debu http://bugs.python.org/issue26207 12 msgs #26198: PyArg_ParseTuple with format "et#" and "es#" detects overflow http://bugs.python.org/issue26198 11 msgs #26039: More flexibility in zipfile interface http://bugs.python.org/issue26039 7 msgs #26219: implement per-opcode cache in ceval http://bugs.python.org/issue26219 7 msgs #26223: decimal.to_eng_string() does not implement engineering notatio http://bugs.python.org/issue26223 7 msgs #19883: Integer overflow in zipimport.c http://bugs.python.org/issue19883 6 msgs #20598: argparse docs: '7'.split() is confusing magic http://bugs.python.org/issue20598 6 msgs #25314: Documentation: argparse's actions store_{true,false} default t http://bugs.python.org/issue25314 6 msgs #26204: compiler: ignore constants used as statements? (don't emit LOA http://bugs.python.org/issue26204 6 msgs Issues closed (27) ================== #18018: SystemError: Parent module '' not loaded, cannot perform relat http://bugs.python.org/issue18018 closed by brett.cannon #18898: Apply the setobject optimizations to dictionaries http://bugs.python.org/issue18898 closed by rhettinger #19023: ctypes docs: Unimplemented and undocumented features http://bugs.python.org/issue19023 closed by martin.panter #22363: argparse AssertionError with add_mutually_exclusive_group and http://bugs.python.org/issue22363 closed by martin.panter #24705: sysconfig._parse_makefile doesn't expand ${} vars appearing be http://bugs.python.org/issue24705 closed by berker.peksag #25296: Simple End-of-life guide covering all unsupported versions http://bugs.python.org/issue25296 closed by berker.peksag #26034: venv documentation out of date http://bugs.python.org/issue26034 closed by berker.peksag #26146: PEP 511: Add ast.Constant to allow AST optimizer to emit const http://bugs.python.org/issue26146 closed by haypo #26181: argparse can't handle positional argument after list (help mes http://bugs.python.org/issue26181 closed by martin.panter #26183: 2.7.11 won't clean install on Windows 10 x64 http://bugs.python.org/issue26183 closed by Roger Cook #26189: Interpreter returns control to cmd.exe early http://bugs.python.org/issue26189 closed by Ivan.Pozdeev #26190: GC memory leak using weak and cyclic references http://bugs.python.org/issue26190 closed by koehlma #26191: pip on Windows doesn't honor Case http://bugs.python.org/issue26191 closed by SilentGhost #26196: Argparse breaks when a switch is given an argument beginning w http://bugs.python.org/issue26196 closed by eric.smith #26197: arange from numpy function has some limits....I propose a pyth http://bugs.python.org/issue26197 closed by ebarry #26199: fix broken link to hamcrest.library.integration.match_equality http://bugs.python.org/issue26199 closed by berker.peksag #26201: Faster type checking in listobject.c http://bugs.python.org/issue26201 closed by rhettinger #26202: The range() object is deepcopied as atomic http://bugs.python.org/issue26202 closed by serhiy.storchaka #26203: nesting venv in virtualenv segfaults http://bugs.python.org/issue26203 closed by brett.cannon #26206: test_socket.testRecvmsgPeek() timeout on "AMD64 Debian root 3. http://bugs.python.org/issue26206 closed by martin.panter #26211: HTMLParser: “AssertionError: we should not get here!” http://bugs.python.org/issue26211 closed by Hibou57 #26217: Fatal error when importing ``test.test_os`` in debug mode on W http://bugs.python.org/issue26217 closed by ebarry #26220: Unicode HOWTO references a question mark that isn't in snippet http://bugs.python.org/issue26220 closed by martin.panter #26227: Windows: socket.gethostbyaddr(name) fails for non-ASCII hostna http://bugs.python.org/issue26227 closed by haypo #26230: Cookies do not correct if cookiename includes [ or ] http://bugs.python.org/issue26230 closed by tom_lt #26232: Mock(spec=spec) has no effect http://bugs.python.org/issue26232 closed by michael.foord #26237: UnboundLocalError error while handling exception http://bugs.python.org/issue26237 closed by haypo

4 years, 4 months

Re: [Python-Dev] Speeding up CPython 5-10%

by Damien George

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 integers within object pointers. Thus integer arithmetic below 2**30 (on 32-bit arch) requires no heap. > Do you use opcode dictionary caching only for LOAD_GLOBAL-like > opcodes? Do you have an equivalent of LOAD_FAST, or you use > dicts to store local variables? The opcodes that have dict caching are: LOAD_NAME LOAD_GLOBAL LOAD_ATTR STORE_ATTR LOAD_METHOD (not implemented yet in mainline repo) For local variables we use LOAD_FAST and STORE_FAST (and DELETE_FAST). Actually, there are 16 dedicated opcodes for loading from positions 0-15, and 16 for storing to these positions. Eg: LOAD_FAST_0 LOAD_FAST_1 ... Mostly this is done to save RAM, since LOAD_FAST_0 is 1 byte. > If we change the opcode size, it will probably affect libraries > that compose or modify code objects. Modules like "dis" will > also need to be updated. And that's probably just a tip of the > iceberg. > > We can still implement your approach if we add a separate > private 'unsigned char' array to each code object, so that > LOAD_GLOBAL can store the key offsets. It should be a bit > faster than my current patch, since it has one less level > of indirection. But this way we loose the ability to > optimize LOAD_METHOD, simply because it requires more memory > for its cache. In any case, I'll experiment! Problem with that approach (having a separate array for offset_guess) is that how do you know where to look into that array for a given LOAD_GLOBAL opcode? The second LOAD_GLOBAL in your bytecode should look into the second entry in the array, but how does it know? I'd love to experiment implementing my original caching idea with CPython, but no time! Cheers, Damien.

4 years, 4 months

FAT Python (lack of) performance

by Victor Stinner

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 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

4 years, 4 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev January 2016