Return-Path: X-Original-To: apmail-apr-dev-archive@www.apache.org Delivered-To: apmail-apr-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4CC779B69 for ; Mon, 30 Jan 2012 01:08:54 +0000 (UTC) Received: (qmail 50753 invoked by uid 500); 30 Jan 2012 01:08:53 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 50629 invoked by uid 500); 30 Jan 2012 01:08:52 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 50620 invoked by uid 99); 30 Jan 2012 01:08:52 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Jan 2012 01:08:52 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [74.125.83.50] (HELO mail-ee0-f50.google.com) (74.125.83.50) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Jan 2012 01:08:43 +0000 Received: by eekb57 with SMTP id b57so1276817eek.37 for ; Sun, 29 Jan 2012 17:08:23 -0800 (PST) Received: by 10.14.33.218 with SMTP id q66mr2463361eea.67.1327885703013; Sun, 29 Jan 2012 17:08:23 -0800 (PST) Received: from zulu.local (cpe-46-164-12-254.dynamic.amis.net. [46.164.12.254]) by mx.google.com with ESMTPS id b49sm65771277eec.9.2012.01.29.17.08.21 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Jan 2012 17:08:21 -0800 (PST) Message-ID: <4F25ED83.80307@apache.org> Date: Mon, 30 Jan 2012 02:08:19 +0100 From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Bojan Smojver CC: dev@apr.apache.org Subject: Re: svn commit: r1237078 - /apr/apr/trunk/tables/apr_hash.c References: <20120128155422.BCF80238890B@eris.apache.org> <4F253CEB.5020002@apache.org> <4F2545DC.80708@apache.org> <1157242535.1012357368@rexursive.com> <1327851294.16813.0.camel@shrek.rexursive.com> <4F259CB0.1000204@apache.org> <1327876677.16813.1.camel@shrek.rexursive.com> <1327877987.16813.8.camel@shrek.rexursive.com> <1327878931.16813.11.camel@shrek.rexursive.com> In-Reply-To: <1327878931.16813.11.camel@shrek.rexursive.com> X-Enigmail-Version: 1.3.4 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAAXNSR0IArs4c6QAAADBQTFRF IhsbCy0qZjoVOVRoeFxSAIKBzXQiAKaibYiewnk7nn9z0qCTgL3i87Ep6Kx/+tHBsrE+zgAAAjZJ REFUOMvF0jFoE1EYB/CzjWlqIzaTjqVIBifRRWyG0t5iUqlLyFpCeXBgKg5yq6A4degUDJjoUDpc 1Qt4Ux94B11SOLB0KGS4discpbkORTCn9/m9d3fvLhXnvuHu3f+Xx/veyyfZfLSdZHzgicSfeyw4 JISwdz8FT6M8lM8Ceg385Dlhs+cC9sQCDn0B78QCogzwN+sxfHGOIXBbRGkNAM4cZymGtgNsDPgz cByxon3EEm1TLmvAlghoHOO3CZSa+IQ/vF6JV8tgKOMow78gRgL2/+EIvATOUtB3SSdMg4GXgrbn uk0uLiGdoCHKbX4E+t1FUTqn1AtIdPJebssDQ64YANSQyyaQNyUOFs0ijMsMFnOPTahPLXKYowtY 08MfCP7vR7hRnc5zmPK7CDYYbHcbC7tHuyFA94U/1LYZaJpu/sxACHMwvwZljTLY0TbNk4x+zuEt yC3MfCM6uSIvfwur0itFL4FA2Yal8BzLfnYV4EIGwEPAk7o5zIcnvzHMEjwJrrhAKK7on6IrsfRJ 7A53BhaK+CL7fj6+q/sPeOvcDTtoZTxpUYsFeIknrOXep3p3l7Ua+8sZ5FPQKyKwWi+DfROTU7ny C1/9UhpeY7K287WJCzbsNPQm2S6Yk4PSCNhWM2r3nD0K9liYb6yPgCRJhSzPrxUK0yUBVk1VX0lj s7MzGZyp0wImMK/e8rHbz2soL+O+2r1dxfGsAmBcx0lNjS/RUhlUC7gRn1wGMdQ7Vw1/AReW/RN3 xFWdAAAAAElFTkSuQmCC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On 30.01.2012 00:15, Bojan Smojver wrote: > On Mon, 2012-01-30 at 09:59 +1100, Bojan Smojver wrote: >> With my latest patch, I get that fixed (i.e. the final hash is >> perturbed a lot better). > Hmm, different problems emerge. The hash then has a tendency to produce > either all odd or even indexes (i.e. lower bits used to address > buckets). Just as I said -- the hash function we have is not meant to be perfect, or even secure, but to allow reasonable insertion and retrieval times. Running the same result through it again will not make any appreciabble difference. to the distribution. You'd have to make the second pass with a different hash function, or at least a different prime multiplier. I'm still not sure that'd be worth the extra cycles, however. I'm not even close to being an expert on hashing functions, but all multiply/modulo hashes apparently tend to behave similarly. -- Brane