True Multi-Core Optimization May Require Windows Rework

rated by 0 users
This post has 6 Replies | 0 Followers

Top 10 Contributor
Posts 26,217
Points 1,187,235
Joined: Sep 2007
ForumsAdministrator
News Posted: Mon, Mar 22 2010 12:44 PM
A key Microsoft kernel architect, David Probert, has come out with a surprising statement regarding Windows' ability to harness multiple cores. While Windows has taken advantage of multicore technology for over a decade, Probert notes that users rarely see the performance that they should. "Why should you ever, with all this parallel hardware, ever be waiting for your computer?" Probert asked in a presentation last week at the Universal Parallel Computing Research Center in Champaign-Urbana.

Each successive OS release from Microsoft has improved multicore scaling but bottlenecks regularly occur as multiple applications jockey for position. Priority scheduling helps a certain amount, but it's not transparent to the end user or guaranteed to improve performance. One of the reasons for poor multicore performance is that the operating system doesn't understand which programs the user wants prioritized (and which he doesn't). If the OS is busy running a virus scan while the user is busy opening documents or copying files, system responsiveness drops like a rock no matter how many cores you have.


Coming soon to a desktop near you!

We've known since Day 1 of the multicore era that parallel programming was much more difficult than conventional single-core coding. The general assumption back then was that new compilers and methodologies would appear and solve the problem in a few years. Five years later, the situation is generally better, but no one has discovered a magic key that unlocks parallel scalability. Part of the problem here is that while we may be five years into the multicore era, programmers are still searching for ways to extract greater parallelism from software with its roots in serial execution. Instead of continuing to hammer a square peg into a round hole, Probert suggests another sort of solution.

Probert argues that the best way to solve the problem is to build a new OS from the ground up using a different set of assumptions. If the OS 'knew' it had multiple cores at its disposal by default, programs could be assigned to specific processors and the OS would no longer have to juggle the various cores to ensure individual programs were being handled properly. This switching takes time; in some cases it's currently more efficient to keep code executing on a single CPU core rather than spin it off to another.

Unfortunately, we aren't going to see an OS built like this anytime soon. Probert views don't reflect any work going on at Microsoft and his ideas aren't universally accepted across the Windows architecture team. It's also difficult to model his theory; modern OS's by their very definition don't include the necessary capabilities to do so. Part of what makes Probert's ideas intriguing is that CPU core counts are growing much faster than consumer software that can take advantage of them. Quad-core desktops are available at Dell and HP for under $500; AMD has enthusiast six-core processors on the way. Intel does technically have a six-core chip of its own, but the price tag puts it out of reach for all but the most enthusiastic (and loaded) buyers. It may not happen for another few years, but sooner or later octal-core processors are going to show up in regular desktops. Based on what we've seen the past few years it may take a radically different approach to programming to effectively harness that much parallel hardware on a day-to-day basis.
  • | Post Points: 65
Not Ranked
Posts 65
Points 800
Joined: Jun 2008
dizowned replied on Mon, Mar 22 2010 1:48 PM

You know what this guy hits the nail right on the head and as a programmer I'm inclined to agree with him.

Trying to do multicore programming with the use of how Threading works is somewhat annoying to me, and I rarely see a lot of speed up, at least what I think I should see. If the OS were more efficient at handling threading whether it be on a per program or per task it would be a glorious day. I also happen to love the idea of rewriting windows from the ground up, everyone and there mother has been asking for this since 2000, but its nothing but rehash after rehash...I mean why are we paying 200 bucks every 3-4 years for the same ole crap just a different flavor???

It's not custom unless your the only one who can boot it.

  • | Post Points: 5
Not Ranked
Posts 25
Points 305
Joined: Mar 2010
bbdl replied on Mon, Mar 22 2010 2:23 PM

I agree from a user standpoint dizowned. My processor is of course a dual core, and I guess it operates OK. I also was doing some research on things this weekend, and figured out that I can prioritize specifically some programs to a core. So I guess that would be more efficient, with a Dual core cpu it is not as big of a thing though as it would be to what coming onto the market.

Intel's new six core CPU is amazing to me, and from what I understand we may have eight core processors by the end of this year. So this seems to be all on the software providers to me. The hardware is there, but in general at least in many cases the software either see's a rudimentary increase in operational power.

I think if the software knew by default how to manage a CPU, or at least gave you open options on install or something it would be better considerably than it is now.

Maybe since you are a programmer you can explain this holding back of the software industry from direct usage of the hardware that is now common?

  • | Post Points: 20
Top 500 Contributor
Posts 318
Points 3,180
Joined: Feb 2010
Location: Louisiana
la_guy_10 replied on Mon, Mar 22 2010 6:35 PM

The way I understood it was say on a quad core processor (core 1 handles Gaming), (core 2 handles ripping a DVD), (Core 3 handles virus scan), and( core 4 encodes a DVD). Now this is worst case scenario of taxing a processor but I though each core handled its given task to the best of its ability. I agree the problem seems to lie in the coding as programs are not optimized properly, games included.

  • | Post Points: 20
Top 100 Contributor
Posts 862
Points 11,010
Joined: Apr 2008
RyuGTX replied on Mon, Mar 22 2010 6:38 PM

I'm not a programmer, but I read this article a a while back. I know it is an old article but it might still apply today. Even though this article is about games, it should be no different from other software.

http://www.anandtech.com/tradeshows/showdoc.aspx?i=2868

 

If you think you can’t do something, you’ll never be able to do it. No matter how easy it is.
  • | Post Points: 5
Top 75 Contributor
Posts 1,809
Points 18,105
Joined: May 2009
Location: Waikiki

This has always been an issue with the multi core processors.

Some of my DCC programs are able to take advantage of these CPU's. Yet it kinda turns out to be a Plug and Pray aspect of using these.

I would hope that if anything, they would come out with a program that allows us to utilize these across all platforms.

That is why I have been waiting for the 8cores. Because I would like them to use all 8, inside the programs when you go to render scenes. Yet it kinda seems like it uses them whenever they feel like it.

Intel Core i7-875K Quad
Asetek 510LC 120MM
4GB Kingston Hyper-X DDR-3
ASUS P7P55D-E Pro
CyberPower 800 PSU
Kingston 64GB SSD 
2 Hitachi 1-TB HDD'S
FirePro V8800
8X Blu-Ray DVD±R/±RW
HPw2207 22" LCD
Cintiq 21UX
CoolerMaster 690II Advance
Win 7 Pro 64 bit
Special thanks to HotHardware.com!
  • | Post Points: 5
Top 500 Contributor
Posts 90
Points 945
Joined: Jan 2010
Location: Calgary, AB
JoelB replied on Tue, Mar 23 2010 10:23 AM

As a programmer, I wholeheartedly agree with you. Multi-threaded programming is a pretty tricky beast. It isn't just a matter of 'splitting things up' - it's a matter of splitting things up, still having them be able to talk to each other, and not having the whole program go down in a horrible deadlocked situation (which is surprisingly easy to do, yet tricky to spot). Perhaps it just comes down to us programmers being better trained at this sort of thing.

I think it should be very interesting to see how Id's Rage engine handles this. From my understanding of the architecture, it is meant to scale very well for multiple cores/threads.

  • | Post Points: 5
Page 1 of 1 (7 items) | RSS