True Multi-Core Optimization May Require Windows Rework
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.
|
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??? |
|
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? |
|
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
|
|
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. |
|
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. |
|
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. |
stuff on Hot Hardware
Loading...
Loading...
Loading...
