An OS that multicores software???

J

JLGatsby

Weaksauce
Joined
Sep 6, 2005
Messages
89
The biggest problem with multicore processing is that you need the software to be multicore coded in order for it to take advantage of the proc.

Why can't they create an OS that automatically "converts" or "splits up" the processes of a single core coded program so that all the cores in a processor can use it?

What is going to happen when we have 80 core procs? We need something like this.
 
silent-circuit said:
...no. We need programmers to start making their stuff thread out.
Click to expand...

Yeah, but in reality, can we rely on EVERY software company to do this?

Also, if the program is more complex (in terms of code), that might cause more buggy issues.
 
The problem is that different program react differently to multi threading. How would the OS know this, how would it split its work load?

eg

I encode video then it simply splits the work load between the cores, if I play a game then it can not be split like this becuase its time limited, what if the AI thread does not finish in time, the game will either crash or you will get computer controlled characters out of sync.

Its very very hard, and unless some one comes up with 1 equation that can explain how to multi thread all code no OS will be able to do it.
 
I don't think it's feasible for the OS to do this; multithreading isn't easy as that. It can be hard enough to implement when you've got the source code in front of you, but the OS doesn't know what programs are trying to achieve at all Keeping track of dependencies between the multiple threads would be a huge task, or you'd get constant race conditions.

Even if it were trying to multithread video encoding (something that's comparatively easy to multithread as a programmer), it would have to be able to somehow identify the compiled code that was doing the video encoding itself and cause that to run in multiple threads on different parts of the file, but maintain the other parts of the application in a single thread, while keeping all threads in a state that looked like they were a single-threaded program as the processor intended, and coordinate the worker threads to all finish before it gave the correct signal to the main thread. If it gets any of this wrong, the UI might start running in multiple threads and not take input correctly, or it might report that the file was finished converting when it wasn't, it would crash because it tried to read memory that was being simultaneously modified by another thread and got invalid data, etc. Programmers who understand the task need to do it, it's an impossible task for the OS to extrapolate multiple threads from compiled code.
 
At the present time: Certainly not. It's a hot research topic because it's an incredibly different problem. Things can't just be arbitrarily split. And lots of things can't be split up period.

For instance, take the following loop:
Code: 
int a = 1;
for(i=10; i<1000; ++i) {
  a += i;
  std::cout << a << std::endl;
}
Now, in this example, a good compiler could technically recalculate it since it's all constants, but pretend it used function arguments or something and couldn't. Seems like a great candidate for parallelization, right? Super-long loop that does the same thing over and over. Except that each iteration depends on the state of the system after the previous iteration, so it can't do anything.

Parallel programming is hard specifically because it requires an entirely new mindset. Existing single-threaded programs can't/shouldn't be/are incredibly difficult to transform directly to "multi-threaded" apps; a rewrite of the core algorithms is what usually has to occur.
 
When it gets to the point that pretty much the entire market is dual core or above, then you'll start to see multi threading be common place. Xp and Vista does do a decent job managing both cores though. If you keep an eye on the task manager, both cores get used. Even when your running a program that is not multi threaded, one core will be max used and the other will be 20-40%. A good portion of threads are being ran on the 2nd line from the OS etc.
 
Parallelization is a big enough problem that Intel just gave my school $20 million to solve it! :p
 
I work on embedded real-time systems for a living. Multi-threaded programming is doubly-hard because you have to spend extra time designing, and you have to spend extra effort tracking down bugs.

See the link above to get an idea; single-threaded programs are cake to design (you don't have to design separate processes and segregate/protect data), and painless to debug because there's just one thread. Programmers have gotten a break because processor makers steadily increased their instructions per clock (ICP) throughout the 80s and 90s. But now, we're hitting the wall on complexity as you add more pipelines, so multi-core is the only way left to go.

In addition, there is this: multiple threads can be done easily for certain types of code, but for others there's almost no benefit. In other words, even if programmers learn threads, they won't be able to solve every problem out there with more threads.
 
The thing is threading isn't the problem, its knowing how to solve the problem with parallel parts, However, the average desktop these days is running many different applications simultaneously anyway, so multiple cores helps without well threaded software.
 
Now what about the hardware level?

I mean, what if single-threaded applications could run on all cores or processors due to special hardware that would "pool" those cores or processors into one "super-processor"? I'm not saying it's a great idea nor am I condemning it.

Also, wasn't AMD working on something like this not too long ago? Whatever happened to that?
 
One of the biggest issues is that you can't split a process that depends on itself. Answers are expected by the programmer in A->B->C->D order. If you cut the tasks up, they may come out B->D->C->A. Very bad.

Processors however already do this, with some degree of effectiveness. Google speculative execution and branch prediction. They more or less guess what path the program will take and continue to execute, even while the first instruction is still computing.
 
GushpinBob said:
Now what about the hardware level?

I mean, what if single-threaded applications could run on all cores or processors due to special hardware that would "pool" those cores or processors into one "super-processor"? I'm not saying it's a great idea nor am I condemning it.
Click to expand...

They already do this. It's called out-of-order execution, and it was introduced to the Intel world with the Pentium Pro (yes, it's that old).

The basics: when instructions are loaded into the processor, it checks for dependencies. For example:

B = 1
A = B + 1
C = 2
A = A + 1

The above four instructions have a dependency: the second instruction cannot execute before the first is complete, and the fourth instruction cannot execute until the second is complete But imagine that our processor has the hardware to execute two instructions at the same time - if we wait for this dependency to be satisfied, then the extra execution pipeline is sitting idle, and it takes us four cycles to execute four instructions.

Enter instruction re-ordering. Since instruction three does not have any dependencies, it is executed out-of-order simultaneously with instruction one (one goes to each execution unit). That leaves us these instructions:

A = B + 1

A = A + 1

These, unfortunately, must execute in-order, but the processor can meanwhile fetch even more instructions to fill the execution units.

Thus, you have effectively increased the speed of execution of this single-threaded code: what would have taken four clock cycles to execute now takes three, and when you have fewer dependencies in the code, this improvement can be much larger.

Go look up out-of-order execution for more information:

http://en.wikipedia.org/wiki/Out-of-order_execution

The problem with out-of-order execution is that, as you add more decode/dispatch pipelines, the complexity of the chip increases exponentially. Every new pipeline has to have access to registers, requires that you double the rename registers, and complicates other feedback logic. That is why we didn't see a major increase in number of instructions per-cycle for many years, until the Core 2 was released. This is also why we see the move toward multiple cores, because multiple simple cores are cheaper to make than one more complex core.
 
You must log in or register to reply here.
Back
Top