Thread: Multithreading with pthreads -- no performance increase

Well to see a performance increase, you would need to be running on a machine with at least two real cores.

If you've only got one core, then threads are just a "smoke and mirrors" illusion, which takes away a small amount of time which could otherwise be used for doing work.
This probably explains why you see no gain, the threads are run sequentially.

> Also, when I use mutexs, the code takes FOREVER. Im guessing this is the deadlock problem I read about?
No, deadlock is when nothing happens at all.
This would be an example of thrashing.

You only need the mutex if you're working with overlapping data. Assuming your split is good, then the two image halves are independent.

I don't normally use threading with the expectation of a performance increase, I just use it for the threads, but in theory IF you have a multi-processor system, you should be able to get such an increase,

Code:

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

void *testfuncA(void *n) {
	int i;
	for (i=0;i<3;i++) {
		printf("%d %d\n",(int)n,i); fflush(stdout);
		sleep(1);
	}
	pthread_exit(0);
}


int main (int argc, char *argv[]) {
	int i;
	pthread_t one, two;

	pthread_create(&one,NULL,testfuncA,(void*)1);
	pthread_create(&two,NULL,testfuncA,(void*)2);

        sleep(3);
	puts("DONE");

	return 0;
}

This takes 3 seconds, not six, but of course there is no load.

If you do have multiple processors, loop your process enough times to make it take 10 seconds or so, and use a dual CPU meter -- both of them should go up to 100% for the duration. If not, there is implementation problem (I guess).

Ah, I did leave out some obvious information... I am running the application on a machine with a dual core processor (core 2 duo), so it isnt a hardware limitation.

Looking at my system monitor, the first core maintains 100% usage while the second core fluctuates at around 80% or 90%. So both cores are being used, though for what purpose I cant figure out...

EDIT: I just added a print statement which prints out 0 in the first thread and 1 in the second thread and the result: with smaller images (10x10 or 400x400) the threads are not running completely concurrently: it prints all of the 0's and then all of the 1's... With a larger image (10 000x5 000), it prints large alternating blocks of all 0's and all 1's. (0000000000011111111111100000000001111111110000000 00etc).

Originally Posted by lilrayray

EDIT: I just added a print statement which prints out 0 in the first thread and 1 in the second thread

Did you use fflush()?

Code:

printf(...you debugging stuff...);  fflush(stdout);

Otherwise the apparent order of operations on the display will not match the real order. The number of 1's or 0's just represents the size of your stdout buffer.

Hmmm. How are you timing this?

Like I said, I've never bothered to do a test like this because I haven't used pthreads purely for performance, but this is a little disappointing.

Hopefully one of the truly seasoned pros on the board will come along with an explanation, be patient A really crude guess would be that because you are reading from and writing to the same contiguous blocks of memory, the kernel is simply serving up first one thread then the other, or that in fact the calculations in add5 (which look simple) are outpacing the FSB transfer (meaning it is a bottleneck). IE, maybe these are complications you need to consider when using threads this way.

Originally Posted by lilrayray

If this is the case, how does one optimize large matrix operations?

I would guess by "unrolling" the loop, qv.
Loop unwinding - Wikipedia, the free encyclopedia
and/or (probably AND) working with larger chunks. Right now, your getPixel/setPixel are only getting/setting 3 bytes at a time. You might want to consider fetching an entire row of pixels instead, so that thread 1 works row by row thru the top half, and then thread 2 row by row thru the bottom.

This may make better use of the processor caches, since they will have room for more than 3 bytes at a time.

you might also want to try pthread librarys set affinity to enrure both cores are workin with threaded version.