Multicore-Aware Applications

[Capmaster]

With multiple-core CPUs inching more and more towards mainstream, I thought it would be interesting to test a few of them on my multi-core PC. I already knew that many video apps are multi-aware, so I knew the power wouldn't be wasted for me before I bought it. But I was curious as to just how they all utilized the extra capability, and also how some mainstream non-video apps stacked up.

I also wanted to share my results because several people have asked about multi-core CPUs in this forum. Maybe this little exercise will help shed some light on it.

I had mistakenly thought that since Windows was multi-aware, all apps run within it were also. I based this upon observing the CPU load during an Office Pro installation running on my dual-P-Pro Windows NT4 workstation many years ago. Both CPUs were fully utilized.

I was wrong. There is a vast difference between common apps on how they utilize multiple cores. Having an overall multithreaded OS isn't enough, apparently. The apps themselves need to have the multithreading ability added to the code.

So today I ran several of my installed apps, trying to load down the CPU as much as possible. It wasn't always possible, like in the case of DVDShrink. I couldn't get any of the cores to show a load above idle when it was running. A few of even the video apps show such little loading, the percentages are likely inaccurate. But for a quick-and-dirty test it's adequate. I suppose that's a tribute to the CPU, but it didn't help me for this little exercise.

So I opened Windows Task Manager and did grabs while each was running. Some were borderline between multi- and single-core aware, but I made judgment calls and labeled an app "multi-aware" if more than one CPU seemed to rise above the idle loading. There were one or two apps that probably could have been called either way ....oh well.

So here's my summary of single-core and multi-core aware apps that I use regularly. Several of the non-video apps surprised me in that they were multithreaded nicely, and a big disappointment with Imageready, an Adobe sister app to Photoshop. It's also odd how some apps that are multithreaded make use of only two or three of the four available cores.



Here are the single-core-aware app CPU graphs:






And here are the multi-core-aware apps:





My conclusions: If you aren't doing video work, or from what I've read CAD/CAM or 3D rendering, the extra cores probably won't help you much. The same is true of gaming, according to the "expert" enthusiast PC web sites. Anything above a dual-core CPU would likely be a waste of money. The exception is that if you like to have several apps running at once, my test results show that some single-core apps use core 2, some core 3 and come core 4. You could run all three without any performance hit to the other open apps.

If you are doing a fair amount of video work, or using some of the other apps that utilize several of the cores ....hold on to something!!! I'm not kidding. The apps open instantaneously, finish in a blink, and generally kick butt all OVER the place. The speed is very impressive!! It's sort of like running Windows 3.1 on a fast P4!

[Soopafresh]

How about doing some x264.exe tests ? ffmpeg would be interesting as well.

[Capmaster]

How about doing some x264.exe tests ? ffmpeg would be interesting as well.

I'll work on that today

[mysts]

It would be interesting to see how defraggers use the multicore.

[Capmaster]

It would be interesting to see how defraggers use the multicore.

Probably moot since they need so little CPU time, but lots of HD accesses. Here's what WinXP defragger shows:




@Soopafresh - Here are the two you wanted:

[JohnnyMalaria]

Having an overall multithreaded OS isn't enough, apparently. The apps themselves need to have the multithreading ability added to the code.

Nice post

There's more to it than being multithreaded, though.

For example, the current Microsoft software development platform is Microsoft Visual Studio .NET 2005 (ooh, two years ago - time for a new version!) One of the most common programming languages is C++. By default, any C++ programs written using this platform will be multithreaded.

Any applications that use DirectShow (for example) will always run the hard core multimedia stuff on a different thread than the user interface (the GUI).

Multithreading is advantageous even on a single CPU system since it allows the programmer to have separate threads dedicated to specific needs - e.g., monitoring the transport state of a DV device (play, record, rewind etc).

One of our programs, for example, typically runs with 14 threads - even though we haven't programmed it that way (i.e., many of those threads are created by the OS automatically). One a single CPU system, it will easily peg out at nearly max CPU use when pushed - on a dual core, it doesn't go much above 50%.

This is because all of the encoding/decoding happens in one thread - all the user interface stuff, the displaying of video, rendering of audio etc happen on different threads.

To take full advantage of the second core, we have to deliberately split the encoder (for example) into two threads that process, say, one half of the video frame each.

Nearly all modern applications will benefit from running on a multiple CPU platform - even if only to allow the OS to get around a stubborn application that, on a single CPU, would make the whole system become unresponsive.

[Capmaster]

@JohnnyMalaria - Thanks. You obviously know more about it than I do ....wayyyy over my head The deepest I got into programming was Rocky Mountain Basic and Fortran ...a long time ago, and some more recent Visual Basic (gasp - ver. 5)

[ahhaa]

This is an important thread when related to the cost of upgrading; thanks guys & HNY!

[rallynavvie]

Nearly all modern applications will benefit from running on a multiple CPU platform - even if only to allow the OS to get around a stubborn application that, on a single CPU, would make the whole system become unresponsive.

That's one of biggest niceties of SMP is the ability to put most, if not all, the Windows tasks on one processor and have a dedicated CPU for whatever app is currently active. Now your only issue is hard drive access between the two which can be somewhat solved by having one drive dedicated to the OS and perhaps another speedy drive dedicated to the applications. Of course then you're utilizing slightly more system resources to access multiple drives, unless they were SCSI I suppose.