Bug 26424 - tr1/unordered vs 64-bit machines
Summary: tr1/unordered vs 64-bit machines
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 4.2.0
: P3 normal
Target Milestone: 4.1.1
Assignee: Paolo Carlini
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-22 16:56 UTC by Paolo Carlini
Modified: 2006-04-21 17:51 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-04-19 10:49:52


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paolo Carlini 2006-02-22 16:56:53 UTC
The number of buckets is currently limited to ~2^32 (see X<>::primes). This is a serious issue: for correctness, rehash(n) for n > 2^32 should throw and do nothing, in order not to violate the post-conditions in Table 21.

We have various options: as suggested by Howard off-line, we could well compute at run-time prime-numbers. Otherwise, mid-term, if we cannot extend the maximum number of bucket we have to add throws to the rehashing functions.
Comment 1 Falk Hueffner 2006-02-22 17:11:58 UTC
Just curious: is the assumption of prime-size buckets hardwired in the TR?
Otherwise, the obvious alternative would be to use power-of-two sizes, which
are much faster in access.
Comment 2 Paolo Carlini 2006-02-22 17:23:54 UTC
(In reply to comment #1)
> Just curious: is the assumption of prime-size buckets hardwired in the TR?
> Otherwise, the obvious alternative would be to use power-of-two sizes, which
> are much faster in access.

Yes. Really, I have yet to study the issue in detail (Knuth...), I'm going to do that. For sure TR1 doesn't mandate a specific policy, but we have got a default policy, prime_rehash_policy, which is definitely well known and used elsewhere, it would be nice to fix it, to begin with ;)
Comment 3 Paolo Carlini 2006-02-22 18:01:48 UTC
... something considered "obvious" in the literature is that the size policy goes together with the range-hashing function: e.g., an exponential size-policy would not work well together with our default modulo range-hashing function.
Comment 4 Paolo Carlini 2006-04-19 10:49:52 UTC
Working on it.
Comment 5 paolo@gcc.gnu.org 2006-04-19 22:58:29 UTC
Subject: Bug 26424

Author: paolo
Date: Wed Apr 19 22:58:23 2006
New Revision: 113100

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113100
Log:
2006-04-19  Paolo Carlini  <pcarlini@suse.de>

	PR libstdc++/26424
	* include/tr1/hashtable (X<>::primes): Extend for 64-bit machines.
	(X<>::n_primes): Adjust.
	(prime_rehash_policy::next_bkt, bkt_for_elements, need_rehash): Adjust.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/include/tr1/hashtable

Comment 6 paolo@gcc.gnu.org 2006-04-21 17:50:02 UTC
Subject: Bug 26424

Author: paolo
Date: Fri Apr 21 17:49:48 2006
New Revision: 113143

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113143
Log:
2006-04-21  Paolo Carlini  <pcarlini@suse.de>

	PR libstdc++/26424
	* include/tr1/hashtable (X<>::primes): Extend for 64-bit machines.
	(X<>::n_primes): Adjust.
	(prime_rehash_policy::next_bkt, bkt_for_elements, need_rehash): Adjust.

Modified:
    branches/gcc-4_1-branch/libstdc++-v3/ChangeLog
    branches/gcc-4_1-branch/libstdc++-v3/include/tr1/hashtable

Comment 7 Paolo Carlini 2006-04-21 17:51:57 UTC
Fixed for 4.1.1.