[PATCH] 3db6cbfc - SIPHASH is very slow on 32 bit x86 #12638
Comments
From @bulk88Created by @bulk88summary: SIPHASH on 32 bit processors without native CPU 64 bit integers The discussion in http://www.nntp.perl.org/group/perl.perl5.porters/2012/12/msg196172.html Perl Info |
From @demerphqMy current branch checks if HAS_QUAD is defined. Yves |
|
The RT System itself - Status changed from 'new' to 'open' |
From @bulk88On Tue Dec 11 18:19:54 2012, bulk88 wrote:
See attached patch. I tried it on VC 2003 32 bit Win32 Perl, no Quads, -- |
From @bulk880001-don-t-use-SIPHASH-on-x86-32-and-non-native-int-64-pl.patchFrom 22fb3e894dc7ba2f922861c955e0d5239fb4cf5a Mon Sep 17 00:00:00 2001
From: Daniel Dragan <bulk88@hotmail.com>
Date: Sun, 23 Dec 2012 03:03:12 -0500
Subject: [PATCH] don't use SIPHASH on x86-32 and non-native int 64 platforms
SIPHASH performance 7x slower than ONE_AT_A_TIME on i386 in my testing. On
AMD64 its 2x slower. This commit is related to commit 3db6cbfca3
and fixes Perl RT #116054. Details on speed claims are in
http://www.nntp.perl.org/group/perl.perl5.porters/2012/12/msg196172.html .
Any compiler can emulate any integer. Since the x86-32/i386 instruction
set has no 64 bit instructions, all compilers will emulate 64 bit integers
using multiple 32 bit instructions, and possibly calls to a static linked
math library. This severely degrades performance of the hashing function.
On a 32 bit Perl with Quads on i386, the slower SIPHASH was used
previously. Now, 32 bit Perl with Quads on i386 will use the faster native
ONE_AT_A_TIME instead of SIPHASH. Other CPUs and macros should be added
in the future to the list, but it should not be done without looking at the
assembly output of compilers and knowledge of the typical compiler flags
for that platform, and knowledge of the instruction set for that platform.
Obviously any CPU with 64 bit pointers has 64 bit operand instructions. If
a CPU or platform has emulated 64 bit pointers that will be delt with
when such a bug ticket comes. 32 bit CPUs that I dont know the details
of were put in the comments.
---
hv.h | 15 ++++++++++++++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/hv.h b/hv.h
index 3ee2399..ac395f7 100644
--- a/hv.h
+++ b/hv.h
@@ -156,7 +156,20 @@ struct xpvhv {
|| defined(PERL_HASH_FUNC_ONE_AT_A_TIME_OLD) \
|| defined(PERL_HASH_FUNC_BUZZHASH16) \
)
-#ifdef U64
+/* Porting note, add CPUs and macros which indicate native 64 bit ints,
+ or no native 64 bit ints. This is to not use SIPHASH on platforms with
+ compiler emulated 64 bit ints, ONE_AT_A_TIME works well with 32 bit CPUs.
+ See http://www.nntp.perl.org/group/perl.perl5.porters/2012/12/msg196172.html
+ for discussion on speed of these hash functions.
+
+ sparc, powerpc, alpha, mips and arm with 32 bit pointers are missing from
+ this list, 32 bit x86 with AVX might one day have native 64 bit ints
+*/
+#if defined(U64) && \
+ (PTRSIZE == 8 \
+ || defined(__ILP32__) \
+ || ( !defined(i386) && !defined(__i386) && !defined(__i386__) \
+ && !defined(_M_IX86) && !defined(__X86__) && !defined(_X86_)))
#define PERL_HASH_FUNC_SIPHASH
#else
#define PERL_HASH_FUNC_ONE_AT_A_TIME
--
1.7.9.msysgit.0
|
From @tonycozOn Sun Dec 23 00:09:52 2012, bulk88 wrote:
Perl no longer uses SIPHASH by default, even for 64-bit builds, so this I discussed this briefly in #p5p, and bulk88 would like the ticket kept Tony |
From @bulk88On Thu Jul 25 18:39:34 2013, tonyc wrote:
Since this ticket is about which is the best/fastest hash algo for perl, -- |
From @tonycozOn Sat Oct 19 13:18:45 2013, bulk88 wrote:
#120208 was fixed in 54e07e2. DJB2 probably isn't suitable as a default algorithm, since the 32-bit space Tony |
|
Given this ticket subject is not "What's the best hashing algorithm" and this discussion has died, I'm closing this case. If we want to discuss that in github issues, I suggest a new case. |
Migrated from rt.perl.org#116054 (status was 'open')
Searchable as RT116054$
The text was updated successfully, but these errors were encountered: