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 ...
- 05-22-2009 #1
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
Run as ./program_name num_threadsCode:#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++; } }
And then kill -USR1 $(pgrep program_name) to display the speed of different number of threads.
- 05-24-2009 #2Linux Guru
- 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!


Reply With Quote