document DJBX33A and discussion about non-aligned memory

This commit is contained in:
Christian Heimes 2013-11-14 00:20:03 +01:00
parent 4b767a63ee
commit 346215c231
1 changed files with 22 additions and 1 deletions

View File

@ -237,7 +237,10 @@ weakness in CityHash.
DJBX33A
-------
TODO
DJBX33A is a very simple multiplication and addition algorithm by Daniel
J. Bernstein. It is fast and has low setup costs but it's not secure against
hash collision attacks. Its properties make it a viable choice for small
string hashing optimization.
Other
@ -609,6 +612,22 @@ possibility to select a hash algorithm at startup. The approach was considered
an unnecessary complication by several core committers [pluggable]_. Subsequent
versions of the PEP aim for compile time configuration.
Non-aligned memory access
-------------------------
The implementation of SipHash24 were critized because it ignores the issue
of non-aligned memory and therefore doesn't work on architectures that
requires alignment of integer types. The PEP deliberately neglects this
special case and doesn't support SipHash24 on such platforms. It's simply
not considered worth the trouble until proven otherwise. All major platforms
like X86, X86_64 and ARMv6+ can handle unaligned memory with minimal or even
no speed impact. [alignmentmyth]_
Almost every block is properly aligned anyway. At present bytes' and str's
data are always aligned. Only memoryviews can point to unaligned blocks
under rare circumstances. The PEP implementation is optimized and simplified
for the common case.
References
==========
@ -649,6 +668,8 @@ References
.. [pluggable] https://mail.python.org/pipermail/python-dev/2013-October/129138.html
.. [alignmentmyth] http://lemire.me/blog/archives/2012/05/31/data-alignment-for-speed-myth-or-reality/
Copyright
=========