15 Feb 2009 15:34
TAGS: dev thoughts
I think, that an idea to make every program multi-thread and multi-processor conscious is wrong.
This may seem radical and stupid at first, but let's think about this.
Not everyone knows, that multi-thread algorithms are:
- less optimal than corresponding single-thread ones
- more complicated
Saying less optimal than corresponding single-thread I mean this:
Suppose you have a problem to solve. You have quad-core processor and two algorithms. One loads only one core and runs for 1 minute. The parallel (multi-thread) loads all four cores and runs for 20 seconds.
Is 20 seconds more than 60 seconds? Of course not. But 20 seconds running on for cores is sometimes more like 80 seconds.
Why?
Suppose, you run the same algorithm for four different sets of data.
Single-thread version | ||||
---|---|---|---|---|
Core 1 | Core 2 | Core 3 | Core 4 | time in seconds |
single-thread algorithm for data set 1 | single-thread algorithm for data set 2 | single-thread algorithm for data set 3 | single-thread algorithm for data set 4 | 60 |
Total time in seconds | 60 |
Multi-thread version | ||||
---|---|---|---|---|
Core 1 | Core 2 | Core 3 | Core 4 | time in seconds |
multi-thread algorithm for data set 1 | 20 | |||
multi-thread algorithm for data set 2 | 20 | |||
multi-thread algorithm for data set 3 | 20 | |||
multi-thread algorithm for data set 4 | 20 | |||
Total time in seconds | 80 |
Summary
In both situations the programs solved a problem for four sets of data using four processing units. Using single-thread version was faster.
Bottom line
- implementing multi-thread programs is more complex than single-thread
- using parallelism adds some overhead to the program performance
- the best parallel programs are almost as fast as N-times faster than single-thread versions when using N-times more processing power
Having this said I don't think parallel computing should really happen on home computers. However, multi-threading should be used in programs to handle so-called background tasks, improving UI responsibility and separating tasks of different program parts.
Also, having multi-core processor seems OK even when running only single-thread applications, because usually you have more than 1 (usually 2 to 10) running processes, so system utilizes the additional power.
Actually I see a way of utilizing the power of multi-core processors in breaking complicated programs like window managers, display managers, file browsers, web browsers into more processes (or threads) that do different tasks, that are easily separable and thus not adding too much overhead1 and load to system.
As my post title says, I completely agree with you.
So if we have multiple cores, why not, as you have suggested, control which processors process particular processes? (puff puff puff puff, sorry for the alliteration ;D)
Ideally, if you had two cores, have one core handle the operating system, and the other core handle the applications. If the applications core gets too much activity, then it should share its tasks with the operating system core. Background tasks such as system maintenance, virus scanners and firewalls should be a part of the operating system core. Maybe if you had a quad-core processor, you would divide the application processes amongst the three application cores. For example, open one application, the second core handles it. Open another, the third core handles it. Open a third, the fourth core handles it.
But you're the expert in that area… what do you think?
Maybe you could create a linux architecture that runs in this way? Just a thought…
More or less this is exactly how operating system assign tasks to processors.
Generally, the system can run 4 (having quad-core) different processes at a time. I mean without interrupting processes to let others use "a bit" of processor power.
So why would we want to run ONE process and use resources of FOUR cores? Sometimes it's OK, but I prefer running FOUR processes.
Piotr Gabryjeluk
visit my blog
Post preview:
Close preview