Re: [Python-Dev] msvcr90 support was added to mingw
On 30/11/2007, Christian Heimes <[EMAIL PROTECTED]> wrote: > Paul Moore got some Cygwin developers persuaded to implement support for > msvcr90 [1]. The coded was added a few days ago [2]. This means that > users are still able to use MinGW to compile extensions when we switch > to VS 2008 as default compiler on Windows. > > I'm not sure how many people are interested in the topic but some may be > glad to hear that MinGW is still supported. Thanks for letting people know about this Christian! I'm waiting until there's a released binary with this included (or I get time to work out how to build my own!), and then I'll work up a patch for distutils to make this work. Paul. ___ 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] [poll] New name for __builtins__
On Nov 30, 2007, at 6:05 PM, Guido van Rossum wrote: > It's almost as if nobody has seen my proposal to leave __builtins__ > alone and rename the __builtin__ module instead. I suspect that's indistinguishable from everyone being tired of the discussion, knowing that you're going to pick something reasonable in spite of our yammering. +1 for a module named "builtin", or something similarly obscure. -Fred -- Fred Drake ___ 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] [poll] New name for __builtins__
On Nov 30, 2007 3:59 PM, Greg Ewing <[EMAIL PROTECTED]> wrote: > Terry Reedy wrote: > > The only problem would be if someone put > > the incantation into a non-main module named 'main.py', but the same is > > true today of '__main__.py'. And I would consider either a buggy practice. > > I often put the "real" main code into a separate module, so > that it gets compiled to a .pyc, and sometimes I call that > module "main.py". So this change would break a lot of my > programs, and perhaps other people's as well. > > I think the situation with __main__ is different from __builtin__, > because __builtin__ is an actual, specific module, whereas > __main__ is a pseudo-module which stands in for a different thing > in every Python program. So I'm in favour of keeping an > __xxx__ name for it, to emphasise its magic nature. I'm much > less likely to accidentally stomp on a magic name than a > non-magic one. Right. Rest assured, __main__ is not going to change. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] -O2 faster than -O3?
On Nov 30, 2007 12:02 PM, Neil Toronto <[EMAIL PROTECTED]> wrote: > On both of my systems, using -O2 reduces execution time in pystone by 9% > and in pybench by 8%. It's function inlining: "-O3 > -fno-inline-functions" works just as well as "-O2". Removing "-g" has > little effect on the result. > > Systems: > - AMD Athlon 64 X2 Dual Core 4600+, 512 KB cache (desktop) > - Intel T2300 Dual Core 1.66GHz, 512 KB cache (laptop) > > Both are Ubuntu 7.04, GCC 4.1.2. > > Does anybody else see this? > > It may be GCC being stupid (which has happened before) or not enough > cache on my systems (definitely possible). If it's not one of those, I'd > say it's because CPython core functions are already very large, and > almost everything that ought to be inlined is already a macro. > That's quite possible. Previous benchmarks by AMK have shown that perhaps -0m (or whatever the flag is to optimize for size) sometimes is the best solution. It has always been believed that the eval loop is already large and manages to hit some cache sweet spot. -Brett ___ 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] [poll] New name for __builtins__
On Nov 30, 2007 3:16 PM, Fred Drake <[EMAIL PROTECTED]> wrote: > On Nov 30, 2007, at 6:05 PM, Guido van Rossum wrote: > > It's almost as if nobody has seen my proposal to leave __builtins__ > > alone and rename the __builtin__ module instead. > > > I suspect that's indistinguishable from everyone being tired of the > discussion, knowing that you're going to pick something reasonable in > spite of our yammering. > Yeah. I figured your rambling tolerance had already been hit on this and you were just going to pick something. > +1 for a module named "builtin", or something similarly obscure. +1 for your (Guido's) 'builtins' suggestion so that there is symmetry with __builtins__ and 'builtins'. -Brett > > >-Fred > > -- > Fred Drake > > > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ 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] [poll] New name for __builtins__
Terry Reedy wrote: > The only problem would be if someone put > the incantation into a non-main module named 'main.py', but the same is > true today of '__main__.py'. And I would consider either a buggy practice. I often put the "real" main code into a separate module, so that it gets compiled to a .pyc, and sometimes I call that module "main.py". So this change would break a lot of my programs, and perhaps other people's as well. I think the situation with __main__ is different from __builtin__, because __builtin__ is an actual, specific module, whereas __main__ is a pseudo-module which stands in for a different thing in every Python program. So I'm in favour of keeping an __xxx__ name for it, to emphasise its magic nature. I'm much less likely to accidentally stomp on a magic name than a non-magic one. -- 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] [poll] New name for __builtins__
> > On Nov 30, 2007, at 6:05 PM, Guido van Rossum wrote: > >> It's almost as if nobody has seen my proposal to leave __builtins__ > >> alone and rename the __builtin__ module instead. > Fred Drake wrote: > > +1 for a module named "builtin", or something similarly obscure. On Nov 30, 2007 3:42 PM, Neil Toronto <[EMAIL PROTECTED]> wrote: > Would it be too confusing to call it "builtins"? To the contrary, I like that best (and want to note for the record that that's what I proposed when I first brought it up here :-). If someone wants to prepare a patch, be my guest! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] [poll] New name for __builtins__
Fred Drake wrote: > On Nov 30, 2007, at 6:05 PM, Guido van Rossum wrote: >> It's almost as if nobody has seen my proposal to leave __builtins__ >> alone and rename the __builtin__ module instead. > > > I suspect that's indistinguishable from everyone being tired of the > discussion, knowing that you're going to pick something reasonable in > spite of our yammering. > > +1 for a module named "builtin", or something similarly obscure. Would it be too confusing to call it "builtins"? Neil ___ 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] [poll] New name for __builtins__
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 30, 2007, at 6:05 PM, Guido van Rossum wrote: > On Nov 30, 2007 2:17 PM, Nicko van Someren <[EMAIL PROTECTED]> wrote: >> +1 for __universal__ > > It's almost as if nobody has seen my proposal to leave __builtins__ > alone and rename the __builtin__ module instead. Hi Guido, I saw it, and I like that change much better! There's no real need to underscorify the module name. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR1CaVnEjvBPtnXfVAQJk6QP/Z02maduXygFtbObY8LhdwW7sZbkvEkuW Xc0OM11xa6zPV0gAuCgrNgLS7AXJ43FgEyvmbHmQMeicu7V2Ft3xyM7riTz0AqE6 EU22PR1wbPJBWxMFB+D8ufsKAgTtYdLloqDSHrDhMpIKhETA9qUeYZOL+VM2BFaN rkaOuCo5S+4= =wG9Q -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] [poll] New name for __builtins__
On Fri, Nov 30, 2007 at 03:05:18PM -0800, Guido van Rossum wrote: > On Nov 30, 2007 2:17 PM, Nicko van Someren <[EMAIL PROTECTED]> wrote: > > +1 for __universal__ > > It's almost as if nobody has seen my proposal to leave __builtins__ > alone and rename the __builtin__ module instead. I saw it, and I think it'd be the best. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] [poll] New name for __builtins__
Thing is that "universal" is an adjective and we tend to use nouns (maybe not by intention) for our modules/objects: Sys, os, builtins, etc, are all nouns: maybe +1 for __universe__ ? But when you phrase it that way, it doesn't quite make sense. Have we considered special syntax for universal py methods? *.open() ? ::open() (ew!, by the way) ? I'm a huge fan of keeping things legible to people who don't know python, but for some weird reason __universal__ makes me feel like I am writing non-professional software. C -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nicko van Someren Sent: Friday, November 30, 2007 2:17 PM To: Isaac Morland Cc: [email protected] Subject: Re: [Python-Dev] [poll] New name for __builtins__ On 29 Nov 2007, at 14:06, Isaac Morland wrote: > > I wonder how much you could sell the naming rights for? i.e. call it > __[name of sponsor]__. Python's pretty popular, such advertising > should > be worth something I'm sorry, but if you call it __Microsoft_Office_2007__ I shall never write a program that uses what we now call __builtins__ ever again! > PS: I actually do like __universal__. Me too. +1 for __universal__ Nicko ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/cmason%40vcentertainme nt.com ___ 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] [poll] New name for __builtins__
On Nov 30, 2007 2:17 PM, Nicko van Someren <[EMAIL PROTECTED]> wrote: > +1 for __universal__ It's almost as if nobody has seen my proposal to leave __builtins__ alone and rename the __builtin__ module instead. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] [poll] New name for __builtins__
On 29 Nov 2007, at 14:06, Isaac Morland wrote: > > I wonder how much you could sell the naming rights for? i.e. call it > __[name of sponsor]__. Python's pretty popular, such advertising > should > be worth something I'm sorry, but if you call it __Microsoft_Office_2007__ I shall never write a program that uses what we now call __builtins__ ever again! > PS: I actually do like __universal__. Me too. +1 for __universal__ Nicko ___ 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] -O2 faster than -O3?
On Nov 30, 2007 7:16 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > On Nov 30, 2007 12:02 PM, Neil Toronto <[EMAIL PROTECTED]> wrote: > > On both of my systems, using -O2 reduces execution time in pystone by 9% > > and in pybench by 8%. It's function inlining: "-O3 > > -fno-inline-functions" works just as well as "-O2". Removing "-g" has > > little effect on the result. > > > > Systems: > > - AMD Athlon 64 X2 Dual Core 4600+, 512 KB cache (desktop) > > - Intel T2300 Dual Core 1.66GHz, 512 KB cache (laptop) > > > > Both are Ubuntu 7.04, GCC 4.1.2. > > > > Does anybody else see this? > > > > It may be GCC being stupid (which has happened before) or not enough > > cache on my systems (definitely possible). If it's not one of those, I'd > > say it's because CPython core functions are already very large, and > > almost everything that ought to be inlined is already a macro. > > > > That's quite possible. Previous benchmarks by AMK have shown that > perhaps -0m (or whatever the flag is to optimize for size) sometimes > is the best solution. It has always been believed that the eval loop > is already large and manages to hit some cache sweet spot. The flag is -Os. I suspect you will do better to limit the size of inlining rather disabling it completely. The option is -finline-limit=number. I don't know the default value or what you should try. I would be interested to hear more results though. n ___ 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] PATCH: Fast globals/builtins lookups for 2.6
Steve Holden wrote: > Neil Toronto wrote: >> Speaking of which, here's a question for everybody. I was wondering >> whether 64 bits is necessary. It takes an hour of concerted effort - >> nothing but "module.d = 1; del module.d" for an hour straight - to >> overflow a 32-bit version number. Is anybody going to actually get close >> to doing that in a global namespace? >> > Of course not. And 640k is as much memory as anyone could reasonably > need ... Point taken - forget I asked. Neil ___ 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] Update to PEP 366 (Relative imports from the main module)
This looks good. Please make the appropriate changes to the PEP and to
PEP 0 to mark it as accepted.
I think the implementation is fine too (others will have to check it
more carefully) but I noticed that the promised functionality of -m
doesn't work yet: I created a file Lib/test/foo.py whose sole contents
was "from . import test_support". Then I tried to import this using
-m:
$ ./python.exe -m test.foo
Traceback (most recent call last):
File "/Users/guido/p/Lib/runpy.py", line 104, in _run_module_as_main
"__main__", fname, loader)
File "/Users/guido/p/Lib/runpy.py", line 34, in _run_code
exec code in run_globals
File "/Users/guido/p/Lib/test/foo.py", line 1, in
from . import test_support
ValueError: Attempted relative import in non-package
$
What's missing here?
--Guido
On Nov 22, 2007 6:45 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> I've updated PEP 366 with a proposed implementation, as well as a few
> changes to the proposed semantics to make the implementation feasible
> (the old proposal called for imp.new_module to calculate a value when it
> didn't have access to all of the relevant information).
>
> The updated text is below, and should turn up on python.org before too long.
>
> Regards,
> Nick.
>
>
> PEP: 366
> Title: Main module explicit relative imports
> Version: $Revision$
> Last-Modified: $Date$
> Author: Nick Coghlan <[EMAIL PROTECTED]>
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 1-May-2007
> Python-Version: 2.6, 3.0
> Post-History: 1-May-2007, 4-Jul-2007, 7-Jul-2007, 23-Nov-2007
>
>
> Abstract
>
>
> This PEP proposes a backwards compatible mechanism that permits
> the use of explicit relative imports from executable modules within
> packages. Such imports currently fail due to an awkward interaction
> between PEP 328 and PEP 338.
>
> By adding a new module level attribute, this PEP allows relative imports
> to work automatically if the module is executed using the ``-m`` switch.
> A small amount of boilerplate in the module itself will allow the relative
> imports to work when the file is executed by name.
>
>
> Proposed Change
> ===
>
> The major proposed change is the introduction of a new module level
> attribute, ``__package__``. When it is present, relative imports will
> be based on this attribute rather than the module ``__name__``
> attribute.
>
> As with the current ``__name__`` attribute, setting ``__package__`` will
> be the responsibility of the PEP 302 loader used to import a module.
> Loaders which use ``imp.new_module()`` to create the module object will
> have the new attribute set automatically to ``None``. When the import
> system encounters an explicit relative import in a module without
> ``__package__`` set (or with it set to ``None``), it will calculate and
> store the correct value (``__name__.rpartition('.')[0]`` for normal
> modules and ``__name__`` for package initialisation modules). If
> ``__package__`` has already been set then the import system will use
> it in preference to recalculating the package name from the
> ``__name__`` and ``__path__`` attributes.
>
> The ``runpy`` module will explicitly set the new attribute, basing it off
> the name used to locate the module to be executed rather than the name
> used to set the module's ``__name__`` attribute. This will allow relative
> imports to work correctly from main modules executed with the ``-m``
> switch.
>
> When the main module is specified by its filename, then the
> ``__package__`` attribute will be set to ``None``. To allow
> relative imports when the module is executed directly, boilerplate
> similar to the following would be needed before the first relative
> import statement::
>
>if __name__ == "__main__" and __package__ is None:
>__package__ = "expected.package.name"
>
> Note that this boilerplate is sufficient only if the top level package
> is already accessible via ``sys.path``. Additional code that manipulates
> ``sys.path`` would be needed in order for direct execution to work
> without the top level package already being importable.
>
> This approach also has the same disadvantage as the use of absolute
> imports of sibling modules - if the script is moved to a different
> package or subpackage, the boilerplate will need to be updated
> manually. It has the advantage that this change need only be made
> once per file, regardless of the number of relative imports.
>
>
> Rationale for Change
>
>
> The current inability to use explicit relative imports from the main
> module is the subject of at least one open SF bug report (#1510172) [1]_,
> and has most likely been a factor in at least a few queries on
> comp.lang.python (such as Alan Isaac's question in [2]_).
>
> This PEP is intended to provide a solution which permits explicit
> relative imports from main modules, without incurring any significant
> costs during interpreter startup
[Python-Dev] msvcr90 support was added to mingw
Paul Moore got some Cygwin developers persuaded to implement support for msvcr90 [1]. The coded was added a few days ago [2]. This means that users are still able to use MinGW to compile extensions when we switch to VS 2008 as default compiler on Windows. I'm not sure how many people are interested in the topic but some may be glad to hear that MinGW is still supported. Christian [1] http://article.gmane.org/gmane.comp.gnu.mingw.user/24686 [2] http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/msvcrt.def.in?rev=1.8&content-type=text/x-cvsweb-markup&cvsroot=src ___ 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] Decimal news: speedup and stabilization
2007/11/24, Nick Coghlan <[EMAIL PROTECTED]>: > Did you change the Decimal repr to use the same format for the mantissa? I don't understand the question. The output of repr() does not show this internals... > Could you also check the performance gain against the telco benchmark > which is in the sandbox? [1] I tested different versions of Decimal with this telco.py. With Python from the trunk (r58550), which is the last decimal.py version previous to this change: 1241.8 After changed it to keep _int as string: 869.3 (30% faster!) But still there're a lot of room for improvements. I just commited other patch from Mark, where he reordered __new__, to minimize isinstance() checks for the most used types.} After new reordering patch: 672.9 (22% faster!) :) Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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 Tracker Issues
ACTIVITY SUMMARY (11/23/07 - 11/30/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1323 open (+24) / 11687 closed (+11) / 13010 total (+35) Open issues with patches: 418 Average duration of open issues: 699 days. Median duration of open issues: 844 days. Open Issues Breakdown open 1315 (+23) pending 8 ( +1) Issues Created Or Reopened (36) ___ Warning required when calling register() on an ABCMeta subclass 11/30/07 CLOSED http://bugs.python.org/issue1109reopened gvanrossum py3k, patch Patch to remove unbound methods 11/24/07 CLOSED http://bugs.python.org/issue1493created tiran py3k, patch DOM-Documentation should mention that appendChild() removes the 11/24/07 CLOSED http://bugs.python.org/issue1494created dennda Unicode in a comment.11/24/07 CLOSED http://bugs.python.org/issue1495created wiscados add str.maketrans() 11/25/07 CLOSED http://bugs.python.org/issue1496created georg.brandl py3k, patch Patch to remove API to create new unbound methods11/25/07 http://bugs.python.org/issue1497created tiran py3k, patch Rename __builtins__ to __root_namespace__? 11/26/07 http://bugs.python.org/issue1498created gvanrossum py3k failure behaviour of compile() is missing11/26/07 http://bugs.python.org/issue1499created AchimGaedke Example using range doesn't give claimed results 11/26/07 CLOSED http://bugs.python.org/issue1500created basingwerk 0 ** 0 documentation 11/26/07 http://bugs.python.org/issue1501created jimjjewett itertools should grow chunkify 11/26/07 CLOSED http://bugs.python.org/issue1502created arkanes test_xmlrpc is still flakey 11/27/07 http://bugs.python.org/issue1503created gvanrossum Add 2to3 fixer for (un)bound methods 11/27/07 http://bugs.python.org/issue1504reopened tiran py3k Changes to PyMethod_New breaks ctypes on Windows 11/27/07 CLOSED http://bugs.python.org/issue1505created tiran py3k func alloca inside ctypes lib needs #include on solar 11/27/07 http://bugs.python.org/issue1506created mthibaut complex constructor loses signs of zeros 11/27/07 http://bugs.python.org/issue1507created marketdickinson Removal of stale code in _csv.c / pyexpat.c 11/27/07 CLOSED http://bugs.python.org/issue1508created JosephArmbruster py3k Documentation lacking for the sqlite3 module.11/28/07 http://bugs.python.org/issue1509created pmawhorter help for file/open should state which is prefered. 11/28/07 http://bugs.python.org/issue1510created carlfk csv input converts \r\n to \n but csv output does not when a fie 11/28/07 ht
Re: [Python-Dev] [poll] New name for __builtins__
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | I think the situation with __main__ is different from __builtin__, I effectively agreed by not disputing Guido's response ;-) ___ 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] [poll] New name for __builtins__
Oleg Broytmann <[EMAIL PROTECTED]> writes: > On Fri, Nov 30, 2007 at 11:22:03AM +1300, Greg Ewing wrote: >> The next step up from global would be __galactic__. > >Let me skip __universe[al]__ and go directly to The Ultimate >Questions: So maybe it should be called __42__? Bernhard ___ 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] PATCH: Fast globals/builtins lookups for 2.6
Neil Toronto wrote: > Guido van Rossum wrote: >> Hm. >> >> On my Linux box, in the trunk: >> >> Before the patch: >> Pystone(1.1) time for 5 passes = 1.16 >> This machine benchmarks at 43103.4 pystones/second >> >> After the patch: >> Pystone(1.1) time for 5 passes = 1.14 >> This machine benchmarks at 43859.6 pystones/second >> >> That's only about 1.75% faster. But pystone is a lousy benchmark. > > I'm not aware of any benchmark that isn't. :) > > Can you humor me and change the PY_LONG_LONG to Py_ssize_t in both > PyDictObject and PyFastGlobalsObject and see if that helps? It does on > one of my test machines. > > Speaking of which, here's a question for everybody. I was wondering > whether 64 bits is necessary. It takes an hour of concerted effort - > nothing but "module.d = 1; del module.d" for an hour straight - to > overflow a 32-bit version number. Is anybody going to actually get close > to doing that in a global namespace? > Of course not. And 640k is as much memory as anyone could reasonably need ... > I don't think a malicious user could exploit it. The most they could do > is segfault by doing exactly 2**32 entry-invalidating operations and > then one get or set. They've got better things to do if they're running > code on your machine. > > FWIW - and I wouldn't bother with this if I weren't mucking about with > dict internals - with a 32-bit version number, I've verified that gcc > emits only one extra instruction in dict functions that increment it. > It's two for a 64-bit number. The version test in LOAD_GLOBAL does take > a bit more time with 64 bits, though. > That's a good local optimization for today's conditions, probably. Who nows whether it will survive the next ten years. And decisions like that have a weird habit of running into pathological cases whose authors curse you when they find out where the problem arose. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ 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] -O2 faster than -O3?
On both of my systems, using -O2 reduces execution time in pystone by 9% and in pybench by 8%. It's function inlining: "-O3 -fno-inline-functions" works just as well as "-O2". Removing "-g" has little effect on the result. Systems: - AMD Athlon 64 X2 Dual Core 4600+, 512 KB cache (desktop) - Intel T2300 Dual Core 1.66GHz, 512 KB cache (laptop) Both are Ubuntu 7.04, GCC 4.1.2. Does anybody else see this? It may be GCC being stupid (which has happened before) or not enough cache on my systems (definitely possible). If it's not one of those, I'd say it's because CPython core functions are already very large, and almost everything that ought to be inlined is already a macro. Pybench comparison for the Athlon: http://spreadsheets.google.com/ccc?key=pHIJrYc_pnIXCwJvDvU9gfQ&hl=en_US Neil ___ 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] [poll] New name for __builtins__
On Nov 30, 2007 4:40 PM, Oleg Broytmann <[EMAIL PROTECTED]> wrote: > On Fri, Nov 30, 2007 at 03:05:18PM -0800, Guido van Rossum wrote: > > On Nov 30, 2007 2:17 PM, Nicko van Someren <[EMAIL PROTECTED]> wrote: > > > +1 for __universal__ > > > > It's almost as if nobody has seen my proposal to leave __builtins__ > > alone and rename the __builtin__ module instead. > >I saw it, and I think it'd be the best. I'd like to jump on the __builtin__ -> builtin bandwagon too. ;-) Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] [poll] New name for __builtins__
At 06:16 PM 11/30/2007 -0500, Fred Drake wrote: >On Nov 30, 2007, at 6:05 PM, Guido van Rossum wrote: > > It's almost as if nobody has seen my proposal to leave __builtins__ > > alone and rename the __builtin__ module instead. > > >I suspect that's indistinguishable from everyone being tired of the >discussion, knowing that you're going to pick something reasonable in >spite of our yammering. > >+1 for a module named "builtin", or something similarly obscure. What he said - but "builtins", i.e. plural. ___ 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] -O2 faster than -O3?
Neal Norwitz wrote: > On Nov 30, 2007 7:16 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: >> On Nov 30, 2007 12:02 PM, Neil Toronto <[EMAIL PROTECTED]> wrote: >>> On both of my systems, using -O2 reduces execution time in pystone by 9% >>> and in pybench by 8%. It's function inlining: "-O3 >>> -fno-inline-functions" works just as well as "-O2". Removing "-g" has >>> little effect on the result. >>> >>> Systems: >>> - AMD Athlon 64 X2 Dual Core 4600+, 512 KB cache (desktop) >>> - Intel T2300 Dual Core 1.66GHz, 512 KB cache (laptop) >>> >>> Both are Ubuntu 7.04, GCC 4.1.2. >>> >>> Does anybody else see this? >>> >>> It may be GCC being stupid (which has happened before) or not enough >>> cache on my systems (definitely possible). If it's not one of those, I'd >>> say it's because CPython core functions are already very large, and >>> almost everything that ought to be inlined is already a macro. >>> >> That's quite possible. Previous benchmarks by AMK have shown that >> perhaps -0m (or whatever the flag is to optimize for size) sometimes >> is the best solution. It has always been believed that the eval loop >> is already large and manages to hit some cache sweet spot. > > The flag is -Os. I suspect you will do better to limit the size of > inlining rather disabling it completely. The option is > -finline-limit=number. I don't know the default value or what you > should try. I would be interested to hear more results though. I've got some pystones (50) results for the Athlon. The default for -finline-limit is 600. This is for the current trunk. Global optionspystones/sec (median of 3) -- -O3 50454.1 -O2 57273.8 -Os 52798.3 -O3 -fno-inline-functions54824.6 -O3 -finline-limit=300 51229.7 -O3 -finline-limit=150 51177.7 -O3 -finline-limit=7551759.8 -O3 -finline-limit=2553821.3 ceval.c options (-O3 for others) pystones/sec (median of 3) --- -O2 55066.1 -Os 57012.5 -O3 -fno-inline-functions55679.3 -O3 -finline-limit=300 51440.3 -O3 -finline-limit=150 50916.5 -O3 -finline-limit=7551387.5 -O3 -finline-limit=2552631.6 Now that's interesting. -O2 seems to be the best global option, and -Os seems to be best for ceval.c. One more test then: Global -O2, ceval.c -Os 56753.7 Weird. If you're going to run these benchmarks yourself, make sure you "make clean" before building with different options. (I don't know why it's necessary, but it is.) To change options for just ceval.c, add this to Makefile.pre.in under "Special rules": Python/ceval.o: $(srcdir)/Python/ceval.c $(CC) -c $(PY_CFLAGS) -Os \ -o $@ $(srcdir)/Python/ceval.c The last -O flag should override any other. Neil ___ 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] [poll] New name for __builtins__
Terry Reedy wrote: > "Greg Ewing" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > | I think the situation with __main__ is different from __builtin__, > > I effectively agreed by not disputing Guido's response ;-) Very cunning. But I was even more cunning, and didn't even *consider* disputing Guido's response. Neil ___ 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] -O2 faster than -O3?
Neil Toronto wrote: [...] > If you're going to run these benchmarks yourself, make sure you "make > clean" before building with different options. (I don't know why it's > necessary, but it is.) Because the dependencies evaluated by "make" don't take into account the different options that were used to compile existing object files. Without the "make clean" it says "aha, here's a nice up-to-date object file, I'll use that" and you don't get a freshly-compiled version. Touching the sources should also work, and is a little quicker. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ 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] [Fwd: Re: -O2 faster than -O3?]
[Sorry, the send key pressed itself there] Touching the sources should also work, and is a little quicker (but this is usually only practical for small projects). regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ 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
