Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
05733 Misc. Minor Always Oct 16, 2014, 14:21 Mar 29, 2023, 23:15
Tester demotester View Status Public Platform
Assigned To Resolution Won't fix OS
Status [?] Resolved Driver
Version 0.155 Fixed in Version Build
Fixed in Git Commit Github Pull Request #
Summary MESS-specific 05733: sgx: The speed of sgx system has been reduced substantially.
Description The speed of sgx system has been reduced substantially.

I noticed this running the sgx "Axelay" demo on 3 different mess versions: mess0147u4b, mess0148b, mess0155b

Results on my pc (Pentium M 2.13GHz, 1Gb RAM, WinXPSP3):
-------------------------------------------------------------------------------------
- started from mess0147u4b directory ... after pressing F11 => got "skip 0/10 100%" (constant) ..............................the speed is 100%
- started from mess0148b directory ....... after pressing F11 => got "skip 0/10 ~65%" (min_63%, max_67%) .........the speed is ~65% (see Additional Information)
- started from mess0155b directory ....... after pressing F11 => got "skip 0/10 ~50%" (min_48%, max_52%) .........why the speed is reduced ?

JFI ... also, if now start the demo with mess.exe taken from:
--------------------------------------------------------------------------------
- mess0147u4b directory inside of mess0148b directory => got "skip 0/10 100%" (constant) .................................no change in speed
- mess0147u4b directory inside of mess0155b directory => got "skip 0/10 ~65%" (min_63%, max_67%) ..........the speed is reduced ?
- mess0148u4b directory inside of mess0155b directory => got "skip 0/10 ~45%" (min_44%, max_46%) ..........the speed is reduced ?

Note:
mess0147u4b, mess0148b ..... http://www.progettosnaps.net/mess/links.html
mess0155b .................................. http://mamedev.org/release.html
"Axelay_Demo (SGX).sgx" .......... http://www.pouet.net/prod.php?which=24924
Steps To Reproduce 1) create 3 directories => mess0147u4b , mess0148b , mess0155b

2) into each of directory unpack / copy only the according "mess.exe" file and the demo file "Axelay_Demo (SGX).sgx"

3) into each of directory create an .ini file with => mess -cc

4) now start the demo from each directory with => mess sgx -cart "Axelay_Demo (SGX).sgx"
Additional Information The latest messinfo.dat (sgx):
----------------------------------------
WIP:

- 0.148: Convert to using new more accurate video chip device emulation [Wilbert Pol].
Github Commit
Flags
Regression Version
Affected Sets / Systems sgx
Attached Files
zip file icon verbose_showconfig.zip (8,619 bytes) Oct 17, 2014, 11:05 Uploaded by demotester
Relationships
There are no relationship linked to this issue.
Notes
11
User avatar
No.11087
Tafoid
Administrator
Oct 16, 2014, 16:38
Yes, PCE got a major drop in performance when the new video code was added in 0.148. But, I don't understand simply moving your mess to another folder will cause slowdown. You don't really need an .ini file if you use the MAME defaults. Myself, I only use .ini for the roms/media paths.

My testing from 64bit 0.149-0.155 using Intel i5 3.2ghz - Windows 7
I:\OLDER_MAME>mess64_149 tg16 bonk -bench 10
Average speed: 259.52% (9 seconds)
I:\OLDER_MAME>mess64_150 tg16 bonk -bench 10
Average speed: 258.55% (9 seconds)
I:\OLDER_MAME>mess64_151 tg16 bonk -bench 10
Average speed: 264.06% (9 seconds)
I:\OLDER_MAME>mess64_152 tg16 bonk -bench 10
Average speed: 263.77% (9 seconds)
I:\OLDER_MAME>mess64_153 tg16 bonk -bench 10
Average speed: 261.15% (9 seconds)
I:\OLDER_MAME>mess64_154 tg16 bonk -bench 10
Average speed: 261.02% (9 seconds)
I:\OLDER_MAME>mess64_155 tg16 bonk -bench 10
Average speed: 318.45% (9 seconds)

The last drop of yours (if you notice a drop from 0.154 to 0.155), this might be a compile tool casualty. In 64-bit, the new tools have increased performance quite a bit and made smaller binaries. if you could test 32-bit binaries from 0.154 to 0.155 and see if there is a major drop (0.154 was last toolchain), that would be the reason and nothing we can do. Either way, a nearly 10 year old mobile CPU isn't going to hold up well to many modern programs or OS's overhead. Might be time an upgrade. :)
User avatar
No.11088
demotester
Tester
Oct 16, 2014, 17:40
Yeah, without the .ini file 0148 and 0155 versions give the same result => "skip 0/10 ~65%" ... so there must be something in 0155 .ini that causing the speed reduction.

The .ini file was generated with "mess -cc" command for each case, so probably there are some difference inside of each .ini .... but still did not figured out what that could be?

So it seems the point is now on an .ini file generated by mess 0.155 version and not on the mess.exe itself.

Thus would be nice to know what is that setting inside of the .ini that causing the speed reduction in latest 0.155 version.

