Re: [Python-Dev] stat module in C -- what to do with stat.py?

2013-06-22 Thread Armin Rigo 
Hi,

On Fri, Jun 21, 2013 at 9:20 PM, Steven D'Aprano  wrote:
 process. Personally, I don't see the value in it; other implementations
 will need to do *something* special to use it anyway.
>
> That's not correct. Other implementations can do exactly what CPython 3.3
> does, namely just use stat.py as given. Not all implementations necessarily
> care about multiple platforms where stat constants are likely to change.

Thanks Steven.  That's PyPy's position: for now we really care only
about  where stat.py has
been obviously sufficient, as shown by CPython's long experience with
stat.py.


A bientôt,

Armin.
___
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-06-22 Thread Benjamin Peterson 
Many people have raised concerns about this change, so I've now backed it out.

2013/6/18 Gregory P. Smith :
> Raymond -
>
> Why did you do this in the 2.7 branch?
>
> It hasn't been done in 3.3 or default and it isn't not the sort of change we
> make in a stable release branch without justification.  What issue was this
> for?  What problem were you solving?
>
> -gps
>
>
>
> On Mon, Jun 17, 2013 at 11:08 PM, Ethan Furman  wrote:
>>
>> On 06/17/2013 09:05 PM, Eli Bendersky wrote:
>>>
>>>
>>>
>>>
>>> On Fri, Jun 14, 2013 at 6:47 AM, Serhiy Storchaka >> > wrote:
>>>
>>> 14.06.13 11:46, Antoine Pitrou написав(ла):
>>>
>>> On Fri, 14 Jun 2013 07:06:49 +0200 (CEST)
>>> raymond.hettinger >> > wrote:
>>>
>>> http://hg.python.org/cpython/__rev/5accb0ac8bfb
>>> 
>>>
>>> changeset:   84116:5accb0ac8bfb
>>> Fix comment blocks.  Adjust blocksize to a power-of-two
>>> for better divmod computations.
>>>
>>>
>>> Is there any rationale for changing the heuristic from "fits in a
>>> whole
>>> number of cachelines" to "allows fast division by the blocksize"?
>>>
>>> I personally would prefer if such changes were justified a bit
>>> more
>>> than by a one-liner changeset message without any corresponding
>>> open
>>> issue.
>>>
>>>
>>> I share the doubts of Antoine and I was going to write the same
>>> comment. I thought there were good reasons for
>>> previous code. What has changed?
>>>
>>>
>>> I agree it would be interesting to hear about the reasons for the change.
>>> Raymond?
>>
>>
>> Asking as a learner:  are such non-bugfix changes appropriate for the 2.7
>> line?
>>
>> --
>> ~Ethan~
>>
>> ___
>> 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/benjamin%40python.org
>



-- 
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] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod

2013-06-22 Thread Scott Dial 
On 6/22/2013 2:17 PM, Benjamin Peterson wrote:
> Many people have raised concerns about this change, so I've now backed it out.

I think that change also goes with this change:

http://hg.python.org/cpython/rev/f1dc30a1be72

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.

Based on that structure, it would seem that neither BLOCKLEN being 62
(previous value) nor 64 (the new value) make much sense. It would seem
best that sizeof(block) == 64, so BLOCKLEN should be (64 -
2*sizeof(PyObject *)). Nevertheless, I am skeptical that any tuning of
this structure provides any meaningful performance improvement.

-- 
Scott Dial
[email protected]
___
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-06-22 Thread Guido van Rossum 
On Sat, Jun 22, 2013 at 1:43 PM, Scott Dial
 wrote:
> On 6/22/2013 2:17 PM, Benjamin Peterson wrote:
>> Many people have raised concerns about this change, so I've now backed it 
>> out.
>
> I think that change also goes with this change:
>
> http://hg.python.org/cpython/rev/f1dc30a1be72
>
> 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.
>
> Based on that structure, it would seem that neither BLOCKLEN being 62
> (previous value) nor 64 (the new value) make much sense. It would seem
> best that sizeof(block) == 64, so BLOCKLEN should be (64 -
> 2*sizeof(PyObject *)). Nevertheless, I am skeptical that any tuning of
> this structure provides any meaningful performance improvement.

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?

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