multi threading slower than single threading on dual core. why?
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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?
Last edited by nebojsa.andjelkovic; 01-27-2007 at 08:01 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?
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?
Distribution: Solaris 11.4, Oracle Linux, Mint, Ubuntu/WSL
Posts: 9,787
Rep:
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.
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.
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)
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)
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:
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.
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.'"
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.
Distribution: Solaris 11.4, Oracle Linux, Mint, Ubuntu/WSL
Posts: 9,787
Rep:
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 ?
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:
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.
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.'"
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.
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.
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.
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?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.