Re: [Python-Dev] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod
24.06.13 03:16, Raymond Hettinger написав(ла): I truly wasn't expecting the Spanish Inquisition :-) I only asked about the reasons. Previous reasons seemed reasonable to me and I wanted to know why a new code is better than the old. It will help me to use the best style in other places. Thank you for your clarification. ___ 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] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod
Hi Raymond,
Thank you for your long explanation, it is exactly what Antoine asked
for :-) I like micro-optimization even if I know that some other
developers only see such work as noise, not providing an real speed up
:-) So it was interesting to read your email!
I'm sorry that you was injured by the revert of your commits (even I
didn't do the revert myself, I agreed with Benjamin, and he's the
maintainer of Python 2.7). I hope that you understood why they were
rejected after reading this mail thread: the last Python 2.7 release
(which one exactly?) contains regressions, and changes on the 2.7
stable branch are sensitive. By experience, there is always someone in
the world relying to very specific implementation details. Cython,
PyPy CPyExt, ctypes, etc. are sensitive to such change. People should
not rely on such implementation details, but they do :-)
For this specific case, I "hope" that nobody relies on the exact BLOCK
structure (since it is a private structure). But it is just safer to
not change it that in a minor Python version. If your compare the risk
of introducing a regression versus the speedup, I guess that the risk
is higher.
As I wrote, I'm interested in micro-optimization, so please continue
your work! It is just safer to only modify the active development
branch (Python 3.4).
Victor
2013/6/24 Raymond Hettinger :
>
> On Jun 18, 2013, at 12:00 AM, Gregory P. Smith wrote:
>
> Why did you do this in the 2.7 branch?
>
> It hasn't been done in 3.3 or default
>
>
> I worked on the 2.7 branch first because that was the one I had loaded
> and the one where I did timings and code disassembly. I intended to
> post it to 3.3 and 3.4 as well over the weekend.
>
> Ideally, it makes maintenance simpler for me if I keep the branches
> the same as possible. I viewed the one-line struct transposition,
> comment correction, and one-line blocklen change as being somewhat
> innocuous non-algorithmic changes. The struct change fixed an unintended
> cache miss for left links and the blocksize change causes the
> deque_index code to compile more efficiently (using a right-shift
> and bitwise-and and rather than a measurably more expensive
> division and modulo calculation).
>
> I truly wasn't expecting the Spanish Inquisition :-)
>
>
> On Jun 22, 2013, at 1:43 PM, Scott Dial
> wrote:
>
> changeset 84248:f1dc30a1be72 2.7
> Arrange structure to match the common access patterns.
>
> 1.1 --- a/Modules/_collectionsmodule.c
> 1.2 +++ b/Modules/_collectionsmodule.c
> 1.3 @@ -48,8 +48,8 @@
> 1.4
> 1.5 typedef struct BLOCK {
> 1.6 struct BLOCK *leftlink;
> 1.7 +PyObject *data[BLOCKLEN];
> 1.8 struct BLOCK *rightlink;
> 1.9 -PyObject *data[BLOCKLEN];
>1.10 } block;
>1.11
>1.12 #define MAXFREEBLOCKS 10
>
> , which seems like a strange micro-optimization, at best.
>
>
> Yes, this is a micro-optimization. In working on implementing
> deque slicing for 3.4, I restudied the block access patterns.
> On an appendleft(), popleft() or extendleft() operation, the left link is
> accessed immediately before or after the leftmost entry in the data block.
> The old struct arrangement can cause an unnecessary cache miss
> when jumping leftward. This was something I overlooked when I
> originally wrote the code almost a decade ago.
>
> On Jun 23, 2013, at 11:38 AM, Benjamin Peterson wrote:
>
> I've backed this one out, too.
>
>
> Really, you reverted my one-line change within 24 hours of it being posted?
> I can't be on-line every day and sometimes it takes a little while to catch
> up
> with python email.
>
> On Jun 22, 2013, at 2:55 PM, Guido van Rossum wrote:
>
> Actually the data buffer is an array of pointers too, so with the
> original BLOCKLEN value of 62, sizeof(block) would be 64 times
> sizeof(PyObject *). In the Py3 version of the source there's even a
> comment explaining this right before the #define BLOCKLEN. Raymond,
> can you explain?
>
>
> I also tried to fix that comment so it would stop emphasizing the blocklen
> being a multiple of the cache line. Also long as there is a reasonably
> long
> data block, it matters less whether the data block size is an exact multiple
> of the cache line length (62 or 64 words of data versus a typical 8 byte
> cache line).
>
> The data block size does matter elsewhere though.
> The benefit of the having the data block being a power-of-two
> is that the deque_index computation can use bits shifts
> rather division and modulo calculations. The benefit
> of switching data block size from 62 to 64 was measurable
> (a few percent) and observable in the disassembly of the code.
>
> I experimented with one other ordering as well
> (putting the data block first and the links afterwards).
> That saved the scaled-index byte in the generated code
> but produced no measureable speed-up.
>
> In short, I believe the following should go in:
>
> * The comment fix. (Incorrectly suggesting that a 64-bit
>Py_ssize_
Re: [Python-Dev] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod
2013/6/24 Raymond Hettinger : > Lastly, there was a change I just put in to Py 3.4 replacing > the memcpy() with a simple loop and replacing the > "deque->" references with local variables. Besides > giving a small speed-up, it made the code more clear > and less at the mercy of various implementations > of memcpy(). > > Ideally, I would like 2.7 and 3.3 to replace their use of > memcpy() as well, but the flavor of this thread suggests > that is right out. The specific memcpy() function is usually highly optimized with assembler code for each architecture. The GNU libc now does better: it can choose the fastest version depending on the CPU version (MMX, SSE, etc.) at runtime. If I understood correctly, the glibc contains different version of memcpy, and the dynamic linker (ld.so) chooses the version depending on the CPU. GCC is also able to inline memcpy() when the size is known at compile time. I also saw two code paths when the size is only known at runtime: inline version for small size, and function call for larger copy. Python has a Py_MEMCPY which implements exactly that, but only for Visual Studio. I suppose that Visual Studio does not implement this optimization. By the way, Py_MEMCPY() is only used in few places. So it's surprising to read that a dummy loop is faster than memcpy()... even if I already see this in my own micro-benchmarks :-) Do you have an idea on how we can decide between the dummy loop and memcpy()? Using a benchmark? Or can it be decided just by reading the C code? What is the policy for using Py_MEMCPY() vs memcpy()? Victor ___ 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] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod
2013/6/24 Raymond Hettinger : > Changing the BLOCKLEN from 62 to 64 is debatable. > It measureably improved deque_index without an > observable negative effect on the other operations. Out of curiosity, do you know (remember) how was the number 62 chosen? Is it a compromise between memory usage and performances? 62 is surprising because it is not a power of two :-) Is it to just have 64 (2+62) pointers in the structure? (64 is a power of 2) Does it help the memory allocator (reduce memory fragmentation) to have a structure of 256 bytes (32-bit pointer) or 512 bytes (64-bit pointer), which are power of 2, instead of 264 or 528 bytes? It would be interesting to test pymalloc memory allocator on deque: I plan to test Python globally with PyMem_Malloc using pymalloc. pymalloc has a threshold of 512 bytes (and 528 bytes is greater than 512!). I suppose that the memory allocator is (much) more expensive than integer divisions. Would it be possible to change dynamically BLOCKLEN depending on the total size of the deque? Python dict does something like that, but for other reasons (reduce the number of hash collisions). According to your comment, "Larger numbers reduce the number of calls to the memory allocator, give faster indexing and rotation, and reduce the link::data overhead ratio." With dynamic BLOCKLEN, it would also be possible to reduce the memory usage for small deque (less than 62 items). Victor ___ 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-checkins] cpython (2.7): Issue #18277: Document quirks of multiprocessing queue.
On Mon, Jun 24, 2013 at 03:53:27PM +0200, richard.oudkerk wrote: > http://hg.python.org/cpython/rev/8dcc4e017d42 > + but should not cause any pratical difficulties -- you can always ^^ practical > + infinitessimal delay before the queue's :meth:`~Queue.empty` ^^ infinitesimal (or just "short") --amk ___ 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] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod
On Sun, 23 Jun 2013 20:37:37 -0700 Raymond Hettinger wrote: > But it isn't worth all the second guessing (and what feels like sniping). > I've worked on this code for almost a decade. As far as I can tell, none > of the participants in this thread has ever previously shown any interest > in the deque object. How do you measure "showing any interest"? I certainly use deques regularly (thank you for implementing them) and I'm sure others do too. I'm also interested in how the type is implemented and what the tradeoffs are there. Otherwise I wouldn't have noticed your commit. (if you remember, I was also interested enough to propose grafting deque-like functionality on OrderedDict: http://bugs.python.org/issue17100) 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] [Python-checkins] cpython (2.7): Issue #18277: Document quirks of multiprocessing queue.
On 24/06/2013 7:30pm, A.M. Kuchling wrote: On Mon, Jun 24, 2013 at 03:53:27PM +0200, richard.oudkerk wrote: http://hg.python.org/cpython/rev/8dcc4e017d42 + but should not cause any pratical difficulties -- you can always ^^ practical + infinitessimal delay before the queue's :meth:`~Queue.empty` ^^ infinitesimal (or just "short") --amk Thanks. The first has already been pointed out. -- Richard ___ 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-checkins] cpython (3.3): Add -b and -X options to python man page.
On Sun, Jun 23, 2013 at 6:14 PM, R. David Murray wrote: > On Sun, 23 Jun 2013 17:40:13 +0200, Maciej Fijalkowski > wrote: >> On Thu, Jun 20, 2013 at 3:36 PM, Brett Cannon wrote: >> > On Wed, Jun 19, 2013 at 11:20 PM, senthil.kumaran >> > wrote: >> >> .TP >> >> +.BI "\-X " option >> >> +Set implementation specific option. >> > >> > >> > Should probably be "Set the implementation-specific option." >> >> Is there anyone respecting this notation? (I know pypy does not, it >> uses --jit and stuff) > > CPython does. We introduced it for ourselves, it is up to other > implementations whether or not to use it, or use something else. > > --David you mean "CPython does not have any implementation-specific options"? I would claim -O behavior should be implementation-specific since it's nonsense in the optimizations sense, but other than that, it does not seem that there is any -X options? ___ 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-checkins] cpython (3.3): Add -b and -X options to python man page.
3.3 adds some -X options around faulthandler if I recall correctly. Alex On Mon, Jun 24, 2013 at 1:14 PM, Maciej Fijalkowski wrote: > On Sun, Jun 23, 2013 at 6:14 PM, R. David Murray > wrote: > > On Sun, 23 Jun 2013 17:40:13 +0200, Maciej Fijalkowski > wrote: > >> On Thu, Jun 20, 2013 at 3:36 PM, Brett Cannon wrote: > >> > On Wed, Jun 19, 2013 at 11:20 PM, senthil.kumaran > >> > wrote: > >> >> .TP > >> >> +.BI "\-X " option > >> >> +Set implementation specific option. > >> > > >> > > >> > Should probably be "Set the implementation-specific option." > >> > >> Is there anyone respecting this notation? (I know pypy does not, it > >> uses --jit and stuff) > > > > CPython does. We introduced it for ourselves, it is up to other > > implementations whether or not to use it, or use something else. > > > > --David > > you mean "CPython does not have any implementation-specific options"? > I would claim -O behavior should be implementation-specific since it's > nonsense in the optimizations sense, but other than that, it does not > seem that there is any -X options? > ___ > Python-checkins mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-checkins > -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 ___ 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-checkins] cpython (3.3): Add -b and -X options to python man page.
On Mon, 24 Jun 2013 22:14:46 +0200, Maciej Fijalkowski wrote: > On Sun, Jun 23, 2013 at 6:14 PM, R. David Murray > wrote: > > On Sun, 23 Jun 2013 17:40:13 +0200, Maciej Fijalkowski > > wrote: > >> On Thu, Jun 20, 2013 at 3:36 PM, Brett Cannon wrote: > >> > On Wed, Jun 19, 2013 at 11:20 PM, senthil.kumaran > >> > wrote: > >> >> .TP > >> >> +.BI "\-X " option > >> >> +Set implementation specific option. > >> > > >> > > >> > Should probably be "Set the implementation-specific option." > >> > >> Is there anyone respecting this notation? (I know pypy does not, it > >> uses --jit and stuff) > > > > CPython does. We introduced it for ourselves, it is up to other > > implementations whether or not to use it, or use something else. > > > > --David > > you mean "CPython does not have any implementation-specific options"? > I would claim -O behavior should be implementation-specific since it's > nonsense in the optimizations sense, but other than that, it does not > seem that there is any -X options? There is one. -X faulthandler. I'm sure others would agree about -O, but that long predates -X. So, the idea is that -X *can* be used by other implementations for their own purposes, but there is certainly no requirement that they do so. Our promise is that anything CPython uses it for is something we don't expect other implementations to support. --David ___ 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-checkins] cpython (3.3): Add -b and -X options to python man page.
2013/6/24 Maciej Fijalkowski : > On Sun, Jun 23, 2013 at 6:14 PM, R. David Murray > wrote: >> On Sun, 23 Jun 2013 17:40:13 +0200, Maciej Fijalkowski >> wrote: >>> On Thu, Jun 20, 2013 at 3:36 PM, Brett Cannon wrote: >>> > On Wed, Jun 19, 2013 at 11:20 PM, senthil.kumaran >>> > wrote: >>> >> .TP >>> >> +.BI "\-X " option >>> >> +Set implementation specific option. >>> > >>> > >>> > Should probably be "Set the implementation-specific option." >>> >>> Is there anyone respecting this notation? (I know pypy does not, it >>> uses --jit and stuff) >> >> CPython does. We introduced it for ourselves, it is up to other >> implementations whether or not to use it, or use something else. >> >> --David > > you mean "CPython does not have any implementation-specific options"? > I would claim -O behavior should be implementation-specific since it's > nonsense in the optimizations sense, but other than that, it does not > seem that there is any -X options? I wouldn't object to making that -Xno-docstrings or such, but the ship sailed long ago on -O. -- Regards, Benjamin ___ 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-checkins] cpython (3.3): Add -b and -X options to python man page.
On Mon, Jun 24, 2013 at 4:43 PM, Benjamin Peterson wrote: > 2013/6/24 Maciej Fijalkowski : > > On Sun, Jun 23, 2013 at 6:14 PM, R. David Murray > wrote: > >> On Sun, 23 Jun 2013 17:40:13 +0200, Maciej Fijalkowski < > [email protected]> wrote: > >>> On Thu, Jun 20, 2013 at 3:36 PM, Brett Cannon > wrote: > >>> > On Wed, Jun 19, 2013 at 11:20 PM, senthil.kumaran > >>> > wrote: > >>> >> .TP > >>> >> +.BI "\-X " option > >>> >> +Set implementation specific option. > >>> > > >>> > > >>> > Should probably be "Set the implementation-specific option." > >>> > >>> Is there anyone respecting this notation? (I know pypy does not, it > >>> uses --jit and stuff) > >> > >> CPython does. We introduced it for ourselves, it is up to other > >> implementations whether or not to use it, or use something else. > >> > >> --David > > > > you mean "CPython does not have any implementation-specific options"? > > I would claim -O behavior should be implementation-specific since it's > > nonsense in the optimizations sense, but other than that, it does not > > seem that there is any -X options? > > I wouldn't object to making that -Xno-docstrings or such, but the ship > sailed long ago on -O. > Python 4 change! =) ___ 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-checkins] cpython: Issue #9566: Fix a compiler warning in tupleiter_setstate() on Windows x64
On Mon, Jun 24, 2013 at 3:33 PM, victor.stinner
wrote:
> http://hg.python.org/cpython/rev/6b4d279508a3
> changeset: 84325:6b4d279508a3
> user:Victor Stinner
> date:Mon Jun 24 23:31:48 2013 +0200
> summary:
> Issue #9566: Fix a compiler warning in tupleiter_setstate() on Windows x64
>
> files:
> Objects/tupleobject.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
>
> diff --git a/Objects/tupleobject.c b/Objects/tupleobject.c
> --- a/Objects/tupleobject.c
> +++ b/Objects/tupleobject.c
> @@ -997,7 +997,7 @@
> static PyObject *
> tupleiter_setstate(tupleiterobject *it, PyObject *state)
> {
> -long index = PyLong_AsLong(state);
> +Py_ssize_t index = PyLong_AsLong(state);
Actually, this will still lose data when state > MAX_INT (on Windows).
It should be changed to PyLong_AsSssize_t(state) to ensure consistent
behavior on all platforms.
--
Jeremy Kloth
___
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-checkins] cpython: Issue #9566: Fix a compiler warning in tupleiter_setstate() on Windows x64
Ah yes correct, it should be better with the following commit:
http://hg.python.org/cpython/rev/3a393fc86b29
Victor
2013/6/24 Jeremy Kloth :
> On Mon, Jun 24, 2013 at 3:33 PM, victor.stinner
> wrote:
>> http://hg.python.org/cpython/rev/6b4d279508a3
>> changeset: 84325:6b4d279508a3
>> user:Victor Stinner
>> date:Mon Jun 24 23:31:48 2013 +0200
>> summary:
>> Issue #9566: Fix a compiler warning in tupleiter_setstate() on Windows x64
>> ...
>> static PyObject *
>> tupleiter_setstate(tupleiterobject *it, PyObject *state)
>> {
>> -long index = PyLong_AsLong(state);
>> +Py_ssize_t index = PyLong_AsLong(state);
>
> Actually, this will still lose data when state > MAX_INT (on Windows).
> It should be changed to PyLong_AsSssize_t(state) to ensure consistent
> behavior on all platforms.
___
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-checkins] cpython: Issue #9566: recv(), recvfrom(), send(), sendall() and sendto() methods
On Mon, Jun 24, 2013 at 3:48 PM, victor.stinner wrote: > +#if defined(MS_WIN64) || defined(MS_WINDOWS) This test could be reduced to simply `#ifdef MS_WINDOWS`. See PC\pyconfig.h ___ 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-checkins] cpython (3.3): Add -b and -X options to python man page.
2013/6/24 R. David Murray : > There is one. -X faulthandler. I'm sure others would agree about > -O, but that long predates -X. FYI I didn't chose "-X" because it is specific to CPython, but just because it becomes really hard to choose a random letter to add a new option... I prefer long options, but Python only supports the long option --help. IMO "python -X faulthandler" is more explicit than "python -@" (or "python -f", or any other random letter). If you didn't know, you can also write "python -X faulthandler=1", it does also enable faulthandler... As "python -X faulthandler=0" and "python -X faulthandler=False" :-) (PHP style!) > So, the idea is that -X *can* be used by other implementations for their > own purposes, but there is certainly no requirement that they do so. > Our promise is that anything CPython uses it for is something we don't > expect other implementations to support. It would be nice to have faulthandler or something similar (dump traces on a crash) in other Python implementations :-) faulthandler implementation is very specific to CPython. It uses internal structures and low-level OS features like signal handler and a specific stack for its signal handler. It is better to have it integrated directly into CPython. (But it is also available as a third party module for older versions.) Victor ___ 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-checkins] cpython: Issue #9566: recv(), recvfrom(), send(), sendall() and sendto() methods
Oh, I didn't know that."if defined(MS_WIN64) || defined(MS_WINDOWS)" is a common pattern in the Python source code. I simplified the #ifdef in many places: http://hg.python.org/cpython/rev/dfc020b4b123 I also read that MS_WIN32 is always defined on Windows. "#ifdef MS_WIN32" (used in many files, especially in ctypes) can probably be replaced with "#ifdef MS_WINDOWS" for consistency. MS_WIN32 should only be used to check if the API is Win64: /* MSVC defines _WINxx to differentiate the windows platform types Note that for compatibility reasons _WIN32 is defined on Win32 *and* on Win64. For the same reasons, in Python, MS_WIN32 is defined on Win32 *and* Win64. Win32 only code must therefore be guarded as follows: #if defined(MS_WIN32) && !defined(MS_WIN64) Some modules are disabled on Itanium processors, therefore we have MS_WINI64 set for those targets, otherwise MS_WINX64 */ Victor 2013/6/25 Jeremy Kloth : > On Mon, Jun 24, 2013 at 3:48 PM, victor.stinner > wrote: >> +#if defined(MS_WIN64) || defined(MS_WINDOWS) > > This test could be reduced to simply `#ifdef MS_WINDOWS`. See PC\pyconfig.h ___ 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-checkins] cpython (3.3): Add -b and -X options to python man page.
On Tue, Jun 25, 2013 at 12:28:09AM +0200, Victor Stinner wrote: > 2013/6/24 R. David Murray : > > There is one. -X faulthandler. I'm sure others would agree about > > -O, but that long predates -X. > > FYI I didn't chose "-X" because it is specific to CPython, but just > because it becomes really hard to choose a random letter to add a new > option... I prefer long options, but Python only supports the long > option --help. Is that a policy though? Couldn't Python support long options, or is it prohibited? -- Steven ___ 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-checkins] cpython (3.3): Add -b and -X options to python man page.
On 25 Jun 2013 09:03, "Steven D'Aprano" wrote: > > On Tue, Jun 25, 2013 at 12:28:09AM +0200, Victor Stinner wrote: > > 2013/6/24 R. David Murray : > > > There is one. -X faulthandler. I'm sure others would agree about > > > -O, but that long predates -X. > > > > FYI I didn't chose "-X" because it is specific to CPython, but just > > because it becomes really hard to choose a random letter to add a new > > option... I prefer long options, but Python only supports the long > > option --help. > > Is that a policy though? Couldn't Python support long options, or is it > prohibited? Just impractical. It will likely be more feasible to support them in a maintainable way once PEP 432 is done and we can lean on the C API more heavily while processing command line arguments. Cheers, Nick. > > > -- > Steven > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.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] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod
On Jun 24, 2013, at 4:07 AM, Victor Stinner wrote: > Out of curiosity, do you know (remember) how was the number 62 chosen? > Is it a compromise between memory usage and performances? 62 is > surprising because it is not a power of two :-) > > Is it to just have 64 (2+62) pointers in the structure? Yes, the goal was to have the struct size be an exact multiple of the cache line length (always a power-of-two, typically 64 bytes). What was different then is that deques weren't indexable. When indexing was added, the size of 62 became an unfavorable choice because it made the division and modulo calculation in deque_index() slower than for a power of two. > For this specific case, I "hope" that nobody relies on the exact BLOCK > structure (since it is a private structure). I don't know what you're talking about. This structure isn't externally visible. Raymond ___ 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] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod
On Mon, Jun 24, 2013 at 7:47 PM, Raymond Hettinger < [email protected]> wrote: > > > On Jun 24, 2013, at 4:07 AM, Victor Stinner > wrote: > > Out of curiosity, do you know (remember) how was the number 62 chosen? > Is it a compromise between memory usage and performances? 62 is > surprising because it is not a power of two :-) > > Is it to just have 64 (2+62) pointers in the structure? > > > Yes, the goal was to have the struct size be an exact multiple > of the cache line length (always a power-of-two, typically 64 bytes). > What was different then is that deques weren't indexable. > When indexing was added, the size of 62 became an > unfavorable choice because it made the division and modulo > calculation in deque_index() slower than for a power of two. > A-ha! Finally an explanation of the change. It makes intuitive sense now. I think the general feeling is that folks overreacted (perhaps confused by your silence) and that the reversal will be rolled back. Benjamin? -- --Guido van Rossum (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] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod
On Jun 24, 2013 9:11 PM, "Guido van Rossum" wrote: > > On Mon, Jun 24, 2013 at 7:47 PM, Raymond Hettinger < [email protected]> wrote: >> >> >> >> On Jun 24, 2013, at 4:07 AM, Victor Stinner wrote: >> >>> Out of curiosity, do you know (remember) how was the number 62 chosen? >>> Is it a compromise between memory usage and performances? 62 is >>> surprising because it is not a power of two :-) >>> >>> Is it to just have 64 (2+62) pointers in the structure? >> >> >> Yes, the goal was to have the struct size be an exact multiple >> of the cache line length (always a power-of-two, typically 64 bytes). >> What was different then is that deques weren't indexable. >> When indexing was added, the size of 62 became an >> unfavorable choice because it made the division and modulo >> calculation in deque_index() slower than for a power of two. > > > A-ha! Finally an explanation of the change. It makes intuitive sense now. I think the general feeling is that folks overreacted (perhaps confused by your silence) and that the reversal will be rolled back. Benjamin? Seems likely to me. > > -- > --Guido van Rossum (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/greg%40krypto.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] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod
2013/6/24 Guido van Rossum : > On Mon, Jun 24, 2013 at 7:47 PM, Raymond Hettinger > wrote: >> >> >> >> On Jun 24, 2013, at 4:07 AM, Victor Stinner >> wrote: >> >> Out of curiosity, do you know (remember) how was the number 62 chosen? >> Is it a compromise between memory usage and performances? 62 is >> surprising because it is not a power of two :-) >> >> Is it to just have 64 (2+62) pointers in the structure? >> >> >> Yes, the goal was to have the struct size be an exact multiple >> of the cache line length (always a power-of-two, typically 64 bytes). >> What was different then is that deques weren't indexable. >> When indexing was added, the size of 62 became an >> unfavorable choice because it made the division and modulo >> calculation in deque_index() slower than for a power of two. > > > A-ha! Finally an explanation of the change. It makes intuitive sense now. I > think the general feeling is that folks overreacted (perhaps confused by > your silence) and that the reversal will be rolled back. Benjamin? Raymond, go ahead and reapply your change. -- Regards, Benjamin ___ 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
