summaryrefslogtreecommitdiff
path: root/debian/patches/0004-libihash-use-fast-binary-scaling-to-determine-the-lo.patch
diff options
context:
space:
mode:
authorJustus Winter <4winter@informatik.uni-hamburg.de>2014-05-13 20:09:05 +0200
committerJustus Winter <4winter@informatik.uni-hamburg.de>2014-05-13 20:09:05 +0200
commit8ff7c917a8dbe541fb4bf797e21acc6d0edc7ceb (patch)
treebaebeb11c8c44632601828f786b8eca1647e83ea /debian/patches/0004-libihash-use-fast-binary-scaling-to-determine-the-lo.patch
parent2ab6147feee29f561592bcf07bb54c6688eccef7 (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.patch116
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
+