C crypt\u r真的比crypt慢32倍？

我正在做一个概念验证descrypt bruteforcer，并让单线程版本在190k哈希/秒左右运行良好，单核I-7860 cpu

我现在正在尝试制作这个程序的多线程版本（我第一次玩线程，所以我希望我在这里做错了什么）

我第一次尝试直接使用crypt，虽然速度很快，但由于线程对crypt函数有争议，导致散列被破坏

在函数上使用互斥锁和解锁有帮助，但这将程序的速度降低到仅比单线程版本高几个百分点

然后我在谷歌上搜索到了crypt\r，广告上说它是线程安全的。 将两个单线程版本都修改为使用crypt_r（使用单线程） 多线程版本使用它而不是crypt，单线程版本的性能下降到3.6k h/s左右，多线程版本的性能下降到7.7k h/s左右，使用两个内核时的利用率为99.9%

---

所以问题是，它应该这么慢吗？

问题是，我在执行crypt\r函数时调用的函数也包含初始化结构所需的代码

解决方案是将初始化移出散列完成时调用的函数

简化示例不正确方式：

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);
}

for（int i=0；i<200000；i++）
{
结构加密数据；
data.initialized=0；
char*hash=crypt_r（“密码”、“sa”和数据）；
printf（“%i%s”，i，散列）；
}

正确的方法：

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);
}

struct crypt_数据；
data.initialized=0；
对于（int i=0；i<200000；i++）
{
char*hash=crypt_r（“密码”、“sa”和数据）；
printf（“%i%s”，i，散列）；
}

谁实现了

crypt\r

？格里伯？eglibc？一个线程安全且可重入的函数（根据，请注意，它们不是同一件事）会带来开销，这似乎是合理的。或者为什么？我看不出哈希函数不是纯函数的任何原因。一个正常的实现会让非可重入函数只分配一个缓冲区并调用可重入的

\r

版本。它不应该太慢，因为最终它们都应该是完全相同的实现。glibc正是这样做的：你能划分搜索空间吗？运行单独的进程不是更有意义吗？差不多SETI@Home? 线是硬的！