Find the answer to your Linux question:
Results 1 to 2 of 2
I've been experimenting with pthreads lately, writing some multithreaded apps to take advantage of my multi-core processors. The only problem is that anything I've written runs faster without threading, and ...
  1. #1
    Linux Newbie SagaciousKJB's Avatar
    Join Date
    Aug 2007
    Location
    Yakima, WA
    Posts
    162

    pthreads multi-threaded apps

    I've been experimenting with pthreads lately, writing some multithreaded apps to take advantage of my multi-core processors.

    The only problem is that anything I've written runs faster without threading, and I don't know why.

    One program I have compares randomly generated strings against a target string ( been using it to test password strength ) and see how long it takes to get a match. So I decided to run four threads at once doing this.

    I've separated all of them to the point where they're all operating on their own parts of memory, in individual functions, and have eliminated the need for mutexes, but it reduces the speed down from 900K attempts per second, to 100-200K attempts per second with two threads running, and 30-50K with four.


    I can't really find much that covers the concepts of multi-threaded programming except for a few very brief guides on decomposition, which I used to separate all the variables and what not. My fear is that, as another guide said, some applications are just better for sequential and one-core operations.


    I'd rather not post the source, as it's so rough right now that it's frankly embarassing, but perhaps we can use this example to figure out the principles

    Code:
    #include <signal.h>
    #include <stdio.h>
    #include <time.h>
    #include <pthread.h>
    
    long long unsigned int count, start, end;
    
    void *functionC();
    void *printStuff();
    pthread_mutex_t mutex1 = PTHREAD_MUTEX_INITIALIZER;
    
    struct threadStruct {
            int rc;
            pthread_t thread;
    };
    
    static void handler(int sig, siginfo_t *si, void *unused)
    {
               printf("%.2lf cps\n", (float)count/(time(0) - start));
    }
    
    int main(int argc, char *argv[])
    {
            int threads = atoi(argv[1]), i = 0;
            struct threadStruct threadTrack[threads];
            struct sigaction sa;
    
            sa.sa_flags = SA_SIGINFO;
            sigemptyset(&sa.sa_mask);
            sa.sa_sigaction = handler;
    
            start = time(0);
            count = 1;
    
            if (sigaction(SIGUSR1, &sa, NULL) == -1)
                            ;
    
    
            for(i = 0; i < threads; i++)
            {
                    if( (threadTrack[i].rc=pthread_create(&threadTrack[i].thread, NULL, &functionC, NULL)) )
                    {
                          printf("Thread creation failed: %d\n", threadTrack[i].rc);
                    }
            }
    
       /* Wait till threads are complete before main continues. Unless we  */
       /* wait we run the risk of executing an exit which will terminate   */
       /* the process and all threads before the threads have completed.   */
    
            for(i = 0; i < threads; i++)
                    pthread_join( threadTrack[i].thread, NULL);
    
    
            return 0;
    }
    
    void *functionC()
    {
            while(count)
            {
            count++;
            }
    }
    Run as ./program_name num_threads

    And then kill -USR1 $(pgrep program_name) to display the speed of different number of threads.

  2. #2
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, or in a galaxy far, far away.
    Posts
    8,974
    Check out "Modern Multithreading" by Carver and Tai, published by Wiley. You should be able to get it from Amazon.com. I have found it very useful.

    As for your performance problems, remember that each thread has context and each context switch has overhead. One process is probably context switching much less frequently. Running many threads in parallel doing such fine-grained operations as a simple variable increment as you are doing is not going to run faster multi-threaded than single threaded. So, going from 900K iterations / sec to 100-200K / sec is probably about right. Where multi-threading (especially on multiple processors/cores) will shine is when you are doing more complex processing.

    FYI, the ffmpeg audio/video transcoding tool can take advantage of multiple threads, and on my 8 core system, running with 8 threads is almost 8x as fast as running 1 thread when transcoding video from avi or mkv to mpeg2 (dvd compatible). When processing an hour of video goes from almost 2 hours to about 15 minutes, you know it works.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
...