Existing software will continue to run on the individual processor cores. Something that they've done for a long period of time. Old software may not get any faster due to a change in focus toward parallelism vs. increased core speed, but it's not going to suddenly come to a screeching halt any more than my DOS programs from 15 years ago are.
This somewhat depends on what architects do. If they add another level of cache to a processor then that increases the penalty of a cache miss which could lead to a decrease in performance... just a thought.
A lot depends on what hardware architects and mass-market compiler developers start doing when they get beyond having just 4 or so cores on a processor. Performance of legacy code remaining fixed in terms of wall-clock time to solution forever definitely depends on a number of things.
I agree... anyone who's developed multi-threaded code for an SMP has probably run into the problems of debugging asynchronous thread events. This can make debugging, which is already tedious even more tedious and time consuming.
As the number of cores increases different algorithmic approaches will need to be pursued to get the maximum performance. Many algorithms which are great for serial processors will perform poorly on a parallel architecture.
I think many people don't realize just yet how big of a paradigm shift multi-core really represents. Think of all the billions of lines of legacy code that exists out which was written for sequential computing. Scalability of code is also important since code written today is tomorrow's legacy code code written that isn't scalable will eventually need to be revisited.
Multi-core will probably also require a new look at memory systems in PCs... To keep a lot of cores busy you have to feed them and that means possibly changes to the memory subsystems. It's not so bad now with so few cores on processors, but as they increase to 16, 32, etc. things start to get harder.
In any case, multicore is here to stay and it will be exciting to see what changes come about in the next few years.
Slashdot Mirror
This somewhat depends on what architects do. If they add another level of cache to a processor then that increases the penalty of a cache miss which could lead to a decrease in performance... just a thought.
A lot depends on what hardware architects and mass-market compiler developers start doing when they get beyond having just 4 or so cores on a processor. Performance of legacy code remaining fixed in terms of wall-clock time to solution forever definitely depends on a number of things.
I agree... anyone who's developed multi-threaded code for an SMP has probably run into the problems of debugging asynchronous thread events. This can make debugging, which is already tedious even more tedious and time consuming.
As the number of cores increases different algorithmic approaches will need to be pursued to get the maximum performance. Many algorithms which are great for serial processors will perform poorly on a parallel architecture.
I think many people don't realize just yet how big of a paradigm shift multi-core really represents. Think of all the billions of lines of legacy code that exists out which was written for sequential computing. Scalability of code is also important since code written today is tomorrow's legacy code code written that isn't scalable will eventually need to be revisited.
Multi-core will probably also require a new look at memory systems in PCs... To keep a lot of cores busy you have to feed them and that means possibly changes to the memory subsystems. It's not so bad now with so few cores on processors, but as they increase to 16, 32, etc. things start to get harder.
In any case, multicore is here to stay and it will be exciting to see what changes come about in the next few years.