Build Your Own Arcade Controls Forum
Main => Software Forum => Topic started by: Scott84 on September 17, 2005, 01:48:47 am
-
Im wondering if anyone has the new AMD Athlon XP 4800+ kicking around and want to see how the CHD Games run on them?
Just curious how good CHD games would run on one of the best processors out!
Thanks if anyone can test it!
-
Lots of the CHD games run ok on oldish hardware. A better test would probably be some of the 3d games, IMO.
-
Mame would run about the same as on the equivalent speed single core AMD 64. Mame is single threaded. However, in addition to running all of the games the same, with the dual core processors you could also say, encode a video in the background without slowing down Mame.
-
If you're looking to do this test, you'd want something like an FX-57 on a phase change system or a EE Pentium4 on phase change. Get that CPU as fast as you can and then test. That's the best way to do it.
-
What Maxim and pointdablame said....
I personally would be interested in a price/performance comparison, ie. what Intel and AMD processor of each family (A64, AXP, P4, etc) is the minimum necessary to run X at some number of FPS, using the canned build and an optimized build, with certain MAME options set.
This would be quite a large project.
-
I would love to see someone play all games and rate the fps on them... And sort them that way
So you can say Game X runs... so all lower on the list might have preoblems..
basically just rank the requirements for them all.
-
I thought the bottleneck for many of the CHD's was spindle speed. Am I wrong?
In addition, I wasn't aware that mame is single-threaded. It looks like it's developed in some C variant so I'd wonder if it's a strict limitation of the ROMs that forces the mamedevs to only spawn a single thread
-In2
-
I thought the bottleneck for many of the CHD's was spindle speed. Am I wrong?
Not sure I quite follow - spindle speed is a physical aspect of a hard drive. The spindle speed of the cpu you run mame on is irrelevant. I don't know how CHD's are read by mame but I suspect that loading the image directly as it does is almost always faster than the original game could supply data off there own HDs.
The issue in speed is of emulation of the system. The fact that CHD games are often talked about as slow is because they tend to be newer games (they had HD's after all) and therefore tend to be based on newer and faster hardware, hence take more power to emulate.
In addition, I wasn't aware that mame is single-threaded. It looks like it's developed in some C variant so I'd wonder if it's a strict limitation of the ROMs that forces the mamedevs to only spawn a single thread
What a program is written in has almost no bearing on whether it is single or multithreaded. The original systems design/roms are completely irrelevant.
Writing multithreaded applications is very hard. There are also exceptionly few programmers that have a lot of experience writing multithreaded applications (multiple processors have never threatened to be mainstream until recent multicore processors). People tend to imagine that complex emulated games could be sped up by sticking 1 emulated cpu on one processor and emulating the other on the 2nd cpu/core. The problem is that these emulated cpus have to communicate on an extremely exact timing schedule that takes an *unbelieveable* amount of tough programming to achieve across seperate cpus. So much so that it has been suggested that even if all the effort was gone to, the overhead all the extra code to keep the emulated cpus in sync would probably cancel out all the speed advantage, taking you back to square one, except with a program thats probably twice as hard to debug, and probably buggier.
At most you can offload some non-emu related tasks, like drawing the bitmaps to the screen etc..., to a 2nd cpu, but you would only gain a tiny amount. The best advantage is that all OS related tasks could be kept on one core, allowing mame exclusive access to the 2nd core. I'm sure this could help by 5%(?anyone?). So sadly thats the best to hope for, at least until programmers spend a few years really getting to grips with multicore, or someone releases a highly optimised auto-matic multithreading compilier. (I don't see that happening).
-
I thought the bottleneck for many of the CHD's was spindle speed. Am I wrong?
No, the CHD has nothing to do with the performance of most CHD games, it's the fact they are newer games that ran on newer 3d graphics chipsets that need to be emulated.
-
Not sure I quite follow - spindle speed is a physical aspect of a hard drive. The spindle speed of the cpu you run mame on is irrelevant.
Considering we are talking about CHD's (compressed hard drives!?!?!, duh me ::)), I should have been more clear. I have a 2.53/1Gb and a drive that moves data at between 4,500 and 5,500 Kb/s. Any time I have tried to run a game with a CHD, I notice, even when the game appears to be fully loaded, that I'm running up against significant I/O on my physical drive. That's really what I was talking about. I used "spindle speed" more as techie slang. With that, I guess I suspected one of the major reasons for the poor performance was because my drive couldn't handle the intense I/O.
What a program is written in has almost no bearing on whether it is single or multithreaded. The original systems design/roms are completely irrelevant.
Understood. Agreed. I shot myself in the foot again by not being clear. >:( I was talking about the free-threading benefits of writing in a C variant as opposed to the only other OO language with which I am familiar VB6. I know nothing of the language, but, from past conversations I have always had the impression that something like C++ gives the author the option of free-threading -- though, admittedly, I can't even talk about the topic intelligently. However, given what you've outlined as the hurdles to writing multi-threaded apps, as well as the years of experience the Mame Devs have, I'm sure it was a consideration at one point and abandoned when it didn't make sense (likely for the reasons you outlined).
Interesting lesson though. Thanks for clearing up some of my misconceptions.
-In2
-
Um, the significant I/O on your system might be you using swap space.
I hate swap space with a passion. Prior to XP I would disable it on every system I owned. I haven't experimented with disabling it on XP though.
-
If you are worried about I/O you could creadte a very large RAM drive and see if that speeds things up :)