And actually, Linux can run on dozens of cores simultaneously already. I've done it. I'm not saying that it's necessarily doing it in the best way it possibly could, but it does get the job done, and it's pretty smart about recognizing things like process affinities, which become even more important when you go to massive multicore.
They do. They bought PeakStream.
Now, I have no particular idea what they're doing with PeakStream's technology, but clearly, like Victor Kiam, they liked it so much they bought the company.
If you retain the concept of a single north and south bridge, then yes, there's going to be a bottleneck. But on the multicore chips I've worked on, that doesn't exist: there are multiple memory controllers and multiple I/O controllers built right into the chip. Memory bandwidth is still an issue (and indeed often _is_ the major gating factor) but if you want to get really good performance out of a truly multicore architecture, you're going to have to rethink the memory and I/O connectivity. NUMA isn't that far out of the mainstream now, and if we're going to go all out for multicore, it's going to swim right into the mainstream.
No. Read the article and/or the thread. This isn't about interfacing with the hardware; it's about how you designed your algorithm in the first place. All that MS could do in the OS, they have pretty much done already. Now it's the application developer's job to work out how to split their program up into little pieces that can all run at once.
That said, there is some mileage in compilers figuring out the parallelism and doing it themselves; but I've seen some attempts at it and they really didn't help all that much, because the real parallelism win is generally at a coarser level than a compiler can easily pick out (i.e. it's beyond the bounds of one function). Compiler technology is going to have to change fairly radically (with a lot of intelligence moved to the linker) if we are really going to see a significant payoff from automatic compiler-driven parallelism. I think it could happen, but it's probably a way off yet.
Slashdot Mirror
And actually, Linux can run on dozens of cores simultaneously already. I've done it. I'm not saying that it's necessarily doing it in the best way it possibly could, but it does get the job done, and it's pretty smart about recognizing things like process affinities, which become even more important when you go to massive multicore.
They do. They bought PeakStream. Now, I have no particular idea what they're doing with PeakStream's technology, but clearly, like Victor Kiam, they liked it so much they bought the company.
If you retain the concept of a single north and south bridge, then yes, there's going to be a bottleneck. But on the multicore chips I've worked on, that doesn't exist: there are multiple memory controllers and multiple I/O controllers built right into the chip. Memory bandwidth is still an issue (and indeed often _is_ the major gating factor) but if you want to get really good performance out of a truly multicore architecture, you're going to have to rethink the memory and I/O connectivity. NUMA isn't that far out of the mainstream now, and if we're going to go all out for multicore, it's going to swim right into the mainstream.
No. Read the article and/or the thread. This isn't about interfacing with the hardware; it's about how you designed your algorithm in the first place. All that MS could do in the OS, they have pretty much done already. Now it's the application developer's job to work out how to split their program up into little pieces that can all run at once.
That said, there is some mileage in compilers figuring out the parallelism and doing it themselves; but I've seen some attempts at it and they really didn't help all that much, because the real parallelism win is generally at a coarser level than a compiler can easily pick out (i.e. it's beyond the bounds of one function). Compiler technology is going to have to change fairly radically (with a lot of intelligence moved to the linker) if we are really going to see a significant payoff from automatic compiler-driven parallelism. I think it could happen, but it's probably a way off yet.