Can multi-threading improve the performance definitely

Question

I'm using C++11 to develop a project.

In some function, I got some parallel tasks as below:

void func() {
    auto res1 = task1();
    auto res2 = task2();
    auto res3 = task3();
    ...
    std::cout << res1 + res2 + res3 + ...;
}

Well, each task is a little heavy, let's say each task would spend 300ms.

Now I'm thinking that making each task to be a std::thread should improve the performance.

But as my understanding, it's the OS who schedules the threads. I'm not sure if the OS ensures that it will execute these threads immediately or it may need to wait for some other stuff?

So my question is if making the tasks multi-threading can definitely improve the performance, or in some cases, this method would get a worse performance?

BTW, I know that too many threads can cause a very bad performance because of context switch, in my real case, the counts of the tasks is less than 10 and they don't share any data.

There is no generic answer, the outcome depends on too many factors (such as the latency of thread creation, the number of CPU cores, etc.). Why don't you simply measure both options? BTW, `std::async` seems to be more appropriate in your case than `std::thread`. — Daniel Langr, Jan 10 '22 at 13:17
Have you tried it? Have you looked at any documentation (cppreference.com comes to mind)? Also, the answer could be "it depends", when some parts are implementation-defined. Rest assured though that any normal OS can run threads on different CPUs, i.e. completely parallel. — Ulrich Eckhardt, Jan 10 '22 at 21:43

score 1 · Accepted Answer · answered Jan 11 '22 at 00:16

I'm not sure if the OS ensures that it will execute these threads immediately or it may need to wait for some other stuff?

The OS will try to start up the threads as quickly as it can. They aren't guaranteed to already be running at the exact instant your thread object's constructor constructor returns, but OTOH the OS won't deliberately wait around before starting them up, either. (e.g. on a system that isn't terribly loaded-down, you can generally expect them to be running within a small number of milliseconds)

So my question is if making the tasks multi-threading can definitely improve the performance, or in some cases, this method would get a worse performance?

Adding multithreading to a program and finding that your program actually takes longer to complete than the single-threaded version is actually a fairly common experience, especially for programmers who are new to multithreaded programming.

It's similar to adding more cooks to a kitchen -- if the cooks work together well and stay out of each other's way, they can get more food cooked in less time, but if they don't, they may well spend most of their time waiting for each other to finish using the various tools/ingredients, or talking about who is supposed to be doing what, and end up being slower than a single cook would be.

In general, multithreading can speed things up, if you are running on a multi-core system, and your various threads don't need to communicate with each other too much, and the threads don't need to obtain exclusive access to shared resources too often, and your threads aren't doing anything grossly inefficient (like intensive polling or busy-waiting). Whether these conditions are easy to achieve or difficult depends a lot on the task you are trying to accomplish.

Can multi-threading improve the performance definitely

1 Answers1