From multi- to megatasking
Everyone has heard of multitasking. Indeed, the term is even used by non-IT people to refer to physically doing lots of things at once. But it clearly wasn't enough for the quad-core era, which AMD is claiming is yet another step forward. So now we have megatasking - like multitasking, only more so. We can't see it catching on in everyday life, but we've tried to take the idea seriously in our testing. In a nutshell, it means running not two apps at once but three or four.
Our first hurdle to overcome when setting out to test megatasking, was deciding upon exactly which applications to run. Lots of us have numerous apps loaded at once, but often only one of them is active at a given time. You might leave your email client open when you're gaming, for example, but it's not consuming any significant processor time - it just uses up a bit of memory. AMD has suggested some more demanding scenarios, however. These include gaming and media encoding, but also the more dubious idea of running more than one game at a time.
Putting the latter to one side, the question is - would you really want to play a game and encode at the same time? Unless you own lots of PCs you can farm out tasks to, there is a chance you might. If you're running a video encode which takes hours to complete, you may want to fire up a quick game whilst it's still operating. But it is still questionable whether you would want to do more than two things at once. AMD mentioned the idea of encoding multiple video streams on the fly from a system acting as a central media server. Whilst this is conceivable, the end-user products to do this aren't mature. So it remains a future possibility rather than a real-world scenario we can test right now.
Even once we'd decided to run four apps anyway, megatasking also proved a very complicated concept to test in a repeatable way. With four different applications running at the same time, the chances of one of them producing spurious results went up fourfold as well. And if our results varied too much between runs they would be effectively useless - unable to tell us anything concrete about the performance of the platforms on test. What we needed was a testing scenario involving four applications which was automated as much as possible so we could run it in the same way across each test system.
In the end, we opted to run four applications from our usual suite - POV-ray 3D rendering, LAME audio encoding, DivX video encoding, and Quake 4 gaming at 1,024 x 768 with SMP turned on. We chose these four in large part because all of them can be launched from a command line. This allowed us to create a batch file to start them off in succession, eliminating any human error factors. But there were still some foibles with this arrangement. Primarily, as we launched each application from a single batch script, all four would only run concurrently on quad-core PCs. On dual-core systems, whilst POV-ray was inititated to start immediately, a lack of CPU resources ensured that it wouldn't start until the Lame audio and DivX video encodes were finished.
So some results were not directly comparable from dual-core to quad-core. For quad-core systems, Quake 4 was running at the same time as a POV-ray render, LAME audio and DivX video encodes. But with dual-core systems Quake 4 was running first with LAME and DivX together, and then, for a large portion of time and due to the resource issues discussed above, with POV-Ray on its own. We've also provided the time taken to complete all three of these encoding and rendering tasks put together. On quad-core systems they are running concurrently so the time is that of the longest to complete (the LAME audio encode). On dual-core systems, the POV-ray time is added on the end. This may seem incomparable, but if you want to do all three tasks at once, it's how long the whole lot takes which matters, so we consider it to be a key way to show the advantage of quad-core over dual core.
