|
|
Re: MAME 0.281 Icons / Snaps / Benchmarks
10/04/25 11:49 AM
|
|
|
> > It compiles MAME about a minute faster than my M3 Max (7 minutes for a clean full > > build with tools vs. 8 on my M3 Max), which is what I'm happiest about, but running > > it really well is great too of course :-) Also Vas is continuing to tune the DRC for > > both x64 and ARM so there should be small improvements in the heavier games in 0.282 > > again. > > A 13% saved in compile time is huge for development, I can understand why you're > happy with that. > > Great to hear Vas is working on squeezing more performance out of the DRC. Any gains > on the software side of the performance equation is only going to be multiplied by > gains on the hardware side.
The ARM back-end is already executing more IR instructions per host CPU clock cycle than the x86-64 back-end, and I’ve mostly just been going for easy gains so far. (That’s part of the reason some of the MIPS, PowerPC and SuperH games do so well on ARM – the back-end is actually pretty impressive, even to me as the person who did most of the performance tuning for it.)
I know I can get quite a bit more performance out of ARM, but it requires some significant architectural changes to the back-end (won’t require changes to the emulated CPU cores themselves to benefit). The stuff I want to do can’t be done incrementally, and it’s going to require non-trivial time investment.
I optimised the Hyperstone E1 recompiler a lot already. Between that and optimising the x86-64 back-end, it now generates less than half the number of native instructions, while emulating more CPU features with more accuracy and matching the interpreter on cycle counts. There are definitely gains to be had by optimising the code generation for the other recompiling CPUs, but it isn’t a rabbit hole I want to go down right now.
On the bright side, the state the code was in at the beginning of the year meant it was relatively easy to get some significant performance gains already while also fixing a bunch of long-standing issues along the way. The trouble is I’ll inevitably run out of low-hanging fruit and have to start making bigger architectural changes to keep making progress.
|
|