OpenMP多线程数量增加反而性能下降问题咨询

Hey there! Let's break down why your OpenMP code is getting slower when you add more threads—this is a super common pitfall for folks starting out, so don't worry, we'll fix it.

First, let's unpack the key issues in your code snippet and explain how to resolve them:

1. You're using the wrong timer (clock() isn't for wall time!) #

The clock() function counts the total CPU time used by all threads in your process, not the actual real-world (wall-clock) time you'd measure with a stopwatch. When you add more threads, this value will increase because it's adding up CPU time across every thread, making it look like your code is slower even if it's actually running faster in real time. You should use OpenMP's built-in omp_get_wtime() instead—it measures true elapsed time.

2. Race conditions and incorrect thread-local storage #

Looking at your code, you declared sum[NUM_THREADS] but didn't show how you're assigning threads to their own index in the array. If multiple threads write to the same sum element, you'll get race conditions (threads overwriting each other's work), which not only produces wrong results but also slows things down due to cache contention and unnecessary synchronization.

You also need to explicitly set your thread count and get each thread's unique ID inside the parallel region to safely use the sum array.

3. Thread over-subscription and load imbalance #

If you set more threads than your CPU has physical (or logical, with hyper-threading) cores, your OS will constantly context-switch between threads, adding massive overhead. Stick to thread counts matching your core count for best performance. Also, make sure your loop is split evenly between threads to avoid one thread doing most of the work.

Fixed Version of Your Code #

Here's the corrected code that addresses all these issues:

#include <iostream>
#include <omp.h>

using namespace std;

static long num_steps = 100000000;
double step;

int main() {
    // Use OpenMP's wall-time timer instead of clock()
    double start_time = omp_get_wtime();
    
    int NUM_THREADS;
    cout << "Enter number of threads: ";
    cin >> NUM_THREADS;
    
    omp_set_num_threads(NUM_THREADS);
    
    int i, nthreads;
    double pi, *sum;

    step = 1.0 / (double)num_steps;
    
    // Dynamically allocate sum array to match requested threads
    sum = new double[NUM_THREADS];

    #pragma omp parallel private(i)
    {
        int id = omp_get_thread_num();
        int nthrds = omp_get_num_threads();
        double x;
        
        // Only let the master thread set the global thread count
        if (id == 0)
            nthreads = nthrds;
        
        sum[id] = 0.0;
        // Split loop evenly between threads to avoid load imbalance
        for (i = id; i < num_steps; i += nthrds) {
            x = (i + 0.5) * step;
            sum[id] += 4.0 / (1.0 + x*x);
        }
    }

    // Combine all thread-local sums
    pi = 0.0;
    for (i = 0; i < nthreads; i++)
        pi += sum[i] * step;

    double end_time = omp_get_wtime();
    
    cout << "Pi = " << pi << endl;
    cout << "Time taken: " << end_time - start_time << " seconds" << endl;
    
    delete[] sum;
    return 0;
}

Key Fixes Explained #

• Timer Swap: omp_get_wtime() gives you real elapsed time, so you'll see actual speedups (or slowdowns) when adjusting thread counts.
• Thread-Safe Sum: Each thread writes only to its own sum[id] element, eliminating race conditions and cache contention.
• Even Load Distribution: The loop is split using i += nthrds to ensure every thread gets roughly the same amount of work.
• Avoid Over-Subscription: Test with thread counts from 1 up to your CPU's core count (e.g., 4, 8, 16) — going beyond that will likely cause slowdowns from context switching.

Why You Saw Slowdown Before #

• The clock() timer was misleading you by showing total CPU time instead of real time.
• Race conditions made threads waste cycles fighting for shared memory access.
• If you used more threads than your CPU can handle efficiently, the OS spent more time switching threads than doing actual work.

Give this code a test, and you should see performance improve up to your CPU's core count, then plateau or drop slightly if you add extra threads.

内容的提问来源于stack exchange，提问作者César Pereira