Clarification on Multithreaded vs. SMP capable apps..

[dawks]

I was just reading this article on AMD's new Dual Core chips, and I am still confused about what is defined as an multiprocessor capable program..

The article says there are limited number of multithreaded applications on the market, but infact, most applications today are multithreaded.. Apache, Internet Explorer, ICQ, MSN, Winamp, Firefox, Half Life, Quake3, Photoshop, Virtual PC, Microsoft Word..

On the other hand, there are a limited number of SMP capable applications.. 3D Studio Max, Photoshop.. mostly highend specialized software..

Multithreaded applications could use two processors at the same time though, not? The NT kernel is capable of scheduling two threads from a multithread application to two different processors? So Internet Explorer could potentially use both processors if needed?

What is different in an SMP capable application if the above case is true? Quake 3 had SMP capablities, but they needed to be enabled manually. (It was broken with a patch at some point and I dont think its been fixed since)

 

[bsobel]

Why many of those apps may use multiple threads to perform some actions, few of them actually have multiple scheaduable threads available to run at the same time. Think about IE, it requests a page, waits, renders. Not much to do to in parrallel. Running a dual core chip isn't going to make IE faster excepct that other actions occuring on the system (say Windows Media player) can be scheduled on the other CPU. Making both tasks smoother.

Now applications that can evenly distribute their work load over a number of CPU's (such as a rendering application, data base server, web server, etc) are going to see a better gain from the dual core chips.

Bill

 

[oog]

it's my understanding that threads from a single process are usually scheduled to the same processor as this often makes inter-thread communication more efficient. the problem is that you don't end up taking advantage of the multiple processors. i know that things like MSVC++ benefit from multiple processors but that is because it kicks of separate processes for each compilation task.

 

[bsobel]

Originally posted by: oog
it's my understanding that threads from a single process are usually scheduled to the same processor as this often makes inter-thread communication more efficient. the problem is that you don't end up taking advantage of the multiple processors. i know that things like MSVC++ benefit from multiple processors but that is because it kicks of separate processes for each compilation task.

Most schedulers will move a thread to a seperate CPU, the performance gain far outweighs the overhead.

 

[piasabird]

With SMP you can run one OS on each processor and switch back and forth or just split the work up between 2 processors. The problem is how is AMD going to implement the 2 processors. Will some emulation manage the multiprocessing or will the OS mange it or will applications manage the resources?

There could be an SMP application or emulation you load on top of the OS.

 

[dawks]

Originally posted by: piasabird
With SMP you can run one OS on each processor and switch back and forth or just split the work up between 2 processors. The problem is how is AMD going to implement the 2 processors. Will some emulation manage the multiprocessing or will the OS mange it or will applications manage the resources?

There could be an SMP application or emulation you load on top of the OS.

There may be some ciruitry on the chip that will handle some of the addressing, but for the most part, at least in my understanding, a single dual core chip will act the same as having two separate physical processors as far as the kernel and programs are concerned.

I think nForce4 based boards can handle these new dualcore chips already? or at least one model of them.. maybe I'm wrong..

 

[Nothinman]

The problem is how is AMD going to implement the 2 processors. Will some emulation manage the multiprocessing or will the OS mange it or will applications manage the resources?

It's not a problem at all, putting the process management on the chip would be incredibly stupid. There's no way the CPU can know enough about the running processes to make intelligent decisions about what to schedule where.

Multithreaded applications could use two processors at the same time though, not? The NT kernel is capable of scheduling two threads from a multithread application to two different processors? So Internet Explorer could potentially use both processors if needed?

What is different in an SMP capable application if the above case is true? Quake 3 had SMP capablities, but they needed to be enabled manually. (It was broken with a patch at some point and I dont think its been fixed since)

A lot of Windows apps are multithreaded just to give the UI it's own thread so that the window can be redrawn whenver necessary regardless of the state of the rest of the processing. Obviously using threads for this results in no speed improvement in the app, but it does make it seem more responsive and makes people less likely to think it's hung when it's really not.

And an SMP capable program doesn't need to use threads to use multiple CPUs, it could launch full processes and use another type of IPC to manage the children.

 

[ribbon13]

Well, a i hope a lot more people getting into distributed computer with thier spare core!
At least your media player / bittorrent client can make use of the other cpu.

I can't wait to have two Italy's in my rig.

 

[Nothinman]

At least your media player / bittorrent client can make use of the other cpu.

Not really. I have virtually no CPU usage when playing DivX/MP3 AVIs now, how would multithreading that help me any? And BitTorrent is hugely I/O limited, it does a lot of checksumming but the datasets are so small that it uses virtually no CPU time currenlty, the only time I could see it becoming CPU bound is if you passing data at 100Mb/s or faster.

Encoding video could benefit, but I think it would be extremely difficult to multithread for things like DivX that are so dependent on previous frames for the current frame. One easy way to get concurrency is to encode the audio and the video in sepeate threads or processes, but apps like transcode already do that.

 

