multiple core CPU and threads

[Red Squirrel]

By default, do multithreaded apps in windows/linux take advantage of multiple cores? So if I run an app that has 2 threads, will they balance out on separate cores (assuming they're equally used at that point) Or do apps have to be written specifically for this?

[valikac]

Recent operating systems know about multicore technology. Add breakpoints inside different threads and you should see concurrency (multicore or multiprocessor workstation).

valikac

[Arjay]

On Windows they do - don't know about the other OS.

[JVene]

There's an auto-load behavior, like Arjay said, and there's some interesting details besides.

There can be an affinity assigned to a processor, but I don't recall that threads can do that - the entire process, in Windows.

Threads have a priority, so the 'balance' depends on priority.

People seem to think a single thread runs in one CPU, but that's not actually true. If your machine were performing only one thread of activity, and it's a dual or more, you'll witness each of the CPU's doing 100 / CoreCount of the work (2 will share 50%, 4 will share 25%), give or take a few percent.

This is because when the OS scheduler slices and subsequently reschedules a thread, it has no reason to choose any particular processor - a thread can bounce around at any time. It won't be scheduled into more than one CPU at once, but as the OS slices time, the thread can spend, on average, enough time 'in' each CPU (actually, it's more accurate to say that each CPU spends enough time on the thread) - that it balances out to an average.

The more threads running, the more 'spread out' this performance is. Only if you assign processor affinity is this changed.

However, if your threads have different priorities, then it balances in favor of the higher priority threads.

An interesting side note is what is now perhaps obsolete technology that I think will return some day - hyper-threading (though I think it will be on an entirely new level with a different name).

There are multiple execution units in modern CPU's - it might seem like a parallel design, and in a way it is. Our CPU's are designed to execute multiple instructions in a stream of instructions, when those instructions are not interdependent. On average, though, there's some occasion when jumps or dependent instructions come up, that it's recognizable that only 1 or 2 execution units can be occupied. In 'standard' CPU's, this means an execution unit or two might go idle for that clock tick.

With hyperthread, the CPU can accept the next instruction of a waiting thread - and schedule unused execution units to act upon it, simulating, for a short time, a dual CPU core.

It doesn't come up often, but about %15 of the time (give or take considerably), it works out such that hyper-threading did give gains (sometimes).

Someday I think our interest in cores will change - we'll have a rank of execution units and the OS will present a collection of threads. The CPU will then dynamically choose how to schedule those threads among the execution units, such that at some times it may act like an 8 core CPU, other times a 6 core, other times a 4 core.....

I have a longer post on the notion around here (two, actually).

[Arjay]

In addition to what JVene mentioned, the OS thread scheduler will assign the CPU on which the thread runs. In general, once the thread is assigned to a CPU it generally will continue to run on that same CPU for the life of the thread. This sort of scheduling task is the sort of thing best handled by the scheduler and can change from OS version to OS version.

[jesschen]

I don't think u need to consider the dual-core problem when u r programming. because your programs in linux/windows are pretty high level application programs. everything about dual-core sync will be done by OS or driver, not by your code.

only when you r programming under special embedded system. that OS provides you the functions (like API) to control the processing of using/sync... different processors (for instance, dual-core).

[forever.zet]

I guess in more general case apps have to be written for multicore processors to use all cores efficiently.

Here's an article about TPL library which is going to help in distributing workload evenly between all available cores:
http://msdn.microsoft.com/msdnmag/issues/07/10/futures/default.aspx?loc=ren

[Zaccheus]

Yes, and it can be very easy to do.

An example would be a ray-tracing application which uses a number of threads to calculate the lines of an image - one thread per core, each thread would do a line or even a pixel.