Getting Closer to Reality
If you are upgrading to newer processors that have more cores, but slower speeds, then your applications may run slower unless you prepare them to run across multiple processors. While compiler builders such as Codegear (Borland) and Microsoft are sure to build features into their compilers to help with this speed issue, in many ways, the onus is on the developer. It is up to developers to change the design and architecture of their applications to take advantage of the added core. Sequential applications will take advantage of a single core only; if a design change isn't made, you won't gain any speed.
It is going to become critical that developers, architects, or application designers understand concepts such as concurrency and parallelism, if application speed is important. Even if speed isn't important, chances are that you will have to know these concepts in the future. While the tools will eventually make it easier to work with these concepts, it is only the developer that can determine what business logic can be broken across processor cores. As such, while the compiler manufacturers might make it easier to add threading or another manner of using cores, the odds are it will be you that has to decide how to use it.
If you don't use threading in your processor-intensive applications, it doesn't mean you will automatically lose and that your applications will slow down. Your operating system will very likely be able to also take advantage of multiple coresif not today, they will in future releases. This ability means that rather than sharing a single core between your operating system, your application, and everything else on your system, the operating system will be able to use one core and possibly let your application use a separate core. This feature alone could also give you some speed increases. As one person recently joked, "With multiple cores, you get one for your application and the rest for all the spyware on your system!" Regardless, some gains can be had.