Windows and Linux Not Well Prepared For Multicore Chips 626
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."
Adapt (Score:3, Funny)
Huh? (Score:5, Funny)
...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. (Score:5, Funny)
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... (Score:5, Funny)
This is incorrect (Score:4, Funny)
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.
Re:Adapt (Score:5, Funny)
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.
God! The guy doesnt even know Linux != GNU/Linux (Score:2, Funny)
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.
How many times do we have to tell that Linux *IS* the fscking kernel??
Given that, including Linux and Windows in the same bag doesn't make sense. Which makes the entire post m00t.
Solutions:
1) s/Windows/Windows NT kernel/
2) s/Linux/GNU\/Linux/
Nice try to get a battle though.
do it the unix way, use pipes! (Score:2, Funny)
Unix has for ages run on multi CPU systems. And it does this well. And with easy tools you can harvest the power of all CPUs: the pipe
Every part of the pipe can run on another CPU.
I recently came across fslint, which is a example of heavily piped shell.
In short (leaving out the parameters and options) it runs
find | sort | tr | sort | bash | merge_hardlinks| uniq | sort | cut | tr | bash | xargs | sort | uniq | cut | sort | tr | xargs | sort | uniq | cut | sort |tr | xargs | sort | uniq | cut | bash | sort
That's a lot of CPUs :-)
OK it's not a great example for CPU hungry programs. But the progress of the modern programming languages which tend to be monolythic beasts to do everything (perl, php, java) lead to programs not using pipes or other types of inter process communication because it's just cumbersome.
The pipe concept enables multi CPU programming without even thinking about how to put tasks on different processors.
Unfortunatly I have not found a language which sets such a simple concept as the fundamental programming principle.
See the unix shell, without the pipe you can't really do much.
Re:Adapt (Score:5, Funny)
Re:Adapt (Score:5, Funny)
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 (Score:4, Funny)
Re:Adapt (Score:5, Funny)
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 (Score:5, Funny)
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 (Score:5, Funny)
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 ;)
Re:If you are right, we aren't very smart (Score:3, Funny)
And sometimes, even, our background grammar checker misses things that our background finger-controller mis-types while on auto pilot. thought/though, thing/think are stroke-patterns that my hand-controller mixes up a lot and since this isn't something super-formal, the top-part of my brain never catches.
Re:Adapt (Score:1, Funny)
One for the Ballmer, who throws his dark throne,
In the land of Redmond, where the Windows roam.