Main > Main Forum

Phenom II vs Core 2 Duo - Benchmarks

<< < (4/8) > >>

u_rebelscum:

--- Quote from: saurian333 on January 08, 2010, 01:54:10 am ---Correct me if I'm wrong, but when you're looking at an emulator, isn't it a question of whether the emulator itself will utilize the multiple cores?  So technically, a game that doesn't "benefit" from 3 cores vs. 2 would still be utilizing it as the emulator allows....

--- End quote ---

I think you're making the assumption that all games are emulated with the same code. 

Each emulated CPU, video chip, sound chip, etc (IOW each emulated chip) has its own code.  Sure, all games use the same mame core and OS dependent code, but little of the emulation is done in these shared code.  More important, most (if not all) of the slowdown occures in the chip emulation code.
(^This is a simplified view, but I hope not over simplified.)

So, if one or two CPU's emulation code is able to multi-thread enough to use more that 2 of a PC's cores, it will only help the games that use that CPU.  Which IIRC is what's happening, and why only a few games can effectively use more than 2 core.

massive88:

--- Quote from: saurian333 on January 08, 2010, 01:54:10 am ---
Correct me if I'm wrong, but when you're looking at an emulator, isn't it a question of whether the emulator itself will utilize the multiple cores?  So technically, a game that doesn't "benefit" from 3 cores vs. 2 would still be utilizing it as the emulator allows.  While there might not be a noticeable difference to the user, certain benchmarks may show a slight increase.  Obviously you don't need 3 cores for Galaga, for example, but if it's using 3 cores, there should still technically be some kind of performance increase.  Another factor to consider is how well your OS and any other background processes are utilizing those cores, and how that is impacting overall performance.

Just a thought; again, let me know if there's something I'm missing.  I don't have any systems that close to each other (e.g. a 2.8 single core to compare with my 2.8 dual-core) to run any tests myself, so I'll have to take others' word for it. :)

--- End quote ---

To perhaps simplify and be even more incorrect, you can think of Mame as many (or multiple even!) emulators in one package.  Each arcade board basically is a collection of the individual hardware chips.  MAME emulates the chips, and the drivers put the chips together to emulate the board, in a more traditional sense (NES emulators for example have only one board to emulate, so breaking it down like this isnt all that useful).  So if you say a game benefits, you are really saying that a driver benefits, which is really saying that some of the components emulated in the driver benefit.

A chip emulated in the galaga driver may not gain anything, but a different chip emulated in the Killer Instinct Driver might.  The collections of chips make a driver, and all of these drivers are under the single MAME package.

Some games use the same driver (different software on the same hardware), but many times the hardware is unique in its application (hardware uniquely used for the software) if not components (emulated chips).  Was that adding more confusion?

massive88:
Ok, went through some more, this time using 0.136.

The first column is the 0.136 64-bit build as downloaded from Mamedev.  Other columns are using source and Headkaze's compiler optimizing for Core2/AMD64, 2 cores, and 64-Bit.

The color in the first column is comparing the AMD to the Intel, if its red, the other chip does it faster, if its green, it was the faster chip.  In the second and third columns, they are being compared to the column to the left.  If Optimization made a sizable difference, its green.  If nomt was slower than optimization, its red.

On the AMD chip, this time I clocked it up to 221 mhz x 14.5 so its actually running at 3.2 ghz, not 3.19 it was before.  Not much of a difference, but the actual speeds of the two chips should be closer now.

I tried the -str argument Robin, but that made the first test never end.  Not sure what was going on, but they ran fine once I dropped it off.  These runs are using the same string originally done, except with D3D instead of ddraw.



Edit: Also just ran the AMD64 using ddraw instead of D3D, looks like there was no effect on performance.  Some were slower, some were quicker, all within 2% of each others numbers though, so probably within the variation of the tests themselves.

saurian333:

--- Quote from: u_rebelscum on January 08, 2010, 01:06:09 pm ---I think you're making the assumption that all games are emulated with the same code. 

--- End quote ---


--- Quote from: massive88 on January 08, 2010, 01:32:38 pm ---To perhaps simplify and be even more incorrect, you can think of Mame as many (or multiple even!) emulators in one package.  Each arcade board basically is a collection of the individual hardware chips.

--- End quote ---

You guys are right, of course.  I knew arcade ROMs were collections of multiple emulated chips, and just wasn't thinking about that when I made that statement.  Silly of me, really.

For a console emulator, I'd be correct, since the software would be emulating the entire system, and all information in a ROM is simply a data dump from a cart or CD.  Obviously the arcade ROMs are more complex.

That last set of results is very interesting.  I'm still curious as to how the OS's utilization of the cores affects things.  For example, if the OS is leaving the Phenom's third core basically untouched, and most of the games are not using it either, then it's no surprise that there's no increase.  But if you could set the affinity of most of your other processes to that third core, leaving more of the first two for MAME, I wonder if there would be more of an improvement over the Core2.  Not sure how far you can go with that; even in Linux, you can't set the affinity of everything, and probably even less so in Windows.  Even so, that may be beside the point since the Phenom X3s are generally much cheaper than the Core2s, and apparently yield at least similar performance.

u_rebelscum:
Ausome to see the numbers!  looks like the compiler optimizations have gotten a little better than a couple years ago.  :applaud:

First a clearification:

--- Quote from: massive88 on January 10, 2010, 08:55:08 am ---I tried the -str argument Robin, but that made the first test never end.  Not sure what was going on, but they ran fine once I dropped it off.  These runs are using the same string originally done, except with D3D instead of ddraw.

--- End quote ---

"-str" is short for "-seconds_to_run", and mame will except either form.  If you had both, there might be some issues, and if you left either blank, there will be problems.  I was trying to say, "Since you're already used -str (aka -seconds_to_run), mame doesn't show the nag screens."  I can see how my original post wasn't clear.  Sorry. :-[


Okay, back to the numbers (see attached table).  For the averages, I get close but slightly different numbers.  (Calculated differently?)  

Anyway, the phenomII optimization averages a 3% speed increase for the tested games, with a max increase of 4.7%.  The Core2 optimization averages slightly higher, 3.7%, but has a much wider range: max increase of 11.5%, and the min is a decrease of -6.8%.  The -MT option differences are simular: Core2 aveage higher with wider range, including a decrease, while phenomII is a little smaller difference and range, but all positive.

And not to be missed, the phenomII holds it's own again the core2, Ghz for Ghz,  with four games favoring each CPU, and one game a virtual wash (< 2% difference), and the total average of the nine game at less than 0.5% difference.  All games tested except dolphin ran at 95% or greater for the phenomII, but for the core2, gradius4 was under 80%.  If these nine games are a good representation of all the games in mame, things are looking very good for phenomII:

The phenomII on average has the same bang as the core2, priced at a lower buck, for a total better bang per buck.  We also can't say "Core2 is the only way to go" anymore.

edit: uploaded second table

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version