Re: [Python-Dev] cpython: hashtable.h now supports keys of any size

2016-03-23 Thread Serhiy Storchaka

On 21.03.16 23:01, victor.stinner wrote:

https://hg.python.org/cpython/rev/aca4e9af1ca6
changeset:   100640:aca4e9af1ca6
user:Victor Stinner 
date:Mon Mar 21 22:00:58 2016 +0100
summary:
   hashtable.h now supports keys of any size

Issue #26588: hashtable.h now supports keys of any size, not only
sizeof(void*). It allows to support key larger than sizeof(void*), but also to
use less memory for key smaller than sizeof(void*).


If key size is compile time constant, Py_MEMCPY() and memcpy() can be 
optimized in one machine instruction. If it is ht->key_size, it adds 
more overhead. These changes can have negative performance effect.


It can be eliminated if pass a compile time constant to 
_Py_HASHTABLE_ENTRY_READ_KEY() etc.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] cpython: hashtable.h now supports keys of any size

2016-03-23 Thread Serhiy Storchaka

On 23.03.16 19:37, Serhiy Storchaka wrote:

On 21.03.16 23:01, victor.stinner wrote:

https://hg.python.org/cpython/rev/aca4e9af1ca6
changeset:   100640:aca4e9af1ca6
user:Victor Stinner 
date:Mon Mar 21 22:00:58 2016 +0100
summary:
   hashtable.h now supports keys of any size

Issue #26588: hashtable.h now supports keys of any size, not only
sizeof(void*). It allows to support key larger than sizeof(void*), but
also to
use less memory for key smaller than sizeof(void*).


If key size is compile time constant, Py_MEMCPY() and memcpy() can be
optimized in one machine instruction. If it is ht->key_size, it adds
more overhead. These changes can have negative performance effect.

It can be eliminated if pass a compile time constant to
_Py_HASHTABLE_ENTRY_READ_KEY() etc.



Please ignore this message. It was sent to Python-Dev by mistake.

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] [Python-ideas] Add citation() to site.py

2016-03-23 Thread Jim J. Jewett


On Sun Mar 20 16:26:03 EDT 2016, Nikolaus Rath wrote:

> Which I believe makes it completely pointless to cite Python at all. As
> far as I can see, nowadays citations are given for two reasons:

> 1. To give the reader a starting point to get more information on a
>topic.

I don't often see references to good "starting points", but I'll grant
the "get more information".

> 2. To formally acknowledge the work done by someone else (who ends up
>with an increased number of citations for the cited publication,
>which is unfortunately a crucial metric in most academic hiring and
>evaluation processes).

There is a third category, of reader service.  

When I as a reader have wanted to follow a citation, it was because I
wanted to know more about the specific claim it supposedly supported.
In a few cases -- and these were probably the cases most valuable to
the authors -- I wanted to build on the work, or test it out under
new conditions.  Ideally, my first step was to replicate the original
result, to ensure that anything new I found was really caused by the
intentional changes.  If I was looking at a computational model, I
really didn't even have the excuse of "too expensive to run that
many subjects."

For papers more than a few years old, even if the code was available,
it generally didn't run -- and often didn't even compile.  Were there
a few missing utility files, or had they been using a language variant
different from what had eventually become the standard?

Obviously, it would have been better to just get a copy of the
original environment, PDP and all.  In real life, it was very
helpful to know which version of which compiler the authors had
been using.  Even the authors who had managed to save their code
didn't generally remember that level of detail about the original
environment.

Python today has much better backwards compatibility, but ...
if some junior grad student (maybe not in CS) today came across code
raising strings instead of Exceptions, how confident would she be that
she had the real code, as opposed to a mangled transcription?  Would it
help if the paper had a citation that specified CPython 2.1 and she
could still download a version of that ... where it worked?

-jJ

--

If there are still threading problems with my replies, please
email me with details, so that I can try to resolve them.  -jJ
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com