Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.