Dual processor motherboard?

[boodroe]

I have read that mame runs mostly off of the CPU and not the graphics card. Would it be worth buying a dual processor motherboard to run the high end games in mame? Will having a dual processor motherboard make mame twice as fast?

[Jdurg]

I have read that mame runs mostly off of the CPU and not the graphics card. Would it be worth buying a dual processor motherboard to run the high end games in mame? Will having a dual processor motherboard make mame twice as fast?

Absolutely not.  In fact, it may make MAME run even slower since now it would have to synch up to two completely separate processors through the motherboard.  Dual Core processors are able to function well because the two CPU cores are contained within the same physical chip and there isn't as much 'talking' needed with them.  In addition, they are very powerful processors on their own.

Remember, just because you have multiple processors doesn't mean that you have twice as much CPU power.  In order to take advantage of both processors, you need to have software designed to use them both.  This software will send certain commands to one processor and other commands to the other processor.  All the while, the system has to synch up what the two CPUs are doing to ensure the taks gets completed properly.

With emulation, you really can't separate one emulation task into multiple "threads" and gain any speed at all.  In some cases, you lose speed as you try and synch things up.  Therefore, throwing in multiple processors won't do anything as the steps which slow down emulation are only able to be done by one CPU at a time. 

A good analogy is putting multiple engines in a car.  You can throw four engines in an automobile, but it doesn't really mean that the car will go faster than an automobile with only one engine.

[Arshad]

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.

[billpa]

You should check out this thread if you are interested in running some of the more demanding games

http://forum.arcadecontrols.com/index.php?topic=72776.0

What it comes down to is what games you want to play and whether they are worth spending the money for a 2 core duo system. There are probably only a handful of games that I wish I could play (Gauntlet Legends, Blitz, Wayne Gretzkey's Hockey) but the additional cost of building a system to run them is too much for me right now.

[Timstuff]

You only need a dual core processor if you intend to run more graphics intesive emulators like NullDC (which can be nice to have since Dreamcast was home to many arcade-perfect ports of recent games), or new games like Street Fighter 4. In my experience though, an AMD single-core processor gets the job done just fine when it comes to Mame.

[Jdurg]

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.

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.