[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sat, 12 Sep 2015 23:25:41 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: bt.c initial table size
Sayantan -
When testing with lots of hashes, I was getting many "Progress is too
slow!! trying next table size." and this hurt the speeds badly (2 to 3.5
minutes total running time for my test). To have bt.c use a larger
table size right away, I hacked this into create_perfect_hash_table(),
right before the "do { ... } while(1);" loop:
for (i = 0; i < 9; i++) {
unsigned int temp;
temp = next_prime(approx_offset_table_sz % 10);
approx_offset_table_sz /= 10;
approx_offset_table_sz *= 10;
approx_offset_table_sz += temp;
i++;
if (!(i % 5)) {
multiplier_ot += inc_ot;
multiplier_ht += inc_ht;
approx_offset_table_sz = (((long double)num_loaded_hashes / 4.0) * multiplier_ot + 10.00);
approx_hash_table_sz = ((long double)num_loaded_hashes * multiplier_ht);
}
}
The loop contents is some lines I copied from your larger loop. Oh, I
just noticed I got an extra "i++" in there. Well, I am writing this to
ask you to make something like this a standard feature, where we could
request a larger initial table size without hacking the source code -
and maybe the default needs to be bumped up too?
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
