For the programmers out there, (I'm studying hardware/networking) Is there any way to patch a current program to use SMP? That would require a complete recompile/rewrite, correct?
It depends on the software -- some is easier to split into multiple threads than others. If an application has a single very computationally intensive task it can often be chopped into pieces and done in parallel. Often tasks aren't computationally intensive even though they take a lot of time... they can be memory bound, disk bound, network bound, etc. and so having more cores doesn't help. Other kinds of apps have a natural way to split them into a specific number of threads and if the software was properly written this isn't hard to achieve but they can't scale well past that number of processors. So really there is no standard answer to your question, but a considerable amount of the software out there will likely need a rewrite if it is to benefit from multiple cores.
There is a big difference between the MHz-myth and the marketing wave of multi-core... with the MHz-myth it was a lie (or at least an exaggeration) and your machine just wasn't as fast as its clock rate may have implied if you'd fallen victim to the hype. With multi-core machines, however, you are buying untapped potential. In the future more software will take advantage of having more cores, unleashing the potential you paid for.
The good software developers out there have been anticipating this for a while and have been moving in a direction that will allow them to take advantage of the new hardware and thereby gain advantage over their competition. As the hardware becomes more ubiquitous, the tools developers use will adapt and aid developers to create software that is better prepared to leverage the hardware.
Some folks been doing multithreaded/multiprocessor development since...hmm...the 70s? At least the early 80s as I have a textbook about massively parallel processing from that time period in a box somewhere.
Most apps built with Java or .NET have at least a couple threads, a main GUI thread, a worker thread or two. A lot of the guts hidden from programmers by the framework. However, as Programmer noted, a lot of threads are IO bound. Additional CPUs only help a little for some applications.
But software, at least the science part, has had a couple decades of research into concurrency. And we've had at least half-assed mutli-threaded support for almost that long even in Windows NT which was better than early p-threads (posix) implementations which really sucked. Solaris had excellent threading support back then.
Comments
For the programmers out there, (I'm studying hardware/networking) Is there any way to patch a current program to use SMP? That would require a complete recompile/rewrite, correct?
It depends on the software -- some is easier to split into multiple threads than others. If an application has a single very computationally intensive task it can often be chopped into pieces and done in parallel. Often tasks aren't computationally intensive even though they take a lot of time... they can be memory bound, disk bound, network bound, etc. and so having more cores doesn't help. Other kinds of apps have a natural way to split them into a specific number of threads and if the software was properly written this isn't hard to achieve but they can't scale well past that number of processors. So really there is no standard answer to your question, but a considerable amount of the software out there will likely need a rewrite if it is to benefit from multiple cores.
There is a big difference between the MHz-myth and the marketing wave of multi-core... with the MHz-myth it was a lie (or at least an exaggeration) and your machine just wasn't as fast as its clock rate may have implied if you'd fallen victim to the hype. With multi-core machines, however, you are buying untapped potential. In the future more software will take advantage of having more cores, unleashing the potential you paid for.
The good software developers out there have been anticipating this for a while and have been moving in a direction that will allow them to take advantage of the new hardware and thereby gain advantage over their competition. As the hardware becomes more ubiquitous, the tools developers use will adapt and aid developers to create software that is better prepared to leverage the hardware.
Most apps built with Java or .NET have at least a couple threads, a main GUI thread, a worker thread or two. A lot of the guts hidden from programmers by the framework. However, as Programmer noted, a lot of threads are IO bound. Additional CPUs only help a little for some applications.
But software, at least the science part, has had a couple decades of research into concurrency. And we've had at least half-assed mutli-threaded support for almost that long even in Windows NT which was better than early p-threads (posix) implementations which really sucked. Solaris had excellent threading support back then.
Vinea