为什么在使用pthread的Ubuntu中单线程比多线程快？

Question

XUbuntu 14.04, 2 processors.

Multi-threads costs 0.8s while single thread costs only 0.4s.

If MULTI_THREAD is defined,then the program will run in a single thread. Otherwise, it's a Multi-thread program

what's wrong?

 ----------------code------------------------------

    #include <pthread.h>
    #include <semaphore.h>
    #include <stdio.h>
    #include <stdlib.h>
    #include <time.h>

    #define MULTI_THREAD
    #define NUM             10000
    #define SEM_M           10
    int arr[NUM];
    FILE *f;

        typedef struct _SemData{
            sem_t           sem_full;
            sem_t           sem_empty;
        }SemData;

        void InitSemData(SemData *sd){
            sem_init(&sd->sem_full,0,0);
            sem_init(&sd->sem_empty,0,SEM_M);
        }

        void DestroySemData(SemData *sd){

                sem_destroy(&sd->sem_full);
                sem_destroy(&sd->sem_empty);
            }

            void *Produce(void* data){
            #ifdef MULTI_THREAD
                SemData* psd=(SemData*)data;
            #endif
                int i;
                for(i=0;i<NUM;++i){
            #ifdef MULTI_THREAD
                    sem_wait(&psd->sem_empty);
            #endif
                        arr[i]=i;
                        fprintf(f,"produce:%d\n",arr[i]);
            #ifdef MULTI_THREAD
                    sem_post(&psd->sem_full);
            #endif
                }
            }

        void *Custom(void* data){
        #ifdef MULTI_THREAD
            SemData* psd=(SemData*)data;
        #endif
            int i,j;
            for(i=0;i<NUM;++i){
        #ifdef MULTI_THREAD
                sem_wait(&psd->sem_full);
        #endif
                    int tmp=0;
                    for(j=0;j<NUM;++j){
                        tmp+=arr[i];
                    }
                    arr[i]=tmp;
                    fprintf(f,"Custom:%d\n",arr[i]);
        #ifdef MULTI_THREAD
                sem_post(&psd->sem_empty);
        #endif
            }
        }

        void main(){
            f=fopen("b.txt","w");
            clock_t start=clock();
        #ifdef MULTI_THREAD
            SemData sd;
            InitSemData(&sd);

            pthread_t th0,th1;
            pthread_create(&th0,NULL,Produce,(void*)&sd);
            pthread_create(&th1,NULL,Custom,(void*)&sd);

            pthread_join(th0,NULL);
            pthread_join(th1,NULL);

            DestroySemData(&sd);
        #else
            Produce(NULL);
            Custom(NULL);
        #endif
            printf("TotalTime:%fs\n",((float)(clock()-start))/CLOCKS_PER_SEC);
            fclose(f);
        }

Answer 1

In general parallelization brings additional costs. You have to communicate for distributing and collecting data. Additionally synchronizing can be very expensive.

Answer 2

Your single-threaded code works like this:

1. Produce all the numbers
2. Consume all the numbers

The multi-threaded code works like this:

Producer                             Consumer
--------                             --------
Produce one number                   Wait for a number to be produced
Wait for a number to be consumed     Consume one number
Produce one number                   Wait for a number to be produced
Wait for a number to be consumed     Consume one number
Produce one number                   Wait for a number to be produced
Wait for a number to be consumed     Consume one number
...

As you can see, only one thread at a time is actually doing anything.
If there were no overhead to signalling and context switching this would take approximately the same time as the single-threaded code, but since signals and context switches are pretty expensive it's much slower.

Even if you rewrote your multi-threaded code to first produce all the numbers and then consume them, it would be slower, because that would be exactly the same as the single-threaded code plus the signals and context-switches.

Answer 3

The algorithm you are testing doesn't need to be broken in multiple threads to be more efficient: you must consider that there's always an overhead in creating a new thread (ie allocating some resources, waiting for sync, etc). You must evaluate the trade off between new thread creation overhead and single thread complexity.