Quote:
Thats right. But if I run 4 apps which all together do not use 100% of one single core, why should it be faster to run these four apps on four cores?
It depends on the ratio of the CPU they would use on a single core.
If you have 4 apps which use 10% each of a single core they will not run faster. They will just use 10% of a seperate core. But then they also do not need a single 2.5GHz core to run on anyway if they will not fully utilise it.
If you have 4 apps which require 33% each of a single core, they will run faster as they can all run at their full potential on a core each, instead of being "truncated" to 25% each. Therefore 4 cores will be faster.
Either way there is no disadvantage to a multicore setup. Apps should multithread; this has been the design philosophy for computing for a very long time, SMP has been around for a very long time, it not only increases performance on SMP but it increases interactivity on single-processor machines.
On AmigaOS for years it has been the recommendation to put your user input thread seperate so that you can collect it while your main task is busy.
Take for example a networked app - a good one is most web browsers, which spawn a process for networking and especially DNS lookups because gethostbyname() is a blocking call. You don't want your entire browser to freeze when it looks up a hostname. Also, Networking should not block layout, and the same way, layout should not cause the HTTP stream to pause being received. Image decoding should not freeze HTML parsing. And most of all NONE of these tasks should stop you from clicking the "STOP" button.
On MorphOS, look at Voyager and IBrowse for examples.
Basically there are two kinds of task in the world, the compute-bound and the io-bound. The vast, vast majority of applications that people run are predominantly io-bound, in that they access disk, wait for mice, handle network, hand data to graphics cards, etc. and your performance is limited by that - a DVD player is limited by how fast it gets data from the DVD drive and then by how much data it gets (up to 15MBit/s usually, it only has to decode 30 frames per second), the rest of the time it is idle.