Windows and Linux Not Well Prepared For Multicore Chips

Mike Chapman points out this InfoWorld article, according to which you shouldn't immediately expect much in the way of performance gains from Windows 7 (or Linux) from eight-core chips that come out from Intel this year. "For systems going beyond quad-core chips, the performance may actually drop beyond quad-core chips. Why? Windows and Linux aren't designed for PCs beyond quad-core chips, and programmers are to blame for that. Developers still write programs for single-core chips and need the tools necessary to break up tasks over multiple cores. Problem? The development tools aren't available and research is only starting."

Comments

Adapt

[Dyinobal]

Give us a year maybe two.

Re:Adapt

[camperslo]

The programmers of Slashdot are ready for multiple cores and threads. There is no problem.

When performing a number of operations in parallel the key is to simply ignore the results of each operation.
For operations that would have used the result of another as input simply use what you think the result might be or what you wish it was.

The programmers of Slashdot already have the needed skills for such programming as the mental processes are the same ones that enable discussion of TFAs without reading them.

Re:Adapt

[David Gerard]

Three cores to run GNOME, one core to run Firefox.

Re:Adapt

[nmb3000]

To dumb your message down, CPU manufacturers act like book publishers [...]

What is this "books" crap? Pft, I remember when car analogies were good enough for everyone. Now you have to get all fancy. Let me try and explain it more clearly:

CPUs are like cars. Intel and Friends haven't been able to keep increasing the velocity they can safely and reliably run, so instead of relying on increased speed to get more people from point A to point B, they are instead starting to look at parallelization as a means to achieve better performance.

Now you are chopped up into 10 pieces and FedEx'd to your destination with 100 other people. Pieces may go by road, rail, air, or ship and thus overall capacity--"bandwidth" you might say--of the lanes of travel has been increased.

The only problem is that the people who make use of this new technique ("programmers", that is) have a hard time chopping you up in such a way that you can be put back together again. Usually it's a bit of a mess and more trouble that it's worth, thus we just keep driving our old-fashioned cars at normal speeds while adding lanes to the roads.

Re:Adapt

[Opyros]

Thanks for the explanation -- for a moment, I was actually wondering what OpenOffice.org's parallelization mechanisms had to do with anything!

Re:Adapt

[jd]

Well, you see, once IBM buys out Sun, Solaris is going to be re-implemented as macros in OpenOffice. Or Emacs. Whichever one they decide to pick as the new OS kernel.

Re:Adapt

[jd]

Three Cores for the Gnome kings under the Gtk,
Seven for the KDE lords in their halls of X,
Nine for Emacs Men doomed to spawn,

Re:Adapt

[Draek]

Three Cores for the Mozilla-kings under the GUI,
Seven for the Gnome-lords in their halls of X,
Nine for KDE Men doomed to be flamed,
One for the Free Scheduler on his free kernel
In the Land of Linux where the SMP lie.
One Core to rule them all, One Core to find them,
One Core to bring them all and in the scheduler bind them
In the Land of Linux where the SMP lie.

Which is, of course, what will eventually happen if the number of cores keep increasing: we'll need one dedicated exclusively to manage what goes where and when. Which is pretty cool when you think about it ;)

Huh?

[Samschnooks]

...programmers are to blame for that

The development tools aren't available and research is only starting."

Stupid programmers! Not able to develop software without the tools! In my day we wrote our own tools - in the snow, uphill, both ways! We didn't need no stink'n vendor to do it for us - and we liked it that way!

Re:The article's turning a real problem into FUD.

[cowbutt]

I dunno, I'm not feeling particularly fearful or doubtful after reading the article.

The articles has, apparently, sown Uncertainty in you, however, so it was 33.3% successful.

Re:Nothing new to see here...

[ari wins]

I almost modded you Redundant to help get your point across.

This is incorrect

[hazydave]

The idea of an OS and/or suppoet tools handling the SMP problem is nothing more than a crutch for bad programming.

In fact, anyone who grew up with a real multitheaded, multitasking OS is already writing code that will scale just dandy to 8 cores and beyond. When you accept that a thread is nothing more or less than a typical programming construct, you simply write better code. This is no more or less an amazing thing than when regular programmers embraced subroutines or structures.

This was S.O.P. back in the late 80s under the AmigaOS, and enhanced in the early/mid 90s under BeOS. This in not new, and not even remotely tied to the advent of multicore CPUs.

The problem here is simple: UNIX and Windows. Windows had fake multitasking for so long, Windows programmers barely knew what you could do when you had "thread" in the same toolkit as "subroutine", rather than it being something exotic. UNIX, as a whole, didn't even have lightweight preemptive threads until fairly recently, and UNIX programmers are only slowly catching up.

However, neither of these is even slightly an OS problem... it's an application-level problem. If programmers continue to code as if they had a 70s-vintage OS, they're going to think in single threads and suck on 8-core CPUs. If programmers update themselves to state-of-the-1980s thinking, they'll scale to 8-cores and well beyond.