shouldn't dual processors be handled by the OS?

I've heard many times "there arent many applications that supports dual core feature".. but if you start 2 process at the same time.. i guess an OS that supports dual cores, runs each process in a separate core and i guess that applies to process and aplications.. shouldn't be the OS the one who optimizes the process and applications to use correctly the dual core feature instead of the application? In terms of low level programming this should be done by the OS and not by applications. am i wrong? discuss

 

Yes, you are right. So it helps if you multitask. But if you just run a game (single process) and nothing serious in the background, it won't help you, unless the game supports dual core.

 

Nope, programming the applications to make use of multi cores is more efficient. The OS cannot do efficient splitting of one app over 2 cores. What the OS does well is just run some apps on one, others on the second. XP even allows an affinity setting. So you can force XP to prefer one of the cores for certain apps. This comes in handy when you have something important running in the background and don't want it delayed by other stuff running. So you dedicate a core to it and let everything else use the other core ... although in the case of Yonah, this is not entirely true just because of the bus design, other apps will ALWAYS cause a bit of a slow down to each others.

 

Hi Faire,

The problem is in single core/single task programming. There are just a few applications that fully use dual core advantages. I still didn't hear that any game supports it. And it is a huge difference in program code for multicore processing - it is much, much harder to program a multicore app. But it is only a matter of time when the tools will help programmers in achieving such levels of programming. As dr_st said - games are SINGLE PROCESS (task) at the moment - so no real gain yet. OS can help you with balancing the usage of the cores (either in multitasking or dualcore usage), but not in making the single process into multiprocess....

Cheers,

 

Visualizing the limits of OS driven multi-tasking is easy if you think of how you would go and write simple codes (Fortran, C++) in which do_loops are used. Ideally each iteration of the loop can be sent to a different processor, but, nested loops, would often left untouched by the OS because there may be dependencies between the loop's outcomes. However the programmer can signal the OS that some loops are safe to be multi-threated and so on...

I found the following link useful to discuss recent developments in writting applications multi-core ready, http://www.intel.com/technology/magazine/research/speculative-threading-1205.htm

Enjoy!

 

Btw, what do you think would be easier to accomplish, to rewrite a code to exploit 64bit features or to rewrite it to use multi-cores?

 

The first. It is a completely new logic - multicore programming. At least as far as I know about that.

 

It's not "process" (which implies an address space within which there are one or more threads), but "thread" - an independently schedulable set of instructions. The OS will farm out threads to the dual core or other multi-processor architecture. As you point out, most applications today are single-threaded. But the technology for programming multi-threaded applications has been around for ages, whether in the form of a programming language (Ada, occam, Java), or a library (POSIX, win threads, linux threads).

The language-based solutions aren't much, much harder than programming single-threaded applications, because they're designed to address the issue from the ground up. It's just a matter of how well-designed they are, and learning to use them.

- Ed

 

Hi Ed,

If you are referring to the last line - I guess we are both right. SMP or symetric multiprocessing was the thing I was talking about. The popular word that many people use is "multithreading". Check here:
http://www.short-media.com/review.php?r=261
In fact I also think of task when I say "process" although that might be the same in a way. (You are right about memory allocation and I would add - context). One task can have many threads. Each core can handle many tasks with many threads each. But I guess I was thinking of running the completely different singlethreaded tasks on each core. Point taken - games are not multithreaded - and run as a single task inside the single process, thus not using the dual core advatages (multithreading or symetric multiprocessing) to the full.

So I guess if you write the proper multithreading app - it would run much faster on a dual core. Unfortunately dualcore today spends much more time in singlethread singlecore multitasking - because many apps just don't see the other core. Multithreading on dualcore happens only if OS and app supports TLP - thread level parallelism (XP does). There is also some load balance logic built in hardware - and apps that don't use TLP also run a bit faster on dualcores, but way slower than multithreaded.

Don't get me wrong - I would really like that multicore computers run multithread apps 100% of the time - but today it is just not the case. Although you are right again about the known multithreading programming techiques, I still believe that it is much harder to do a such application. Multythreaded apps started to live on PCs in the era of Windows 95 and Windows NT. Although Multithreaded programming can be very useful it sometimes produces nothing but headaches and poor performance with logical errors that are very hard to debug. Deadlocks, starvation, overhead... A trap for newbie programmers. Once you decide to make a multithread app (and you have a justified cause), you start to worry about many things. For example - a simple function with arguments. In singlethread - no problem - pass arguments take the result. In multithread - you must check how it will behave surrounded by multiple threads - how to pass arguments - what to get back and when. And the biggest issue - what thread can call it and when - because all threads run simuntaneously, right? Many people think - oh yes it is easy - especially if I have the already working function in a singlethread app. Oh, I have seen so many great failures. That is probably most common mistake that even very good programmers do.

I will quote one line that illustrates the complexity of such "trivial" problem:

And to say it again - we are talking about a function. Simple, well known, trivial, easy function.

Here you can find aditional info and a simple program written as a singlethread app. It can be "transformed" to use multithreading advantages. Check what happened.

I really believe you are a good programmer - and perhaps you find multithreading easy. It is the future, it is better. It is faster and much more clever. But as the above link states, this is probably the truth:

This word "updated" means much more than many people think. Especially the debugging part.

Cheers, and happy programming

Ivan