Main > Main Forum
Dual processor motherboard?
Jdurg:
--- Quote from: Arshad on June 02, 2008, 03:56:26 pm ---Hmm, I'm not entirely convinced that this is true (that sync'ing would offset any possible gains from multi-threading). I would imagine that at the very least some of the processing happens on co-processors, whether it's for sound or video or whatever and this could be spawned off as separate threads. I haven't looked at the MAME code, so I could be completely wrong, but I could also imagine a scenario where one processor is doing the ISA decode and generating and caching 'optimal' sequences of native code that the other CPU could then execute (although this could all be done offline, or as a preprocess too). Maybe not a huge benefit, but given that all CPU's are going multi-core, it's dumb to ignore cycles that are sitting idle. Thread synchronization is obviously an issue, but with an intelligent design it could be minimized.
Anyways, I guess the bottom line for today's implementation is that a higher clocked single-core CPU is going to outperform a lower clocked one with multiple cores.
--- End quote ---
Well, think about what has to happen during emulation. ALL of the chips need to be emulated at the same time. If your sound processor emulation is being delayed a bit due to cross-talk that's needed between the CPUs, it will create a massive issue with the emulation of the game. It's not like the code from these arcade games runs natively on the CPUs we have today. There has to be translation. So if one CPU is sitting there waiting for the other CPU to translate and run the game code, there is a slight delay. To synch up CPUs is not an easy task. The amount of work that has to be done to translate the code, run the code, and ensure that there are no delays in processing between CPU cores is pretty large.
Take a look at MAME right now. Quad core CPUs aren't really doing all that great. DualCore CPUs are doing just fine, but I don't really think there's a huge increase from the dual cores as opposed to the better processing capabilities of the CPU itself. Where multiple cores can help are with tiny, slow processes that don't get delayed or de-synched. If you have an additional slow CPU on a game PCB that is able to be emulated on a separate core and then the synching with the main emulation still is not causing an issue, then there is no problem.
The argument of "Why can't they code MAME to run better on multiple core/CPU systems?" has been there for a while. It's not nearly as simple as people seem to think it is, and it won't help out with emulation like many believe it will. A multiple CPU/Core system is only going to emulate a game as fast as the slowest CPU in that multi-core system can run.
Arshad:
Just to qualify, I haven't looked at the source, and I have no idea how MAME is architected but I can make some educated guesses. The issue is that multi-core CPU's have only come into vogue in the past couple of years. Prior to that, multi-core systems were somewhat common in the Apple space, but not really on PC's. As such, I don't think much focus was put into architecting the system to take advantage of the extra cores. However, as we move forward there are serious physical limitations to how far we can scale frequency. Extra performance is only going to be had by going wider (more ALU's), and multi-core. MAME cannot simply rely on single CPU's frequency continuing to go higher -- it has to take advantage of the newer architectures to extract maximum performance.
As for your sync'ing argument, I agree that there is a penalty associated with it, but if the operations are properly pipelined, the benefit far outweighs the synchronization. This is just like any modern day superscalar CPU where you can have many operations in flight simultaneously but they still need to sync up at the end of the pipe. At the end of the day, you still get a huge performance win by getting better utilization of the underlying resources. Running an emulator is really not all that different from running other types of code. With some creative thinking, it's often possible to parallelize many problems, or at the very least possible to pipeline or break down the code so that different parts can be run concurrently.
I am sure it's not a trivial problem to solve, but I also don't think it's an impossible problem either.
ark_ader:
Most Duos run slightly faster or over-clocked when treated as a single processor, so the sync'ing issue would be moot anyways.
Ummon:
Search around MameWorld. Been talked a lot about there, and answered by folks like R. Belmont and Aaron.
Navigation
[0] Message Index
[*] Previous page
Go to full version