It seems as if the entire IT industry agrees, that more performance in PCs will be achieved by using more cores in CPUs. Is it true, and what are the implications for Delphi programmers?
Let's start with the assumption about multiple cores. In order to match CPU I/O count performance in a modern PC, you would have to make more than 50 harddisks work in parallel. RAM also has its performance limits, especially as core count grows, so multiple cores are really more about CPU-bound calculations than about anything else. The harddisk problem can be solved by using network attached storage with arrays of harddisks, and the RAM limits can be solved by letting each CPU have its own RAM (like NUMA or other architectures). These solutions are obviously good for servers, which have many concurrent requests, where each request can be served by one thread. This doesn't have much influence on how we write source code, and Delphi does the job very well.
If you want greater performance on a desktop PC, we're usually talking games and simulations or data handling software (database applications). I'm not much into games and simulations and will focus on client/server database applications. The typical performance problems with database applications are about data retrieval over the network, sorting, lookups and filtering. If you have a performance problem in such an application, you will usually not want it to be 2 times faster, but 10 times faster. Given the architectural problems in a desktop PC, this is not possible by using multithreading.
What is needed, is to minimize the time from a user action until something happens. You can do this by caching data, doing things in the background, and by preparing data for user actions that you expect to happen. Multithreading is a very good tool for doing this, so enabling multithreading in applications is something we need - but it's not because the CPUs are going to be multi-core. There are many ways that CodeGear can make Delphi support these techniques, either using technologies like MIDAS, or by modifying the language slightly. But there is no reason to fundamentally change the programming language.