Multi Core CPU and the future

[Rubycon]

Arty here

So if single applications in the future can utilize the multi core cpu's more efficiently does this mean the multitasking ability of multiple core/socket systems could be reduced? Or will future OS/Software have the ability to tune this?

 

[YoungGun21]

No it means that programs will truly begin to be made for dual core CPUs and ultimately making programs run almost twice as fast.

 

[Rubycon]

Originally posted by: YoungGun21
No it means that programs will truly begin to be made for dual core CPUs and ultimately making programs run almost twice as fast.

Yes but remember what makes an SMP system superior to a uniprocessor. If all applications can use both cores 100% a single app can hog everything and cause it to become sluggish. Granted it (in theory) could be finished in half the time but operations that take a long time would make the machine crawl which is something that is nonexistant in today's SMP environment.

 

[Lonyo]

Set affinity?
OS scheduler?

 

[Rubycon]

Originally posted by: Lonyo
Set affinity?
OS scheduler?

That's like using keywords or tarpitting to stop enterprise users from going to dating sites on the job. 😛 Fields can be harvested with a sickle but you need a lot of hands!

Hopefully the OS of the future will handle this intelligently but I'm not counting on it!

 

[xtknight]

It can really only be a good thing once apps become multi-threaded. When you have two single-threaded applications, ideally one will execute on core 1 and the other on core 2 (Scenario 1). Now say you multi-thread both programs. When only one is running at a given time, it can take advantage of both cores alone (Scenario 2). Now if you start the other program, there will be four total threads. The difference is, each program now has two threads, but each is doing half the work as the one thread in the first scenario. Now since either of the threads can run on either core, you can still yield the same amount of work. When you want one app to run twice as fast, you can kill the other app. If you killed the other app when app1 was single-threaded, the second core would just be left unused (Scenario 0).

Scenario 0: 50% total processing time to app 1, 50% wasted
-Core 1: app1 [thread1]
-Core 2: wasted

Scenario 1: 50% total processing time to each app
-Core 1: app1 [thread1]
-Core 2: app2 [thread1]

Scenario 2: 100% total processing time to app 1
-Core 1: smpAPP1 [thread1]
-Core 2: smpAPP1 [thread2]

Scenario 3: 50% total processing time to each app. Same amount of work finished as Scenario 1 with the added flexibility of running one app at once and yielding twice the work for that one app (Scenario 2).
-Core 1: smpAPP1 [thread1] / smpAPP2 [thread1]
-Core 2: smpAPP1 [thread2] / smpAPP2 [thread2]
OR
-Core 1: smpAPP1 [thread1] / smpAPP1 [thread2]
-Core 2: smpAPP2 [thread1] / smpAPP2 [thread2]

So there's really no disadvantage to multi-threading your applications. All of the above assumes the priority of both applications is equal (default: Normal), and that the OS's scheduler is smart enough to assign threads like mentioned above.

Edit: By the way, when you set an affinity to a single-threaded app to CPU0+CPU1 that does not mean both cores can execute one thread at once. That is impossible. You are only giving permission to the scheduler to assign that thread to either CPU0 or CPU1. Of course, if you have one SMP app and one uni app, the SMP app's two threads would steal some of the thunder, so to say. It's all up to the scheduler though and I don't know what Windows would do in that situation.

 

[DaveSimmons]

Most applications can't be optimized for multi core much or at all. For example, your web browser spends most of the time for a new page waiting on a response from the server.

All the optimizing in the world won't make the new page load more than a tiny bit faster since the bottleneck is the server.

Email, web browsing, word processing, many other apps use some multi-threading now, but the threads just sleep while waiting for something to happen so they don't load the multiple cores.

So yes, but only if you're running PhotoShop with fancy filters, playing a 3D game or rendering a movie.

Even then future software will probably have options for the max number of threads to spawn for CPU-intensive tasks.

 

[Rubycon]

Originally posted by: DaveSimmons
Most applications can't be optimized for multi core much or at all. For example, your web browser spends most of the time for a new page waiting on a response from the server.

All the optimizing in the world won't make the new page load more than a tiny bit faster since the bottleneck is the server.

Email, web browsing, word processing, many other apps use some multi-threading now, but the threads just sleep while waiting for something to happen so they don't load the multiple cores.

So yes, but only if you're running PhotoShop with fancy filters, playing a 3D game or rendering a movie.

Even then future software will probably have options for the max number of threads to spawn for CPU-intensive tasks.

For custom encoding to work across an array of CPU's would be very nice. The vendor has demonstrated this with a 9200 cpu cluster and it's impressive but so expensive only GW & Co. is interested. :Q

It's annoying to run a post process and see the util at 50% though. That will probably take forever to change. :frown:

 

[DaveSimmons]

Some programs like CuteFTP and Exact Audio Copy already have settings to control how much threading to do, and I expect many / most apps to add this when it's actually possible for them to saturate 2+ cores for extended periods.

Even 3D games like Oblivion can't saturate both cores more than part of the time, even for the P4 the 805D 2.66 GHz, so most end-user applications aren't going to need such options.