我正在编写一个程序来执行一些长时间的计算，我可以根据需要将其分成任意多个任务。为了便于讨论，让我们假设我正在编写一个算法，通过尝试将它除以 2 到 p-1 之间的所有数字来确定数字 p 是否为素数。这个任务显然可以分解成很多线程。

我实际上编写了一个示例应用程序来执行此操作。作为参数，我给出了我要检查的数字，以及要使用的线程数(每个线程都被赋予了一个相等大小的数字范围，以尝试将 p 除以 - 它们一起覆盖了整个范围)。

我的机器有 8 个核心。我开始使用我知道是质数 (2971215073) 的大量程序运行该程序，并使用 1、2、3 个线程等，直到达到 8 个线程——每次程序运行速度都比前一个快，这正是我所期望的。然而，当我尝试大于 8 的数字时，计算时间实际上越来越短(即使是一点点)!

我的线程中没有 I/O 或类似的东西，只有纯 CPU 计算。我预计当我通过 8 个线程时运行时间会变得更糟，因为会有更多的上下文切换并且并行运行的线程数保持在 8。很难说峰值在哪里，因为差异很小并且变化从一个运行到另一个，但是很明显，即 50 个线程以某种方式运行得比 8 个线程快(约 300 毫秒)...

我的猜测是，因为我有这么多线程，我得到更多的运行时间，因为我在系统的线程池中有更大的部分，所以我的线程被选择得更多。但是，我创建的线程越多，程序运行得越快，这似乎没有意义(否则为什么不每个人都创建1000个线程？？)。

任何人都可以提供一个解释，也许还有一个关于相对于机器上的核心数量创建多少线程的最佳实践？

谢谢。

我的代码供感兴趣的人使用(在 Windows、VS2012 上编译):

#include <Windows.h>
#include <conio.h>
#include <iostream>
#include <thread>
#include <vector>

using namespace std;

typedef struct
{
    unsigned int primeCandidate;
    unsigned int rangeStart;
    unsigned int rangeEnd;
} param_t;


DWORD WINAPI isDivisible(LPVOID p)
{
    param_t* param = reinterpret_cast<param_t*>(p);

    for (unsigned int d = param->rangeStart; d < param->rangeEnd; ++d)
    {
        if (param->primeCandidate % d == 0)
        {
            cout << param->primeCandidate << " is divisible by " << d << endl;
            return 1;
        }
    }

    return 0;
}

bool isPrime(unsigned int primeCandidate, unsigned int numOfCores)
{
    vector<HANDLE> handles(numOfCores);
    vector<param_t> params(numOfCores);
    for (unsigned int i = 0; i < numOfCores; ++i)
    {
        params[i].primeCandidate = primeCandidate;
        params[i].rangeStart = (primeCandidate - 2) * (static_cast<double>(i) / numOfCores) + 2;
        params[i].rangeEnd = (primeCandidate - 2) * (static_cast<double>(i+1) / numOfCores) + 2;
        HANDLE h = CreateThread(nullptr, 0, reinterpret_cast<LPTHREAD_START_ROUTINE>(isDivisible), &params[i], 0, 0);
        if (NULL == h)
        {
            cout << "ERROR creating thread: " << GetLastError() << endl;
            throw exception();
        }
        handles[i] = h;
    }

    DWORD ret = WaitForMultipleObjects(numOfCores, &handles[0], TRUE, INFINITE);
    if (ret >= WAIT_OBJECT_0 && ret <= WAIT_OBJECT_0 + numOfCores - 1)
    {
        for (unsigned int i = 0; i < numOfCores; ++i)
        {
            DWORD exitCode = -1;
            if (0 == GetExitCodeThread(handles[i], &exitCode))
            {
                cout << "Failed to get thread's exit code: " << GetLastError() << endl;
                throw exception();
            }

            if (1 == exitCode)
            {
                return false;
            }
        }

        return true;
    }
    else
    {
        cout << "ERROR waiting on threads: " << ret << endl;
        throw exception();
    }
}

int main()
{
    unsigned int primeCandidate = 1;
    unsigned int numOfCores = 1;

    cout << "Enter prime candidate: ";
    cin >> primeCandidate;
    cout << "Enter # of cores (0 means all): ";
    cin >> numOfCores;
    while (primeCandidate > 0)
    {
        if (0 == numOfCores) numOfCores = thread::hardware_concurrency();

        DWORD start = GetTickCount();
        bool res = isPrime(primeCandidate, numOfCores);
        DWORD end = GetTickCount();
        cout << "Time: " << end-start << endl;
        cout << primeCandidate << " is " << (res ? "" : "not ") << "prime!" << endl;

        cout << "Enter prime candidate: ";
        cin >> primeCandidate;
        cout << "Enter # of cores (0 means all): ";
        cin >> numOfCores;
    }

    return 0;
}

最佳答案

是的。这是我在 i7/Vista 64 机器上所做的一些测试的一小部分(4 个“真实”内核 + 超线程):

8 tests,
400 tasks,
counting to 10000000,
using 8 threads:
Ticks: 2199
Ticks: 2184
Ticks: 2215
Ticks: 2153
Ticks: 2200
Ticks: 2215
Ticks: 2200
Ticks: 2230
Average: 2199 ms

8 tests,
400 tasks,
counting to 10000000,
using 32 threads:
Ticks: 2137
Ticks: 2121
Ticks: 2153
Ticks: 2138
Ticks: 2137
Ticks: 2121
Ticks: 2153
Ticks: 2137
Average: 2137 ms

.. 表明，就像在您的测试中一样，线程的“超额订阅”确实会导致整体执行时间略微提高 2-3%。我的测试将简单的“计算整数”CPU 密集型任务提交给具有不同线程数的线程池。

我当时的结论是，微小的改进是因为更多的线程占用了我机器上“基本负载”的更大百分比——1000 个线程中的少数线程占负载的 1-4%-几乎总是空闲的 Firefox、uTorrent、Word、任务栏等中的奇怪线程在测试期间碰巧运行了一点。

在我的测试中，使用 64 个线程而不是 8 个线程的“上下文切换开销”似乎可以忽略不计。

这仅适用于任务使用的数据非常小的情况。后来我重复了一批类似的测试，其中任务使用 8K 数组——L1 缓存的大小。在这种“最坏情况”的情况下，使用比核心更多的线程会导致非常明显的减速，直到在 16 个及以上线程时，性能下降了 40%，因为线程交换了整个缓存。在大约 20 个线程以上，速度并没有变得更糟，因为无论有多少线程运行任务，缓存仍然以相同的速率从每个内核换出。

另请注意，我有足够的 RAM，因此页面错误很少。

关于c++ - 执行计算时 - 我应该打开多少个线程？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17123795/