diff options
author | Justus Winter <4winter@informatik.uni-hamburg.de> | 2014-05-13 20:09:05 +0200 |
---|---|---|
committer | Justus Winter <4winter@informatik.uni-hamburg.de> | 2014-05-13 20:09:05 +0200 |
commit | 8ff7c917a8dbe541fb4bf797e21acc6d0edc7ceb (patch) | |
tree | baebeb11c8c44632601828f786b8eca1647e83ea /debian/patches/0004-libihash-use-fast-binary-scaling-to-determine-the-lo.patch | |
parent | 2ab6147feee29f561592bcf07bb54c6688eccef7 (diff) |
new huge patch series
Diffstat (limited to 'debian/patches/0004-libihash-use-fast-binary-scaling-to-determine-the-lo.patch')
-rw-r--r-- | debian/patches/0004-libihash-use-fast-binary-scaling-to-determine-the-lo.patch | 116 |
1 files changed, 116 insertions, 0 deletions
diff --git a/debian/patches/0004-libihash-use-fast-binary-scaling-to-determine-the-lo.patch b/debian/patches/0004-libihash-use-fast-binary-scaling-to-determine-the-lo.patch new file mode 100644 index 00000000..1a835a7f --- /dev/null +++ b/debian/patches/0004-libihash-use-fast-binary-scaling-to-determine-the-lo.patch @@ -0,0 +1,116 @@ +From 47ce159fbfca6e14f8ce442573c1fa10365113ff Mon Sep 17 00:00:00 2001 +From: Justus Winter <4winter@informatik.uni-hamburg.de> +Date: Tue, 13 May 2014 18:59:10 +0200 +Subject: [PATCH 04/15] libihash: use fast binary scaling to determine the load + +Expressing the maximum load in binary percent (where 128b% corresponds +to 100%) allows us to use fast binary scaling to determine if the +maximum load has been reached. + +* libihash/ihash.c (hurd_ihash_set_max_load): Update the comment. +(hurd_ihash_add): Use fast binary scaling to determine the current +load. +* libihash/ihash.h (hurd_ihash_set_max_load): Update the comment. +--- + libihash/ihash.c | 37 +++++++++++++++++++++++++++---------- + libihash/ihash.h | 22 ++++++++++++---------- + 2 files changed, 39 insertions(+), 20 deletions(-) + +diff --git a/libihash/ihash.c b/libihash/ihash.c +index d628d75..a4f92d1 100644 +--- a/libihash/ihash.c ++++ b/libihash/ihash.c +@@ -180,14 +180,15 @@ hurd_ihash_set_cleanup (hurd_ihash_t ht, hurd_ihash_cleanup_t cleanup, + } + + +-/* Set the maximum load factor in percent to MAX_LOAD, which should be +- between 1 and 100. The default is HURD_IHASH_MAX_LOAD_DEFAULT. +- New elements are only added to the hash table while the number of +- hashed elements is that much percent of the total size of the hash +- table. If more elements are added, the hash table is first +- expanded and reorganized. A MAX_LOAD of 100 will always fill the +- whole table before enlarging it, but note that this will increase +- the cost of operations significantly when the table is almost full. ++/* Set the maximum load factor in binary percent to MAX_LOAD, which ++ should be between 64 and 128. The default is ++ HURD_IHASH_MAX_LOAD_DEFAULT. New elements are only added to the ++ hash table while the number of hashed elements is that much percent ++ of the total size of the hash table. If more elements are added, ++ the hash table is first expanded and reorganized. A MAX_LOAD of ++ 128 will always fill the whole table before enlarging it, but note ++ that this will increase the cost of operations significantly when ++ the table is almost full. + + If the value is set to a smaller value than the current load + factor, the next reorganization will happen when a new item is +@@ -272,8 +273,24 @@ hurd_ihash_add (hurd_ihash_t ht, hurd_ihash_key_t key, hurd_ihash_value_t item) + + if (ht->size) + { +- /* Only fill the hash table up to its maximum load factor. */ +- if ((ht->nr_items * 100) >> __builtin_ctz (ht->size) <= ht->max_load) ++ /* Only fill the hash table up to its maximum load factor given ++ as "binary percent", where 128b% corresponds to 100%. As the ++ size is always a power of two, and 128 is also, the quotient ++ of both is also a power of two. Therefore, we can use bit ++ shifts to scale the number of items. ++ ++ load = nr_items * 128 / size ++ = nr_items^{log2 (128) - log2 (size)} ++ = nr_items >> (log2 (size) - log2 (128)) ++ -- if size >= 128 ++ = nr_items << (log2 (128) - log2 (size)) ++ -- otherwise ++ */ ++ int d = __builtin_ctz (ht->size) - 7; ++ unsigned int load = d >= 0 ++ ? ht->nr_items >> d ++ : ht->nr_items << -d; ++ if (load <= ht->max_load) + if (add_one (ht, key, item)) + return 0; + } +diff --git a/libihash/ihash.h b/libihash/ihash.h +index 8829e51..e245db4 100644 +--- a/libihash/ihash.h ++++ b/libihash/ihash.h +@@ -97,8 +97,9 @@ typedef struct hurd_ihash *hurd_ihash_t; + be a power of two. */ + #define HURD_IHASH_MIN_SIZE 32 + +-/* The default value for the maximum load factor in percent. */ +-#define HURD_IHASH_MAX_LOAD_DEFAULT 75 ++/* The default value for the maximum load factor in binary percent. ++ 96b% is equivalent to 75%, 128b% to 100%. */ ++#define HURD_IHASH_MAX_LOAD_DEFAULT 96 + + /* The LOCP_OFFS to use if no location pointer is available. */ + #define HURD_IHASH_NO_LOCP INTPTR_MIN +@@ -143,14 +144,15 @@ void hurd_ihash_free (hurd_ihash_t ht); + void hurd_ihash_set_cleanup (hurd_ihash_t ht, hurd_ihash_cleanup_t cleanup, + void *cleanup_data); + +-/* Set the maximum load factor in percent to MAX_LOAD, which should be +- between 50 and 100. The default is HURD_IHASH_MAX_LOAD_DEFAULT. +- New elements are only added to the hash table while the number of +- hashed elements is that much percent of the total size of the hash +- table. If more elements are added, the hash table is first +- expanded and reorganized. A MAX_LOAD of 100 will always fill the +- whole table before enlarging it, but note that this will increase +- the cost of operations significantly when the table is almost full. ++/* Set the maximum load factor in binary percent to MAX_LOAD, which ++ should be between 64 and 128. The default is ++ HURD_IHASH_MAX_LOAD_DEFAULT. New elements are only added to the ++ hash table while the number of hashed elements is that much percent ++ of the total size of the hash table. If more elements are added, ++ the hash table is first expanded and reorganized. A MAX_LOAD of ++ 128 will always fill the whole table before enlarging it, but note ++ that this will increase the cost of operations significantly when ++ the table is almost full. + + If the value is set to a smaller value than the current load + factor, the next reorganization will happen when a new item is +-- +2.0.0.rc0 + |