Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752843AbcD2DQF (ORCPT ); Thu, 28 Apr 2016 23:16:05 -0400 Received: from mail-ig0-f194.google.com ([209.85.213.194]:33955 "EHLO mail-ig0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752368AbcD2DQE (ORCPT ); Thu, 28 Apr 2016 23:16:04 -0400 MIME-Version: 1.0 In-Reply-To: <20160429025751.8368.qmail@ns.horizon.com> References: <20160429025751.8368.qmail@ns.horizon.com> Date: Thu, 28 Apr 2016 20:16:02 -0700 X-Google-Sender-Auth: J1Yep_5zf8uUdpsL_eFcZbZrs1c Message-ID: Subject: Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism From: Linus Torvalds To: George Spelvin Cc: Thomas Gleixner , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1344 Lines: 32 On Thu, Apr 28, 2016 at 7:57 PM, George Spelvin wrote: > > How many 32-bit platforms nead a multiplier that's easy for GCC to > evaluate via shifts and adds? > > Generlly, by the time you've got a machine grunty enough to > need 64 bits, a multiplier is quite affordable. Probably true. That said, the whole "use a multiply to do bit shifts and adds" may be a false economy too. It's a good trick, but it does limit the end result in many ways: you are limited to (a) only left-shifts and (b) only addition and subtraction. The "only left-shifts" means that you will always be in the situation that you'll then need to use the high bits (so you'll always need that shift down). And being limited to just the adder tends to mean that it's harder to get a nice spread of bits - you're basically always going to have that same carry chain. Having looked around at other hashes, I suspect we should look at the ones that do five or six shifts, and a mix of add/sub and xor. And because they shift the bits around more freely you don't have the final shift (that ends up being dependent on the size of the target set). It really would be lovely to hear that we can just replace hash_int/long() with a better hash. And I wouldn't get too hung up on the multiplication trick. I suspect it's not worth it. Linus