ps. Yeah, maybe my mobile CPU is not good for newer mess versions, but it run RetroArch pce_module at 100% speed while the CPU itself showing below 30%. How is that possible? :-)
User avatar
No.11089
Tafoid
Administrator
Oct 16, 2014, 18:19
Retroarch can use many cores.. as you have seen. Hard to know what version of MAME or MESS they are using unless they explicitly state version and that gives a lot of false illusions and, to me, makes judging things very confusing.. I"d have to guess it is another emulator's PCE emulation (mednafen) or a much earlier version of PCE/TG16 MESS from many years ago.

You could run from command-line with -verbose, this would tell you if something fails like video or otherwise. Some settings in .ini are not the same between version so it is quite possible recent changed behavior in sound/video might be an issue.
You also can also run "-showconfig" to list what MESS is using as its settings and see if that helps.
User avatar
No.11090
demotester
Tester
Oct 16, 2014, 18:59
Hmm, my last post (11088) is not true ... testing in mess0155b directory it seems I made an mistake thinking I had 0155 exe when removed the .ini file, but I had an 0148 exe version that shows ~65% w/o .ini and I get wrong conclusion ... the 0155 shows the same ~50% with or without the .ini file.

So, yes, if mess0148 running in mess0155 directory with created mess0155 .ini file, it will run slower, but w/o the ini it will run at same speed as it runs in mess0148 created directory ... what means, the mess0155 created .ini has influence only on older mess0148 making it slower. (sorry for inconvenience)

But still the mess0155 w/o the .ini is slower than mess0148 w/o the .ini file. (and that is the point)
User avatar
No.11093
B2K24
Senior Tester
Oct 17, 2014, 04:39
Using official 0.155 MESS X64 on my i7 930 @ 2.8 GHz, The Average speed is always 100.00% whether I let the demo run for 60 seconds or 600 seconds
User avatar
No.11095
demotester
Tester
Oct 17, 2014, 11:08
edited on: Oct 17, 2014, 11:12
Using MESS X32 on my Pentium M @2.13GHz - WinXPSP3:
------------------------------------------------------------------------
------------------------------------------------------------------------
mess sgx -cart "Axelay_Demo (SGX).sgx" -bench 10
------------------------------------------------------------------------
mess0147u4b . Average speed:178.77% (9 seconds)
mess0148b ... Average speed: 81.06% (9 seconds)
mess0155b ... Average speed: 59.07% (9 seconds)
------------------------------------------------------------------------
------------------------------------------------------------------------
mess sgx -cart "Axelay_Demo (SGX).sgx" -verbose > verbose.txt
mess sgx -cart "Axelay_Demo (SGX).sgx" -showconfig > showconfig.txt
--------------------------------------------------------------------------------------------------
verbose and showconfig is in attached .zip file
User avatar
No.11096
demotester
Tester
Oct 17, 2014, 13:39
edited on: Oct 17, 2014, 13:52
... and comparison with the pce system speed
-------------------------------------------------------------------------
-------------------------------------------------------------------------
mess pce -cart "CMC_Courage.pce" -bench 10
-------------------------------------------------------------------------
mess0147u4b . Average speed: 408.94% (9 seconds)
mess0148b ... Average speed: 141.45% (9 seconds)
mess0155b ... Average speed: 97.42% (9 seconds)
-------------------------------------------------------------------------
-------------------------------------------------------------------------

JFI ... and comparison with the megadriv system speed
-------------------------------------------------------------------------
-------------------------------------------------------------------------
mess megadriv -cart "day_trip.BIN" -bench 10
-------------------------------------------------------------------------
mess0147u4b . Average speed: 294.71% (9 seconds)
mess0148b ... Average speed: 298.58% (9 seconds)
mess0155b ... Average speed: 210.07% (9 seconds)
-------------------------------------------------------------------------
-------------------------------------------------------------------------
User avatar
No.11097
Tafoid
Administrator
Oct 17, 2014, 14:29
edited on: Oct 17, 2014, 14:53
You cannot compare system to system, regardless of the speed of the processors or other seemingly comparable statistics. Megadrive has other issues that might have slowed it down - adding the carts in the new slot system and having complete mappings has been known to make performance drop as well as the modernization/devicifying of the main graphics part (315-5313).

That said, I was reminded of a command which from 0.148 onward is not on by default called multithreading (-mt).
Add -mt to your tests and see if it improves.
User avatar
No.11098
demotester
Tester
Oct 17, 2014, 15:37
edited on: Oct 17, 2014, 15:52
Hmm, no change also with -mt command ... perhaps because my cpu is single core.

Yeah, megadriv system was mentioned just for info ... it only shows that there was no difference in speed between megadriv system in 0147u4b and 0148b versions.

ps. I just wonder, does this "improvement" in the accuracy of the PCE driver can justify such a large difference in speed? (ie. whether there is a room for optimization of the driver)
User avatar
No.11104
NekoEd
Senior Tester
Oct 18, 2014, 04:02
This is no longer new, and is under investigation. Acknowledging.
User avatar
No.21233
Kale
Developer
Mar 29, 2023, 23:15
edited on: Mar 29, 2023, 23:17
There's no investigation here, and the report is so old that it isn't relevant anymore.
If anybody has ideas about how to improve the performance then I'm gonna listen but in a github issue, closing here.