指定范围之间的C ++多线程素数计数器

Question

#include <math.h>
#include <sstream>
#include <iostream>
#include <mutex>
#include <stdlib.h>
#include <chrono>
#include <thread>

bool isPrime(int number) {
    int i;

    for (i = 2; i < number; i++) {
        if (number % i == 0) {
            return false;
        }
    }

    return true;
}

std::mutex myMutex;

int pCnt = 0;

int icounter = 0;

int limit = 0;


int getNext() {
    std::lock_guard<std::mutex> guard(myMutex);
    icounter++;
    return icounter;
}

void primeCnt() {
    std::lock_guard<std::mutex> guard(myMutex);
    pCnt++;
}

void primes() {
    while (getNext() <= limit)
        if (isPrime(icounter))
            primeCnt();
}

int main(int argc, char *argv[]) {
    std::stringstream ss(argv[2]);
    int tCount;
    ss >> tCount;

    std::stringstream ss1(argv[4]);
    int lim;
    ss1 >> lim;

    limit = lim;

    auto t1 = std::chrono::high_resolution_clock::now();

    std::thread *arr;
    arr = new std::thread[tCount];

    for (int i = 0; i < tCount; i++)
        arr[i] = std::thread(primes);

    for (int i = 0; i < tCount; i++)
        arr[i].join();

    auto t2 = std::chrono::high_resolution_clock::now();

    std::cout << "Primes: " << pCnt << std::endl;
    std::cout << "Program took: " << std::chrono::duration_cast<std::chrono::milliseconds>(t2 - t1).count() <<
    " milliseconds" << std::endl;
    return 0;
}

Hello , im trying to find the amount of prime numbers between the user specified range, ie, 1-1000000 with a user specified amount of threads to speed up the process, however, it seems to take the same amount of time for any amount of threads compared to one thread. Im not sure if its supposed to be that way or if theres a mistake in my code. thank you in advance!

Answer 1

You don't see performance gain because time spent in isPrime() is much smaller than time which threads take when fighting on mutex.

One possible solution is to use atomic operations, as @The Badger suggested. The other way is to partition your task into smaller ones and distribute them over your thread pool.

For example, if you have n threads, then each thread should test numbers from i*(limit/n) to (i+1)*(limit/n) , where i is thread number. This way you wouldn't need to do any synchronization at all and your program would (theoretically) scale linearly.

Answer 2

Multithreaded algorithms work best when threads can do a lot of work on their own.

Imagine doing this in real life: you have a group of 20 humans that will do work for you, and you want them to test whether each number up to 1000 is prime. How will you do this?

Would you hand each person a single number at a time, and ask them to come back to you to tell you if its prime and to receive another number?

Surely not; you would give each person a bunch of numbers to work on at once, and have them come back and tell you how many were prime and to receive another bunch of numbers.

Maybe even you'd divide up the entire set of numbers into 20 groups and tell each person to work on a group. (but then you run the risk of one person being slow and having everyone else sitting idle while you wait for that one person to finish... although there are so-called "work stealing" algorithms, but that's complicated)

The same thing applies here; you want each thread to do a lot of work on its own and keep its own tally, and only have to check back with the centralized information once in a while.

Answer 3

A better solution would be to use the Sieve of Atkin to find the primes (even the Sieve of Eratosthenes which is easier to understand is better), your basic algorithm is very poor to start with. It will for every number n in your interval do n checks in order to determine if it's prime and do this limit times. This means that you're doing about limit*limit/2 checks - that's what we call O(n^2) complexity. The Sieve of Atkins OTOH only have to do O(n) operations to find all primes. If n is large it is hard to beat the algorithm that has fewer steps by performing the steps faster. Trying to fix a poor algorithm by throwing more resources on it is a bad strategy.

Another problem with your implementation is that it has race conditions and therefore is broken to start with. It's often little use in optimizing something unless you first make sure it's working correctly. The problem is in the primes function:

void primes() {
    while (getNext() <= limit)
        if( isPrime(icounter) )
            primeCnt();
}

Between the getNext() and isPrime another thread may have increased the icounter and cause the program to skip candidates. This results in the program giving different result each time. In addition neither icounter nor pCnt is declared volatile so there's actually no guarantee that the value gets to the global storage location as part of the mutex lock.

Since the problem is CPU intensive, that is almost all of the time is spent executing CPU instructions multi threading won't help unless you have multiple CPU's (or cores) which the OS are scheduling threads of the same process on. This means that there is a limit of number of threads (that can be as low as 1 - I fx see only a improvement for two threads, beyond that theres none) where you can expect an improved performance. What happens if you have more threads than cores is that the OS will just let one thread run for a while on a core and then switch the thread an let the next thread execute for a while.

The problem that may arise when scheduling threads on different cores is in addition that each core may have separate cache (which is faster than the shared cache). In effect if two threads are going to access the same memory the separated cache has to be flushed as part of the synchronization of the data involved - this may be time consuming.

That is you have to strive to keep the data that the different threads are working on separate and minimize the frequent use of common variable data. In your example it would mean that you should avoid the global data as much as possible. The counter for example need only be accessed when the counting has finished (to add the threads contribution to the count). Also you could minimize the use of icounter by not reading it for each candidate, but get a bunch of candidates in one go. Something like:

void primes() {
     int next;
     int count=0;

     while( (next = getNext(1000)) <= limit ) {
          for( int j = next; j < next+1000 && j <= limit ; j++ ) {
              if( isPrime(j) )
                  count++;
          }
     }

     primeCnt(count);
 }

where getNext is the same, but it reserves a number of candidates (by increasing icounter by the supplied count) and primeCnt adds count to pCnt .

Consequently you may end up in a situation where the core runs one thread, then after a while switch to another thread and so on. The result of this is that you will have to run all the code for your problem plus code for switching between the thread. Add that you will probably have more cache hits, then this will probably even be slower.

Answer 4

Perhaps instead of a mutex try to use an atomic integer for the counter. It might speed it up a bit, not sure by how much.

#include <atomic>
std::atomic<uint64_t> pCnt; // Made uint64 for bigger range as @IgnisErus mentioned
std::atomic<uint64_t> icounter;

int getNext() {
    return ++icounter; // Pre increment is faster 
}

void primeCnt() {
    ++pCnt;
}

On benchmarking, most of the time the processor need to warm up to get the best performance, so to take the time once is not always a good representation of the actual performance. Try to run the code many times and get an average. You can also try to do some heavy work before you do the calculation (A long for-loop calculating the power of some counter?)

Getting accurate benchmark results is also a topic of interest for me since I do not yet know how to do it.