LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Programming (https://www.linuxquestions.org/questions/programming-9/)
-   -   multi threading slower than single threading on dual core. why? (https://www.linuxquestions.org/questions/programming-9/multi-threading-slower-than-single-threading-on-dual-core-why-523364/)

nebojsa.andjelkovic 01-27-2007 07:00 PM

multi threading slower than single threading on dual core. why?
 
I have one problem. My C application iz slower when I changed it to be a multi threaded application on dual core machine. Application is about image processing but that is not important. But it is important that this application isn't slower on single core machine.

Does anybody have any idea? What is going on? How can multi threaded application be slower than single threaded on dual core?

docinthebox 01-27-2007 07:43 PM

Blocking among the threads maybe? Did you check CPU load on the two cores? Are they both loaded most of the time or is one of the cores idle?

nebojsa.andjelkovic 01-28-2007 07:47 AM

Quote:

Originally Posted by docinthebox
Blocking among the threads maybe? Did you check CPU load on the two cores? Are they both loaded most of the time or is one of the cores idle?

No, blocking among the threads, no, that isn't reason. And both cores are working. Problem isn't so trivial. I surmise that problem is about scheduler or something similar.
Does anybody have any idea?

jlliagre 01-28-2007 07:57 AM

Quote:

Originally Posted by nebojsa.andjelkovic
No, blocking among the threads, no, that isn't reason. And both cores are working. Problem isn't so trivial. I surmise that problem is about scheduler or something similar.

So you really think the multi-threading / multi-core thing just doesn't work ?

Perhaps is it time for you to tell what O/S, kernel, threading library you are using, and explain why do you think your application is not the problem's root cause.

nebojsa.andjelkovic 01-28-2007 10:52 AM

Quote:

Originally Posted by jlliagre
So you really think the multi-threading / multi-core thing just doesn't work ?

Perhaps is it time for you to tell what O/S, kernel, threading library you are using, and explain why do you think your application is not the problem's root cause.

No I think that multi-threading/multi-core works, it work very good on windows, but I have a problem just on linux.

My OS is Kubuntu 6.06, I use POSIX threads. Application part for multi-threading is very simple, just create two threads and wait for them to finish. Threads function is same for windows and for linux, the difference is just functions that create threads and function that wait for threads(pthread_create(...) and pthread_join() for linux, and correspond for windows). Both threads work on different data(one matrix, but one thread works on one half and another on the second) so I needn't to synchronize them.

Does anybody have any idea now?

Indiestory 01-28-2007 11:44 AM

i have no idea what im talking about here, this is way over my head, but could it be because you arent using a smp kernel, so its just not ready to handle multithreading. ( my first google turned up something along these lines)

nebojsa.andjelkovic 01-28-2007 05:09 PM

Quote:

Originally Posted by Indiestory
i have no idea what im talking about here, this is way over my head, but could it be because you arent using a smp kernel, so its just not ready to handle multithreading. ( my first google turned up something along these lines)

No that is not problem. thanks any way.

sundialsvcs 01-28-2007 10:36 PM

It is certainly possible for a multi-threaded application to be slower than a single-threaded one, whether there are "dual cores" or two discrete CPUs.

There are two "bright line rules" that will help you to determine if a particular application will actually benefit from a multi-threaded implementation:
  1. The functions are truly independent: The activities that you have spun-off into separate threads actually can operate independently, and can proceed "forward" in a meaningful way without reference to the others' data and/or activities.
  2. There is no hardware contention: The hardware resources which materially limit the progress of 'this' thread are unrelated to those which materially limit the progress of 'that' thread.
"Multi-core" is a sort of a halfway-compromise: there are two execution units, true, but they share the same hardware-interface to the outside world. Depending on the situation, this might be "free beer" or "big deal." Great when it's great, and worse-than-useless when it's not (but never say that to the Marketing Department!).

"Technically, 'So it goes.'" :rolleyes:

If your application is truly designed to exploit multiple CPUs or cores, then it will truly "run faster." But if not, it may (as you have seen!) "run slower." Perhaps, much slower.

jlliagre 01-29-2007 02:00 AM

Quote:

Originally Posted by nebojsa.andjelkovic
No I think that multi-threading/multi-core works, it work very good on windows, but I have a problem just on linux.

On the same hardware ?
Quote:

My OS is Kubuntu 6.06, I use POSIX threads. Application part for multi-threading is very simple, just create two threads and wait for them to finish. Threads function is same for windows and for linux, the difference is just functions that create threads and function that wait for threads(pthread_create(...) and pthread_join() for linux, and correspond for windows). Both threads work on different data(one matrix, but one thread works on one half and another on the second) so I needn't to synchronize them.
Is it pure CPU load or are there other potential resource contention (I/O, network) ?

Can you share your measurement methodology and results ?

nebojsa.andjelkovic 01-29-2007 05:03 PM

Quote:

Originally Posted by sundialsvcs
It is certainly possible for a multi-threaded application to be slower than a single-threaded one, whether there are "dual cores" or two discrete CPUs.

There are two "bright line rules" that will help you to determine if a particular application will actually benefit from a multi-threaded implementation:
  1. The functions are truly independent: The activities that you have spun-off into separate threads actually can operate independently, and can proceed "forward" in a meaningful way without reference to the others' data and/or activities.
  2. There is no hardware contention: The hardware resources which materially limit the progress of 'this' thread are unrelated to those which materially limit the progress of 'that' thread.
"Multi-core" is a sort of a halfway-compromise: there are two execution units, true, but they share the same hardware-interface to the outside world. Depending on the situation, this might be "free beer" or "big deal." Great when it's great, and worse-than-useless when it's not (but never say that to the Marketing Department!).

"Technically, 'So it goes.'" :rolleyes:

If your application is truly designed to exploit multiple CPUs or cores, then it will truly "run faster." But if not, it may (as you have seen!) "run slower." Perhaps, much slower.


Like I alredy said on the windows It works very good. Its faster for aboutd 30-40%. So ol important things for multhithreading is enabled. So this is not a problem.

nebojsa.andjelkovic 01-29-2007 05:11 PM

Quote:

Originally Posted by jlliagre
On the same hardware ?
Is it pure CPU load or are there other potential resource contention (I/O, network) ?

Can you share your measurement methodology and results ?

Yes on the same hardware. Yes pure CPU load, no I/O and network. It have just calculate an interpolation function over some matrices. Apropos it resize same picture (e.g. from 320x240 to 400x300) and one thread work on one half of picture and second works on the second.
The measurement methodology is using a system time. On the start of function I read the system time, and on the end again end just subtract them.

Any new idea for my problem?

jlliagre 01-30-2007 01:41 AM

There is nothing that would explain it from the few clues you post.

Can you write a small stripped down test case demonstrating the issue and post its whole source code ?

slantoflight 01-30-2007 06:53 PM

Quote:

Originally Posted by nebojsa.andjelkovic
Apropos it resize same picture (e.g. from 320x240 to 400x300) and one thread work on one half of picture and second works on the second.


Now I wonder if that technically counts as two independent tasks. It seems possible thats problem that could be solved more effectively with single threading. Could vary from OS to OS. Perhaps the overhead of even loading the POSIX thread library, could buckle down a simple application. It could be for linux its best to let the operating system passively handle threads for simple applications that don't truely have independent tasks. And on windows its best to take charge.

graemef 01-30-2007 09:56 PM

Looking at the task you are doing are the threads necessary? The time consuming part of the work would appear to be reading the data from hard-disk to RAM, then from RAM into CPU and then back to the hard disk, with the majority of the processing requiring data from RAM plus some processing, maybe there is more time waiting for the data to arrive from RAM to the CPU than actual processing. So what is your CPU load when you run this?


All times are GMT -5. The time now is 11:52 PM.