C crypt_r really 32 times slower than crypt?

Question

I'm doing a proof of concept descrypt bruteforcer, and have the single threaded version working nicely at around 190k hashes/s with a single core of i-7 860 cpu.

I am now trying to make a multithreaded version of this program (my first time playing with threads, so I'm hoping that I'm doing something wrong here).

I first attempted to use crypt directly, this was fast but resulted in mangled hashes, as the threads were contesting the crypt function.

Using mutex lock and unlock on the function helped, but this reduced the speed of the program to just a few percent higher than the single threaded version.

I then managed to google up crypt_r which was advertised to be threadsafe. Modified both the singlethreaded version to use crypt_r (with single thread) and the multithreaded version to use it instead of crypt, and the performance in singlethreaded version dropped to around 3.6kh/s and to around 7.7kh/s in the multithreaded version when using two cores at 99.9% utilization.

So the question is, should it be this slow?

Answer 1

The problem was, that the function I was calling when executing the crypt_r function also contained the code for initializing the struct that it requires.

The solution was to move the initialization out of the function that is called when hashing is done.

simplified example incorrect way:

for (int i = 0; i < 200000; i++)
{
    struct crypt_data data;
    data.initialized = 0;

    char* hash = crypt_r("password", "sa", &data);
    printf("%i %s", i, hash);
}

correct way:

struct crypt_data data;
data.initialized = 0;

for (int i = 0; i < 200000; i++)
{
    char* hash = crypt_r("password", "sa", &data);
    printf("%i %s", i, hash);
}