| << Newer | Article #20 | Older >> |
Stuck below 4GHz….
Well, the writing's been on the wall for a while now. Up until recently, my development system upgrade cycle was generally every 18-24 months. I would get a good 2x+ speed increase and life would be happy again. But I bought my 3GHz PC a little over 2 years ago, and where are we topped out now? 3.6GHz. Even with bus, memory, and cache improvements, we're nowhere near a 2x increase from my main desktop machine. Which is why I broke down and bought a laptop this round.
There's a really good article soon to be published in Dr. Dobb's Journal that talks about what's going on in the processor space, and why we're going to soon have more processors than we know what to do with, but we'll still be capped in raw clock speed for quite a while.
Of course, this is of concern for those who like to play with MAME....
I've quoted 10GHz as what you would need to run the Seattle games full speed, and that may be a little on the low side. People have asked for multiprocessor support in MAME, but the way MAME is architected, there isn't too much that can realistically be offloaded to a second processor. For most games that are currently slow in MAME, there is one big bottleneck that can't really be split. For Seattle, it's the R5000 emulation, which even by itself won't run full speed on less than 5GHz. Now, with some work, the Voodoo emulation could be made to run on a second processor, which would get you closer to full speed on a dual core machine, but it's still not going to get you all the way there.
In MAME's general architecture, there's not much room for splitting things up. The only obvious place is on the video side. The code that renders tilemaps, sprites, and polygons into the frame buffer could potentially be made to run on a second processor; however, that code by necessity accesses buffers which would need to be copied so that they aren't modified while the first processor continues the CPU emulation during the rendering phase. If these buffers are large, then you're not buying yourself time because the copying eats the cache and slows down first processor.
Once the data is in the frame buffer, the code which draws it to the screen could be made to run on a second processor without much ado; however, apart from demanding artwork compositing, that's not going to save you a whole lot of time in the grand scheme of things.
Sound emulation these days isn't a large percentage of games' time. Even the discrete sound system, which is demanding, isn't too bad because the games which use it tend to run on fairly ancient hardware.
Finally, everyone likes to think that multi-CPU games could obviously make use of multiple processors, but this isn't the case. In theory you could run each CPU on a separate processor, but then you have thrown all synchronization between the processors to hell. It's rather difficult to explain why unless you have actually written multithreaded code and understand how timing and interrupts work in MAME, but it's definitely not possible in a completely generalized system. You might be able to make it work for certain games with a lot of synchronization, but you're really asking for trouble. And then, because every OS schedules threads and processors differently, you will have a host of bugs which only happen on certain systems or under certain conditions which are not globally reproducible. It's just not worth it.
So, in short, I expect there will eventually be an interest in adding some multiprocessor support to MAME, but it will not be the pill to end all your performance woes.