From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82507 invoked by alias); 8 May 2015 22:11:00 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 82442 invoked by uid 89); 8 May 2015 22:10:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: mail-ig0-f175.google.com Received: from mail-ig0-f175.google.com (HELO mail-ig0-f175.google.com) (209.85.213.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 08 May 2015 22:10:55 +0000 Received: by igbsb11 with SMTP id sb11so33062251igb.0 for ; Fri, 08 May 2015 15:10:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Au4uWIYjNpvfmsrxY1eLTRCVNM+SvlTJ9sbTFXtrmlg=; b=Evo9wvL9XStFoX9Ju5t7xtpoU5X0tsfONXiV/54jyi40r5xNO7jmnuD2NEPTKpRi+n tQV4DU3bHf9b1SwXpcXaH+kLo9b9WChabQz7NW9YL2+cJhi3jbQ/YvSOzkiQIBJK+z38 fz1b2VLsRd/ov44d7MZXoVJXNNvvwYtvspbggnHB3PIwBnOw4EEjppcXd38y5gJEiDcT WEjuuXzz560290calxBg8efBCJP9gxxh33f5Z6hO3nyKOThzfbU3nIRBWWWMnCY/W+95 o/hfnaraGKOvIEJ4NXczgceadAOHNZyJ7/i/03dsdSb4pI/ZiQnDn+vqg38RCY6f9exG Hpkw== X-Gm-Message-State: ALoCoQliTKPm3HOuFtyB8hHY0ofCEaiAtlVDHlbA0GNaq8CE/q3cNRuolkyzBXuSKPRloOcrKcAC MIME-Version: 1.0 X-Received: by 10.107.128.149 with SMTP id k21mr208327ioi.7.1431123052806; Fri, 08 May 2015 15:10:52 -0700 (PDT) Received: by 10.79.68.194 with HTTP; Fri, 8 May 2015 15:10:52 -0700 (PDT) In-Reply-To: <554D1A05.9070601@gmail.com> References: <554A751E.9030009@gmail.com> <554D1A05.9070601@gmail.com> Date: Fri, 08 May 2015 22:11:00 -0000 Message-ID: Subject: Re: Enhance std::hash for pointers From: Christopher Jefferson To: =?UTF-8?Q?Fran=C3=A7ois_Dumont?= Cc: Richard Biener , "libstdc++@gcc.gnu.org" , gcc-patches Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2015-05/txt/msg00769.txt.bz2 My concern with accepting this patch is that many of libstdc++'s hash functions are awful from a mixing point of view -- you would get exactly the same problem from users who have integers which are always a multiple of a power of 2 (which is in practice not uncommon). This would give exactly the same problem. Rather than try to "fix" one hash function like this, we should just accept our hash functions might have low quality lower order bits. On 8 May 2015 at 21:18, Fran=C3=A7ois Dumont wrote: > On 08/05/2015 10:02, Richard Biener wrote: >> >> On Wed, May 6, 2015 at 10:10 PM, Fran=C3=A7ois Dumont >> wrote: >>> >>> Hi >>> >>> Following Marc Glisse comment #4 >>> on:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D65641 I would like to >>> propose this enhancement to the hash functor for pointers. It simply ge= ts >>> rid of the irrelevant bits on pointers hash code based on memory >>> alignment >>> of the pointed type. The only drawback I can think of is that the type >>> needs >>> to be complete at std::hash instantiation time but is it really an issue >>> ? >>> >>> IMO it is quite obvious that the resulting hash code will be better >>> but >> >> If you use a real hashing function that's not true. That is, something >> else than GCCs pointer_hash (void *p) { return (uintptr_t)p >>3; }. > > > Sorry, I don't understand your remark. Do you mean that if someone is not > using std::hash to hash its pointers he won't benefit from the enhancemen= t ? > > It is a good point however to see that gcc is using something similar > internally. > > Fran=C3=A7ois >