[kylef]

Originally posted by: Nothinman

At least your media player / bittorrent client can make use of the other cpu.

Not really. I have virtually no CPU usage when playing DivX/MP3 AVIs now, how would multithreading that help me any? And BitTorrent is hugely I/O limited, it does a lot of checksumming but the datasets are so small that it uses virtually no CPU time currenlty, the only time I could see it becoming CPU bound is if you passing data at 100Mb/s or faster.

You make a good point. However, I think there is still a win in your case because each core can dispatch interrupts independently. You're less likely to see weird behavior like your USB mouse cursor getting jerky during periods of heavy disk I/O (caused by the USB interrupt being lower in priority than the disk controller's interrupt).

With a second processor to dispatch interrupts, lower priority interrupts won't get starved as easily, making your system seem more responsive overall. This may only happen if, say for instance an app has had a lot of its memory paged to disk and you switch to the app suddenly, triggering a flurry of page faults; on a single processor system, this flurry of page faults can cause things like music playing in the background to skip because of this interrupt starvation problem.

In my case, I frequently perform large builds (compiles) that hit both the CPU and the disk very heavily, so an extra CPU not only speeds up the build (which is SMP-aware), but also makes the system respond much better while the build runs in the background.

 

[ribbon13]

Given my Azureus is often a gigabit hop away from on a OC3 or better, its good for me.

 

[Nothinman]

You make a good point. However, I think there is still a win in your case because each core can dispatch interrupts independently. You're less likely to see weird behavior like your USB mouse cursor getting jerky during periods of heavy disk I/O (caused by the USB interrupt being lower in priority than the disk controller's interrupt).

That's true, but IME it takes a lot for that to happen, at least for me on Linux.

In my case, I frequently perform large builds (compiles) that hit both the CPU and the disk very heavily, so an extra CPU not only speeds up the build (which is SMP-aware), but also makes the system respond much better while the build runs in the background.

I agree, I refuse to run a non-SMP desktop at home even though the CPUs by themselves are currently pretty slow compared to what's available today.

Given my Azureus is often a gigabit hop away from on a OC3 or better, its good for me.

If that's true, you're in an extreme minority. Probably an smaller minority than Linux or Mac users have ever been.

 

[VirtualLarry]

Originally posted by: kylef
You make a good point. However, I think there is still a win in your case because each core can dispatch interrupts independently. You're less likely to see weird behavior like your USB mouse cursor getting jerky during periods of heavy disk I/O (caused by the USB interrupt being lower in priority than the disk controller's interrupt).

I have that happen often. It's rather annoying, especially when you are in the middle of doing some drag-n-drop filesystem operations in Explorer, and end up moving something into the wrong folder because your mouse-movement glitched. :|

Worse yet, on my mobo (MSI KT4V-L), the default USB 2.0 EHCI controller's IRQ is the same as my Promise IDE controller's IRQ (because slot 4 is the only PCI slot that doesn't share IRQs, except for the onboard USB EHCI controller. Sigh.) If only PCI cards offered a jumper setting for selecting between INTA-INTD, I would be all set. I could put my AGP and network and disk controllers all on their own IRQs, and share IRQs for everything else, if needed. Right now, I think that my AGP two other "multimedia" devices are sharing IRQs. In these sorts of situations, is it any wonder that I prefer using PS/2 mice for gaming purposes?

Originally posted by: kylef
With a second processor to dispatch interrupts, lower priority interrupts won't get starved as easily, making your system seem more responsive overall. This may only happen if, say for instance an app has had a lot of its memory paged to disk and you switch to the app suddenly, triggering a flurry of page faults; on a single processor system, this flurry of page faults can cause things like music playing in the background to skip because of this interrupt starvation problem.

What is the default processor affinity on a DP system for interrupt handlers? Do they mostly all get scheduled to one "master" CPU, or on an as-available basis? (I guess that would depend on how the APIC is programmed, and the mobo's IRQ-routing "stuff".) Just wondering if there was a generic default in Windows' or something.

 

[VirtualLarry]

Originally posted by: ribbon13
Given my Azureus is often a gigabit hop away from on a OC3 or better, its good for me.

No wonder you use an SSD. 😛

 

[kylef]

Originally posted by: VirtualLarry
What is the default processor affinity on a DP system for interrupt handlers? Do they mostly all get scheduled to one "master" CPU, or on an as-available basis? (I guess that would depend on how the APIC is programmed, and the mobo's IRQ-routing "stuff".) Just wondering if there was a generic default in Windows' or something.

Windows programs the I/O APIC on x86 and x64 SMP systems to interrupt the processor currently running at the lowest kernel IRQL. Whichever processor this happens to be will handle the interrupt.

I believe you can actually change this default behavior using the "IntFilter" utility in the Windows Resource kit if you want only one processor to handle interrupts. Although, I'm not entirely certain why anyone other than hardware driver writers would ever care to do this...