OpenMP和核心/線程

Question

我的CPU是Core i3 330M，有2個內核和4個線程。 當我在終端中執行命令cat /proc/cpuinfo時，就好像我有4個CPUS。 當我使用OpenMP函數get_omp_num_procs()我也得到4。

現在我有一個標准的C ++矢量類，我的意思是一個不使用表達式模板的固定大小的雙數組類。 我仔細並行化了我班級的所有方法，並獲得了“預期”的加速。

問題是：在這么簡單的情況下，我能猜出預期的加速嗎？ 例如，如果我添加兩個沒有並行化for循環的向量，我會得到一些時間（使用shell time命令）。 現在，如果我使用OpenMP，根據內核/線程的數量，我應該將時間除以2或4嗎？ 我強調我只是要求這個特別簡單的問題，數據中沒有相互依賴性，一切都是線性的（向量加法）。

這是一些代碼：

Vector Vector::operator+(const Vector& rhs) const
{
    assert(m_size == rhs.m_size);
    Vector result(m_size);
    #pragma omp parallel for schedule(static)
    for (unsigned int i = 0; i < m_size; i++) 
            result.m_data[i] = m_data[i]+rhs.m_data[i];

    return result;
}

我已經閱讀過這篇文章： OpenMP線程映射到物理核心 。

我希望有人會告訴我更多有關OpenMP如何在這個簡單案例中完成工作的信息。 我應該說我是並行計算的初學者。

謝謝！

Answer 1

編輯：現在添加了一些代碼。

在該特定示例中，計算量很少並且存儲器訪問量很大。 因此，性能將在很大程度上取決於：

• 矢量的大小。
• 你是如何計時的。 （你有一個外環用於計時）
• 數據是否已存在於緩存中。

對於較大的矢量大小，您可能會發現性能受到內存帶寬的限制。 在這種情況下，並行性不會有太大幫助。 對於較小的尺寸，線程的開銷將占主導地位。 如果你得到了“預期的”加速，那么你可能介於結果最佳的位置。

我拒絕提供硬數字，因為一般來說，“猜測”性能，特別是在多線程應用程序中是一個失敗的原因，除非您具有先前的測試知識或對程序及其運行的系統的深入了解。

就像我在這里回答的一個簡單例子： 如何從C程序中獲得100％的CPU使用率

在Core i7 920 @ 3.5 GHz（4核，8個線程）上：

如果我使用4個線程運行，結果是：

This machine calculated all 78498 prime numbers under 1000000 in 39.3498 seconds

如果我運行4個線程並且明確地（使用任務管理器） 將線程固定在4個不同的物理內核上 ，結果是：

This machine calculated all 78498 prime numbers under 1000000 in 30.4429 seconds

---

所以這表明即使是一個非常簡單和令人尷尬的並行應用程序也是多么不可預測。 涉及大量內存使用和同步的應用程序變得更加丑陋......

Answer 2

添加到Mysticals的答案。 你的問題純粹是內存帶寬有限 。 看看STREAM基准測試 。 在單線程和多線程情況下在您的計算機上運行它，並查看三元組結果 - 這是您的情況（好吧，差不多，因為您的輸出向量同時是您的輸入向量之一）。 計算您移動的數據量，您將確切知道預期的性能。

多線程是否適用於此問題？ 是。 單個CPU內核很少能夠使系統的整個內存帶寬飽和。 現代計算機平衡可用內存帶寬與可用內核數量。 根據我的經驗，您需要大約一半的內核才能通過簡單的memcopy操作來滿足內存帶寬。 如果你在路上做一些計算，可能還需要一些。

請注意，在NUMA系統上，您需要將線程綁定到cpu核心並使用本地內存分配來獲得最佳結果。 這是因為在這樣的系統上，每個CPU都有自己的本地內存，訪問速度最快。 您仍然可以像通常的SMP一樣訪問整個系統內存，但這會產生通信成本 - CPU必須明確地交換數據。 將線程綁定到CPU並使用本地分配非常重要。 如果不這樣做會導致可擴展性喪失。 如果要在Linux上執行此操作，請檢查libnuma。