Re: [Python-Dev] Ctypes and the stdlib (was Re: LZMA compression support in 3.3)
Dan Stromberg wrote: > SIP's approach of using something close to, but not identical to, the .h's > sounds like it might be pretty productive - especially if the derivative > of the .h's could be automatically derived using a python script, with > minor > tweaks to the inputs on .h upgrades. But sip itself is apparently > C++-only. http://www.riverbankcomputing.co.uk/software/sip/intro "What is SIP? One of the features of Python that makes it so powerful is the ability to take existing libraries, written in C or C++, and make them available as Python extension modules. Such extension modules are often called bindings for the library. SIP is a tool that makes it very easy to create Python bindings for C and C++ libraries. It was originally developed to create PyQt, the Python bindings for the Qt toolkit, but can be used to create bindings for any C or C++ library. " It's not C++ only. The code for SIP is also in C. Jeremy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 optimizations continued...
stefan brunthaler, 02.09.2011 06:37: as promised, I created a publicly available preview of an implementation with my optimizations, which is available under the following location: https://bitbucket.org/py3_pio/preview/wiki/Home I followed Nick's advice and added some valuable advice and overview/introduction at the wiki page the link points to, I am positive that spending 10mins reading this will provide you with a valuable information regarding what's happening. It does, thanks. A couple of remarks: 1) The SFC optimisation is purely based on static code analysis, right? I assume it takes loops into account (and just multiplies scores for inner loops)? Is that what you mean with "nesting level"? Obviously, static analysis can sometimes be misleading, e.g. when there's a rare special case with lots of loops that needs to adapt input data in some way, but in general, I'd expect that this heuristic would tend to hit the important cases, especially for well structured code with short functions. 2) The RC elimination is tricky to get right and thus somewhat dangerous, but sounds worthwhile and should work particularly well on a stack based byte code interpreter like CPython. 3) Inline caching also sounds worthwhile, although I wonder how large the savings will be here. You'd save a couple of indirect jumps at the C-API level, sure, but apart from that, my guess is that it would highly depend on the type of instruction. Certain (repeated) calls to C implemented functions would likely benefit quite a bit, for example, which would be a nice optimisation by itself, e.g. for builtins. I would expect that the same applies to iterators, even a couple of percent faster iteration can make a great deal of a difference, and a substantial set of iterators are implemented in C, e.g. itertools, range, zip and friends. I'm not so sure about arithmetic operations. In Cython, we (currently?) do not optimistically replace these with more specific code (unless we know the types at compile time), because it complicates the generated C code and indirect jumps aren't all that slow that the benefit would be important. Savings are *much* higher when data can be unboxed, so much that the slight improvement for optimistic type guesses is totally dwarfed in Cython. I would expect that the return of investment is better when the types are actually known at runtime, as in your case. 4) Regarding inlined object references, I would expect that it's much more worthwhile to speed up LOAD_GLOBAL and LOAD_NAME than LOAD_CONST. I guess that this would be best helped by watching the module dict and the builtin dict internally and invalidating the interpreter state after changes (e.g. by providing a change counter in those dicts and checking that in the instructions that access them), and otherwise keeping the objects cached. Simply watching the dedicated instructions that change that state isn't enough as Python allows code to change these dicts directly through their dict interface. All in all, your list does sound like an interesting set of changes that are both understandable and worthwhile. Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 optimizations continued...
> as promised, I created a publicly available preview of an > implementation with my optimizations, which is available under the > following location: > https://bitbucket.org/py3_pio/preview/wiki/Home > One very important thing that I forgot was to indicate that you have to use computed gotos (i.e., "configure --with-computed-gotos"), otherwise it won't work (though I think that most people can figure this out easily, knowing this a priori isn't too bad.) Regards, --stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 optimizations continued...
> 1) The SFC optimisation is purely based on static code analysis, right? I > assume it takes loops into account (and just multiplies scores for inner > loops)? Is that what you mean with "nesting level"? Obviously, static > analysis can sometimes be misleading, e.g. when there's a rare special case > with lots of loops that needs to adapt input data in some way, but in > general, I'd expect that this heuristic would tend to hit the important > cases, especially for well structured code with short functions. > Yes, currently I only use the heuristic to statically estimate utility of assigning an optimized slot to a local variable. And, another yes, nested blocks (like for-statements) is what I have in mind when using "nesting level". I was told that the algorithm itself is very similar to linear scan register allocation, modulo the ability to spill values, of course. >From my benchmarks and in-depth analysis of several programs, I found this to work very well. In fact, the only situation I found is (unfortunately) one of the top-most executed functions in US' bm_django.py: There is one loop that gets almost never executed but this loop gives precedence to local variables used inside. Because of this, I have already an idea for a better approach: first, use the static heuristic to compute stack slot score, then count back-branches (I would need this anyways, as the _Py_CheckInterval has gone and OSR/hot-swapping is in general a good idea) and record their frequency. Next, just replace the current static weight of 100 by the dynamically recorded weight. Consequently, you should get better allocations. (Please note that I did some quantitative analysis of bython functions to determine that using 4 SFC-slots covers a substantial amount of functions [IIRC >95%] with the trivial scenario when there are at most 4 local variables.) > 2) The RC elimination is tricky to get right and thus somewhat dangerous, > but sounds worthwhile and should work particularly well on a stack based > byte code interpreter like CPython. > Well, it was very tricky to get right when I implemented it first around Christmas 2009. The current implementation is reasonably simple to understand, however, it depends on the function refcount_effect to give me correct information at all times. I got the biggest performance improvement on one benchmark on the PowerPC and think that RISC architectures in general benefit more from this optimization (eliminate the load, add and store instructions) than x86 CISCs do (an INCREF is just an add on the memory location without data dependencies, so fairly cheap). In any case, however, you get the replication effect of improving CPU branch predicion by having these additional instruction derivatives. It would be interesting (research-wise, too) to be able to measure whether the reduction in memory operations makes Python programs use less energy, and if so, how much the difference is. > 3) Inline caching also sounds worthwhile, although I wonder how large the > savings will be here. You'd save a couple of indirect jumps at the C-API > level, sure, but apart from that, my guess is that it would highly depend on > the type of instruction. Certain (repeated) calls to C implemented functions > would likely benefit quite a bit, for example, which would be a nice > optimisation by itself, e.g. for builtins. I would expect that the same > applies to iterators, even a couple of percent faster iteration can make a > great deal of a difference, and a substantial set of iterators are > implemented in C, e.g. itertools, range, zip and friends. > > I'm not so sure about arithmetic operations. In Cython, we (currently?) do > not optimistically replace these with more specific code (unless we know the > types at compile time), because it complicates the generated C code and > indirect jumps aren't all that slow that the benefit would be important. > Savings are *much* higher when data can be unboxed, so much that the slight > improvement for optimistic type guesses is totally dwarfed in Cython. I > would expect that the return of investment is better when the types are > actually known at runtime, as in your case. > Well, in my thesis I already hint at another improvement of the existing design that can work on unboxed data as well (while still being an interpreter.) I am eager to try this, but don't know how much time I can spend on this (because there are several other research projects I am actively involved in.) In my experience, this works very well and you cannot actually report good speedups without inline-caching arithmetic operations, simply because that's where all JITs shine and most benchmarks don't reflect real world scenarios but mathematics-inclined microbenchmarks. Also, if in the future compilers (gcc and clang) will be able to inline the invoked functions, higher speedups will be possible. > 4) Regarding inlined object references, I would expect that it's much more > worthwhile to speed up LOAD_
[Python-Dev] Multigigabyte memory usage in the OpenIndiana Buildbot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A single instance of buildbot in the OpenIndiana buildbot is eating 1.4GB of RAM and 3.8GB of SWAP and growing. The build hangs or die with a "out of memory" error, eventually. This is 100% reproducible. Everytime I force a build thru the buildbot control page, I see this: takes huge memory and dies with an "out of memory" or hangs. I am allocating 4GB to the buildbots. I think this is not normal. I am the only one seen such a memory usage?. I haven't changed anything in my buildbots for months... - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [email protected] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[email protected] _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTmD81plgi5GaxT1NAQJIfQP+LvxG8jGDcfdsKB3omkM8fE/pA3q3yVQL qVtSPQomCNB3hhhctEXnSFmDDekOTroCTpU9lYp6c9ZLmSCEGJx7bVW/53hk9ZJv oMNwSHvQbrZy/eWuJAlSUqIl2oAmMP75RiDhL2eqBu/alhavK8oXCeDV7iG9EvZq 0RH9Weqr788= =3jyf -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2011-08-26 - 2011-09-02) 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: open2967 ( +4) closed 21701 (+36) total 24668 (+40) Open issues with patches: 1283 Issues opened (32) == #12837: Patch for issue #12810 removed a valid check on socket ancilla http://bugs.python.org/issue12837 reopened by brett.cannon #12848: pickle.py treats 32bit lengths as signed, but _pickle.c as uns http://bugs.python.org/issue12848 opened by pitrou #12849: urllib2 headers issue http://bugs.python.org/issue12849 opened by shubhojeet.ghosh #12850: [PATCH] stm.atomic http://bugs.python.org/issue12850 opened by arigo #12851: ctypes: getbuffer() never provides strides http://bugs.python.org/issue12851 opened by skrah #12852: POSIX level issues in posixmodule.c on OpenBSD 5.0 http://bugs.python.org/issue12852 opened by rpointel #12853: global name 'r' is not defined in upload.py http://bugs.python.org/issue12853 opened by reowen #12854: PyOS_Readline usage in tokenizer ignores sys.stdin/sys.stdout http://bugs.python.org/issue12854 opened by Albert.Zeyer #12855: linebreak sequences should be better documented http://bugs.python.org/issue12855 opened by Matthew.Boehm #12856: tempfile PRNG reuse between parent and child process http://bugs.python.org/issue12856 opened by ferringb #12857: Expose called function on frame object http://bugs.python.org/issue12857 opened by eric.snow #12858: crypt.mksalt: use ssl.RAND_pseudo_bytes() if available http://bugs.python.org/issue12858 opened by haypo #12860: http client attempts to send a readable object twice http://bugs.python.org/issue12860 opened by langmartin #12861: PyOS_Readline uses single lock http://bugs.python.org/issue12861 opened by Albert.Zeyer #12862: ConfigParser does not implement "comments need to be preceded http://bugs.python.org/issue12862 opened by DanielFortunov #12863: py32 > Lib > xml.minidom > usage feedback > overrides http://bugs.python.org/issue12863 opened by GPU.Group #12864: 2to3 creates illegal code on import a.b inside a package http://bugs.python.org/issue12864 opened by simohe #12866: Want to submit our Audioop.c patch for 24bit audio http://bugs.python.org/issue12866 opened by Peder.Jørgensen #12869: PyOS_StdioReadline is printing the prompt on stderr http://bugs.python.org/issue12869 opened by Albert.Zeyer #12870: Regex object should have introspection methods http://bugs.python.org/issue12870 opened by mattchaput #12871: Disable sched_get_priority_min/max if Python is compiledwitho http://bugs.python.org/issue12871 opened by haypo #12872: --with-tsc crashes on ppc64 http://bugs.python.org/issue12872 opened by dmalcolm #12873: 2to3 incorrectly handles multi-line imports from __future__ http://bugs.python.org/issue12873 opened by Arfrever #12875: backport re.compile flags default value documentation http://bugs.python.org/issue12875 opened by eli.bendersky #12876: Make Test Error : ImportError: No module named _sha256 http://bugs.python.org/issue12876 opened by wah meng #12878: io.StringIO doesn't provide a __dict__ field http://bugs.python.org/issue12878 opened by ericp #12880: ctypes: clearly document how structure bit fields are allocate http://bugs.python.org/issue12880 opened by meadori #12881: ctypes: segfault with large structure field names http://bugs.python.org/issue12881 opened by meadori #12882: mmap crash on Windows http://bugs.python.org/issue12882 opened by itabhijitb #12883: xml.sax.xmlreader.AttributesImpl allows empty string as attrib http://bugs.python.org/issue12883 opened by Michael.Sulyaev #12885: distutils.filelist.findall() fails on broken symlink in Py2.x http://bugs.python.org/issue12885 opened by Alexander.Dutton #12886: datetime.strptime parses input wrong http://bugs.python.org/issue12886 opened by heidar.rafn Most recent 15 issues with no replies (15) == #12885: distutils.filelist.findall() fails on broken symlink in Py2.x http://bugs.python.org/issue12885 #12883: xml.sax.xmlreader.AttributesImpl allows empty string as attrib http://bugs.python.org/issue12883 #12881: ctypes: segfault with large structure field names http://bugs.python.org/issue12881 #12880: ctypes: clearly document how structure bit fields are allocate http://bugs.python.org/issue12880 #12873: 2to3 incorrectly handles multi-line imports from __future__ http://bugs.python.org/issue12873 #12872: --with-tsc crashes on ppc64 http://bugs.python.org/issue12872 #12869: PyOS_StdioReadline is printing the prompt on stderr http://bugs.python.org/issue12869 #12866: Want to submit our Audioop.c patch for 24bit audio http://bugs.python.org/issue12866 #12864: 2to3 creates illegal code on import a.b inside a package http://bugs.python.org/issue12864 #12863: py32 > Lib > xml.minidom
Re: [Python-Dev] PEP 393 Summer of Code Project
On Sep 1, 2011, at 9:30 PM, Steven D'Aprano wrote: > Antoine Pitrou wrote: >> Le jeudi 01 septembre 2011 à 08:45 -0700, Guido van Rossum a écrit : >>> This is definitely thought of as a separate >>> mark added to the e; ë is not a new letter. I have a feeling it's the same >>> way for the French and Germans, but I really don't know. >>> (Antoine? Georg?) >> Indeed, they are not separate "letters" (they are considered the same in >> lexicographic order, and the French alphabet has 26 letters). > > > On the other hand, the same doesn't necessarily apply to other languages. (At > least according to Wikipedia.) > > http://en.wikipedia.org/wiki/Diacritic#Languages_with_letters_containing_diacritics For example, in Serbo-Croatian (Serbian, Croatian, Bosnian, Montenegrin, if you want), each of the following letters represent one distinct sound of the language. In Serbian Cyrillic alphabet, they are distinct symbols. In Latin alphabet, the corresponding letters are formed with diacritics because the alphabet is shorter. Letter Approximate pronunciation Cyrillic -- - č tch in butcher ч ć ch in chapter, but softer ћ dž j in jump џ đ j in juice ђ š sh in ship ш ž s in pleasure, measure, ... ж The language has 30 sounds and the corresponding 30 letters. See the count of the letters in these tables: - http://hr.wikipedia.org/wiki/Hrvatska_abeceda - http://sr.wikipedia.org/wiki/Азбука Diacritics are used in grammar books and in print (occasionally) to distinguish between four different accents of the language: - long rising: á, - short rising: à, - long falling: ȃ (inverted breve, *not* a circumflex â), and - short falling: ȁ, especially when the words that use the same sounds -- thus, spelled with the same letters -- are next to each other. The accents are used to change the intonation of the whole word, not to change the sound of the letter. For example: "Ja sam sȃm." -- "I am alone." Both words "sam" contain the "a" sound, but the first one is pronounced short. As a form of the verb "to be" it's an enclitic that takes the accent of the preceding word "I". The second one is pronounced with a long falling accent. The macron can be used to indicate the length of a *non-stressed* vowel, e.g. ā, but is usually unnecessary in standard print. Many languages use alphabets that are not suitable to their sound system. The speakers of these languages adapted alphabets to their sounds either by using letters with distinct shapes (Cyrillic letters above), or adding diacritics to an existing shape (Latin letters above). The new combined form is a distinct letter. These letters have separate sections in dictionaries and a sorting order. The diacritics that indicate an accent or length are used only above vowels and do *not* represent distinct letters. Best regards, Zvezdan Petković P.S. Since I live in the USA, the last letter of my surname is *wrongly* spelled (ć -> c) and pronounced (ch -> k) most of the time. :-) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 optimizations continued...
stefan brunthaler, 02.09.2011 17:55: 4) Regarding inlined object references, I would expect that it's much more worthwhile to speed up LOAD_GLOBAL and LOAD_NAME than LOAD_CONST. I guess that this would be best helped by watching the module dict and the builtin dict internally and invalidating the interpreter state after changes (e.g. by providing a change counter in those dicts and checking that in the instructions that access them), and otherwise keeping the objects cached. Simply watching the dedicated instructions that change that state isn't enough as Python allows code to change these dicts directly through their dict interface. [...] Thanks for the pointers to the dict stuff, I will take a look (IIRC, Antoine pointed me in the same direction last year, but I think the design was slightly different then), Not unlikely, Antoine tends to know the internals pretty well. The Cython project has been (hand wavingly) thinking about this also: implement our own module type with its own __setattr__ (and dict proxy) in order to speed up access to the globals in the *very* likely case that they rarely or never change after module initialisation time and that most critical code accesses them read-only from within functions. If it turns out that this makes sense for CPython in general, it wouldn't be a bad idea to join forces at some point in order to make this readily usable for both sides. Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Multigigabyte memory usage in the OpenIndiana Buildbot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/09/11 17:57, Jesus Cea wrote: > The build hangs or die with a "out of memory" error, eventually. A simple "make test" with python not compiled with "pydebug" and skipping all the optional tests (like zip64) is taking up to 300MB of RAM. Python 2.7 branch, current tip. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [email protected] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[email protected] _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTmEYIZlgi5GaxT1NAQK79gP/aRyMqgEE7uScYtrZzPqs0ZSpGnVM8sBi RbNEN3cB/s6Oe/UVIo4vinaDnXXYSOM5qtqghUl5Cnx+wiiK2cL8iIv/YzZbjT9s U8QELEkol8lpjAVPEO/rSylZ5kvsmdjkM2mU6NOwiLGw+mmbbgqpmdAU14p+sqSO 2xFJElgOHuM= =YA0J -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Multigigabyte memory usage in the OpenIndiana Buildbot
On Fri, 02 Sep 2011 19:53:37 +0200 Jesus Cea wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 02/09/11 17:57, Jesus Cea wrote: > > The build hangs or die with a "out of memory" error, eventually. > > A simple "make test" with python not compiled with "pydebug" and > skipping all the optional tests (like zip64) is taking up to 300MB of > RAM. Python 2.7 branch, current tip. Can you tell if it's something recent or it has always been like that? Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 393 Summer of Code Project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/01/2011 11:59 PM, Stephen J. Turnbull wrote: > Tres Seaver writes: > >> FWIW, I was taught that Spanish had 30 letters in the alfabeto: >> the 'ñ', plus 'ch', 'll', and 'rr' were all considered distinct >> characters. > > That was always a Castellano vs. Americano issue, IIRC. As I wrote, > Mr. Gonzalez was Castellano. - From a casual web search, it looks as though the RAE didn't legislate "letterness" away from the digraphs (as I learned them) until 1994 (about 25 years after I learned the 30-letter alfabeto). > I believe that the deprecation of the digraphs as separate letters > occurred as the telephone became widely used in Spain, and the > telephone company demanded an official proclamation from whatever > Ministry is responsible for culture that it was OK to treat the > digraphs as two letters (specifically, to collate them that way), so > that they could use the programs that came with the OS. > > So this stuff is not merely variant by culture, but also by > economics and politics. :-/ Lovely. :) Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5hHswACgkQ+gerLs4ltQ7m9ACeOJZRgjcm9pd0Rnry26zP0I3t 53cAoLv78VD5eIdbjvboLaysoeREIp1t =0PuR -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 optimizations continued...
> > For a comparative real world benchmark I tested Martin von Loewis' > django port (there are not that many meaningful Python 3 real world > benchmarks) and got a speedup of 1.3 (without IIS). This is reasonably > well, US got a speedup of 1.35 on this benchmark. I just checked that > pypy-c-latest on 64 bit reports 1.5 (the pypy-c-jit-latest figures > seem to be not working currently or *really* fast...), but I cannot > tell directly how that relates to speedups (it just says "less is > better" and I did not quickly find an explanation). > Since I did this benchmark last year, I have spent more time > investigating this benchmark and found that I could do better, but I > would have to guess as to how much (An interesting aside though: on > this benchmark, the executable never grew on more than 5 megs of > memory usage, exactly like the vanilla Python 3 interpreter.) > PyPy is ~12x faster on the django benchmark FYI ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 optimizations continued...
Maciej Fijalkowski, 02.09.2011 20:42: For a comparative real world benchmark I tested Martin von Loewis' django port (there are not that many meaningful Python 3 real world benchmarks) and got a speedup of 1.3 (without IIS). This is reasonably well, US got a speedup of 1.35 on this benchmark. I just checked that pypy-c-latest on 64 bit reports 1.5 (the pypy-c-jit-latest figures seem to be not working currently or *really* fast...), but I cannot tell directly how that relates to speedups (it just says "less is better" and I did not quickly find an explanation). PyPy is ~12x faster on the django benchmark FYI FYI, there's a recent thread up on the pypy ML where someone is complaining about PyPy being substantially slower than CPython when running Django on top of SQLite. Also note that PyPy doesn't implement Py3 yet, so the benchmark results are not comparable anyway. As usual, benchmark results depend on what you do in your benchmarks. Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 optimizations continued...
On Fri, Sep 2, 2011 at 9:20 PM, Stefan Behnel wrote: > Maciej Fijalkowski, 02.09.2011 20:42: >>> >>> For a comparative real world benchmark I tested Martin von Loewis' >>> django port (there are not that many meaningful Python 3 real world >>> benchmarks) and got a speedup of 1.3 (without IIS). This is reasonably >>> well, US got a speedup of 1.35 on this benchmark. I just checked that >>> pypy-c-latest on 64 bit reports 1.5 (the pypy-c-jit-latest figures >>> seem to be not working currently or *really* fast...), but I cannot >>> tell directly how that relates to speedups (it just says "less is >>> better" and I did not quickly find an explanation). >> >> PyPy is ~12x faster on the django benchmark FYI > > FYI, there's a recent thread up on the pypy ML where someone is complaining > about PyPy being substantially slower than CPython when running Django on > top of SQLite. Also note that PyPy doesn't implement Py3 yet, so the > benchmark results are not comparable anyway. Yes, sqlite is slow. It's also much faster in trunk than in 1.6 and there is an open ticket about it :) The "django" benchmark is just templating, so it does not involve a database. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 393 Summer of Code Project
Terry Reedy wrote: While it has apparently been criticized as 'conservative' (which is well ought to be), it has been rather progressive in promoting changes such as 'ph' to 'f' (fisica, fone) and dropping silent 'p' in leading 'psi' (sicologia) and silent 's' in leading 'sci' (ciencia). I find it curious that pronunciation always seems to take precedence over spelling in campaigns like this. Nowadays, especially with the internet increasingly taking over from personal interaction, we probably see words written a lot more often than we hear them spoken. Why shouldn't we change the pronunciation to match the spelling rather than the other way around? -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 393 Summer of Code Project
Greg Ewing writes: > I find it curious that pronunciation always seems to take > precedence over spelling in campaigns like this. Nowadays, > especially with the internet increasingly taking over from > personal interaction, we probably see words written a lot > more often than we hear them spoken. Why shouldn't we > change the pronunciation to match the spelling rather than > the other way around? Because 90% of all people move their lips when reading. :-) More seriously, because almost nobody learns to read before learning to understand spoken language. Aural language is more primitive than written language. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
