Re: [Python-Dev] A new JIT compiler for a faster CPython?
On 17 Jul 2012, at 23:04, mar...@v.loewis.de wrote: [snip...] I would like to use a JIT to generate specialized functions for a combinaison of arguments types. I think history has moved past specializing JITs. Tracing JITs are the status quo; they provide specialization as a side effect. Mozilla implemented a method-JIT (compile whole methods) on top of their tracing JIT because a tracing JIT only optimises part of your code (only in loops and only if executed more times than the threshold) and there are further performance improvements to be had. So tracing JITs are not the *whole* of the state of the art. Michael Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new JIT compiler for a faster CPython?
That's not, strictly speaking, true. Mozilla added a method-JIT (Jaegermonkey) and then added another one (IonMonkey) because their tracing JIT (Tracemonkey) was bad. There's no fundamental reason that tracing has to only cover loops, indeed PyPy's tracing has been generalized to compile individual functions, recursion, etc. And any profiling JIT, in practice, needs a compile heuristic for how many calls must occur before a unit is compiled, even the Hotspot JVM has one. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new JIT compiler for a faster CPython?
On Tue, Jul 17, 2012 at 3:20 PM, Victor Stinner victor.stin...@gmail.com wrote: It's the JIT compiler of Unladen Swallow that failed; in my understanding because LLVM is crap (i.e. it is slow, memory-consuming, and buggy) - as a low-level virtual machine; it may be ok as a compiler backend (but I still think it is buggy there as well). What is the status of LLVM nowadays? Is it not a good solution to write a portable JIT? Its code generator is still fairly slow. You could probably get a faster one committed, but you'd have to write it. LLVM also still doesn't have great profile-guided optimizations (what you need in a JIT), although the infrastructure is starting to be built. You'd probably have to contribute to that too. It's probably a better use of your time to contribute to PyPy. Jeffrey ___ Python-Dev mailing list Python-Dev@python.org 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 (2012-07-13 - 2012-07-20)
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:
open3528 ( +8)
closed 23658 (+55)
total 27186 (+63)
Open issues with patches: 1501
Issues opened (39)
==
#9374: urlparse should parse query and fragment for arbitrary schemes
http://bugs.python.org/issue9374 reopened by eric.araujo
#9803: IDLE closes with save while breakpoint open
http://bugs.python.org/issue9803 reopened by serwy
#15346: Tkinter dnd has no documentation
http://bugs.python.org/issue15346 opened by weirdink13
#15347: IDLE - does not close if the debugger was active
http://bugs.python.org/issue15347 opened by serwy
#15348: IDLE - shell becomes unresponsive if debugger windows is close
http://bugs.python.org/issue15348 opened by serwy
#15350: {urllib,urllib.parse}.urlencode.__doc__ is unclear
http://bugs.python.org/issue15350 opened by samwyse
#15351: Add to unittest.TestCase support for using context managers
http://bugs.python.org/issue15351 opened by cjerdonek
#15352: importlib.h should be regenerated when the marshaling code cha
http://bugs.python.org/issue15352 opened by meador.inge
#15353: ld: library not found for -lpython3.3m because of wrong LDFLAG
http://bugs.python.org/issue15353 opened by Jerry.Jacobs
#15355: generator.__next__() docs should mention exception if already
http://bugs.python.org/issue15355 opened by cjerdonek
#15358: Test pkgutil.walk_packages in test_pkgutil instead of test_run
http://bugs.python.org/issue15358 opened by ncoghlan
#15359: Sockets support for CAN_BCM
http://bugs.python.org/issue15359 opened by Thorney
#15360: Behavior of assigning to __dict__ is not documented
http://bugs.python.org/issue15360 opened by davide.rizzo
#15362: pyport.h includes antiquated UTF handling for FreeBSD
http://bugs.python.org/issue15362 opened by JohnSchneider
#15363: Idle/tkinter ~x.py 'save as' fails. closes idle
http://bugs.python.org/issue15363 opened by terry.reedy
#15364: sysconfig confused by relative paths
http://bugs.python.org/issue15364 opened by sbt
#15365: Traceback reporting can fail if IO cannot be imported
http://bugs.python.org/issue15365 opened by kristjan.jonsson
#15369: pybench and test.pystone poorly documented
http://bugs.python.org/issue15369 opened by flox
#15370: test_runpy should include namespace package tests
http://bugs.python.org/issue15370 opened by ncoghlan
#15371: test_cmd_line_script should include namespace package tests
http://bugs.python.org/issue15371 opened by ncoghlan
#15373: copy.copy() does not properly copy os.environment
http://bugs.python.org/issue15373 opened by htgoebel
#15376: Refactor the test_runpy walk_package support code into a commo
http://bugs.python.org/issue15376 opened by cjerdonek
#15378: Underported Tools/unicode/comparecodecs.py
http://bugs.python.org/issue15378 opened by storchaka
#15379: Charmap decoding of no-BMP characters
http://bugs.python.org/issue15379 opened by storchaka
#15381: Optimize BytesIO to so less reallocations when written, simila
http://bugs.python.org/issue15381 opened by eli.bendersky
#15382: os.utime() mishandles some arguments
http://bugs.python.org/issue15382 opened by Arfrever
#15388: SAX parse (ExpatParser) leaks file handle when given filename
http://bugs.python.org/issue15388 opened by mth
#15389: PEP 3121, 384 refactoring applied to curses module
http://bugs.python.org/issue15389 opened by Robin.Schreiber
#15390: PEP 3121, 384 refactoring applied to datetime module
http://bugs.python.org/issue15390 opened by Robin.Schreiber
#15392: Create a unittest framework for IDLE
http://bugs.python.org/issue15392 opened by terry.reedy
#15393: JSONDecoder.raw_decode breaks on leading whitespace
http://bugs.python.org/issue15393 opened by aalien
#15397: Unbinding of methods
http://bugs.python.org/issue15397 opened by mstefanro
#15398: intermittence on UnicodeFileTests.test_rename at test_pep277 o
http://bugs.python.org/issue15398 opened by flavio.ribeiro
#15402: Correct __sizeof__ support for struct
http://bugs.python.org/issue15402 opened by storchaka
#15403: Refactor package creation support code into a common location
http://bugs.python.org/issue15403 opened by cjerdonek
#15406: Deprecation Warnings fixes on test suite
http://bugs.python.org/issue15406 opened by flavio.ribeiro
#15407: CSV parser fails to iterate properly on 2.6.6
http://bugs.python.org/issue15407 opened by sleepycal
#15408: os.fork/os.popen behaviour change between 2.7 and 3.2
http://bugs.python.org/issue15408 opened by doerwalter
#1492704: distinct error type if shutil.copyfile() fails because of src
http://bugs.python.org/issue1492704 reopened by hynek
Most recent 15 issues with no replies (15)
==
#15408: os.fork/os.popen behaviour change between 2.7 and 3.2
Re: [Python-Dev] A new JIT compiler for a faster CPython?
On Fri, Jul 20, 2012 at 2:55 PM, Michael Foord fuzzy...@voidspace.org.ukwrote: On 17 Jul 2012, at 23:04, mar...@v.loewis.de wrote: [snip...] I would like to use a JIT to generate specialized functions for a combinaison of arguments types. I think history has moved past specializing JITs. Tracing JITs are the status quo; they provide specialization as a side effect. Mozilla implemented a method-JIT (compile whole methods) on top of their tracing JIT because a tracing JIT only optimises part of your code (only in loops and only if executed more times than the threshold) and there are further performance improvements to be had. So tracing JITs are not the *whole* of the state of the art. Michael I'm sorry michael but you're like a 100th person I have to explain this to. The pure reason that mozilla did not make a tracing JIT work does not mean the entire approach is horribly doomed as many people would like to assume. The reasons are multiple, but a lot of them are connected to poor engineering (for example the part inherited from adobe is notoriously bad, have a look if you want). Cheers, fijal ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #15168: Move importlb.test to test.test_importlib.
On Fri, 20 Jul 2012 20:49:03 +0200 (CEST) brett.cannon python-check...@python.org wrote: diff --git a/Lib/importlib/test/__init__.py b/Lib/test/test_importlib/__init__.py rename from Lib/importlib/test/__init__.py rename to Lib/test/test_importlib/__init__.py --- a/Lib/importlib/test/__init__.py +++ b/Lib/test/test_importlib/__init__.py @@ -1,5 +1,6 @@ import os import sys +from .. import support I don't know if I'm only speaking for myself, but I really have trouble parsing non-trivial relative imports, and I personally prefer when people use absolute imports (e.g. from test import support). cheers Antoine. -- Software development and contracting: http://pro.pitrou.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #15168: Move importlb.test to test.test_importlib.
On Fri, 20 Jul 2012 22:12:26 +0200, Antoine Pitrou solip...@pitrou.net wrote: On Fri, 20 Jul 2012 20:49:03 +0200 (CEST) brett.cannon python-check...@python.org wrote: diff --git a/Lib/importlib/test/__init__.py b/Lib/test/test_importlib/__init__.py rename from Lib/importlib/test/__init__.py rename to Lib/test/test_importlib/__init__.py --- a/Lib/importlib/test/__init__.py +++ b/Lib/test/test_importlib/__init__.py @@ -1,5 +1,6 @@ import os import sys +from .. import support I don't know if I'm only speaking for myself, but I really have trouble parsing non-trivial relative imports, and I personally prefer when people use absolute imports (e.g. from test import support). Agreed. I don't see that there is any reason to use relative imports in the stdlib. --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #15168: Move importlb.test to test.test_importlib.
+1 On Fri, Jul 20, 2012 at 11:25 PM, R. David Murray rdmur...@bitdance.com wrote: On Fri, 20 Jul 2012 22:12:26 +0200, Antoine Pitrou solip...@pitrou.net wrote: On Fri, 20 Jul 2012 20:49:03 +0200 (CEST) brett.cannon python-check...@python.org wrote: diff --git a/Lib/importlib/test/__init__.py b/Lib/test/test_importlib/__init__.py rename from Lib/importlib/test/__init__.py rename to Lib/test/test_importlib/__init__.py --- a/Lib/importlib/test/__init__.py +++ b/Lib/test/test_importlib/__init__.py @@ -1,5 +1,6 @@ import os import sys +from .. import support I don't know if I'm only speaking for myself, but I really have trouble parsing non-trivial relative imports, and I personally prefer when people use absolute imports (e.g. from test import support). Agreed. I don't see that there is any reason to use relative imports in the stdlib. --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com -- Thanks, Andrew Svetlov ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new JIT compiler for a faster CPython?
On Jul 18, 2012, at 3:30 AM, Nick Coghlan wrote: - Eugene Toder's patch to add an AST optimisation step to the compiler chain (http://bugs.python.org/issue11549) (I've asked Eugene about this patch more recently and his current thought is that subsequent improvements to the peephole optimisation have rendered it less valuable. However, the patch is still a potentially useful resource for anyone investigating bytecode optimisation ideas) +1 for furthering Eugene's patch. The AST is the correct place to do some of the optimizations currently done by the peepholer. Raymond___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
