Re: [hatari-devel] New option --disable-video and --benchmark

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi,

On 02/26/2017 12:59 AM, Nicolas Pomarède wrote:
Le 25/02/2017 à 23:34, Eero Tamminen a écrit :
not necessarily, some music disk will just start without any user
interaction, so video is not needed if you know you just need to press
up/down arrow later to change song for exemple.

Ok, but one needs to know the software pretty well
beforehand.  Sounds a bit of a corner case. I'm still
in favor of dropping the <bool> and and not having
it in config...

I mean, if it doesn't give clear performance advantage over
existing options, video output being disabled is just a huge
disadvantage.  That makes it *really* marginal use-case.

To validate the --disable-video performance advantage, have
you compared performance e.g. with following options:
	--borders off --frameskips 4 -z 1 --spec512 0
?


<aside>
When you analyze CPU usage, there are few things that you need
to take into account:

* Because task migration between CPU cores messes up CPU
  utilization info, you need to bind task to single core.
  For example:
	taskset 0x1 hatari --tos etos512.img --machine st

* Because all CPUs nowadays have frequency scaling, you need to do
  measuring with a tool that takes CPU frequency into account.
  I'm myself using this:
	https://github.com/maemo-tools-old/sp-memusage (tool)
	https://github.com/maemo-tools-old/sp-measure (library)
  For example:
	mem-cpu-monitor -n hatari

  (It measures only CPU-0 freq, so bind task to first core.)
</aside>


I proceeded to measured Hatari CPU usage for GEM desktop idling,
with borders disabled (and fast-forward obviously disabled), for
following setups:
* SDL_VIDEODRIVER=dummy
* --disable-video on
* --frameskips 0
* --frameskips 4

And while there was ~0.5% variation from run-to-run, there
was no real difference in Hatari CPU usage between above
options, with SDL2 build of Hatari.

As to VBL counts with:
--benchmark --run-vbls 2400 --machine st --tos tos104.img --borders off --fast-forward on

I do get measurable differences:
* 474 VBL/s --disable-video
* 460 VBL/s --disable-video --frameskips 0
* 465 VBL/s SDL_VIDEODRIVER=dummy --frameskips 0
* 426 VBL/s --frameskips 0 --borders on
* 444 VBL/s --frameskips 0
* 468 VBL/s --frameskips 4
* 474 VBL/s --frameskips 4 -z 1
* 477 VBL/s SDL_VIDEODRIVER=dummy --frameskips 4 -z 1

-> --disable-video doesn't provide any performance
   advantage over previously available options and if
   user has disabled the default auto frame-skipping,
   it's actually slower than enabling frame-skipping.


With SDL1 Hatari build (and EmuTOS), the CPU usage results were
quite unexpected:
* 8.5% SDL_VIDEODRIVER=dummy --frameskips 0
* 7.5% --disable-video on --frameskips 0
* 7.0% --frameskips 0
* 6.8% --frameskips 4

-> Disabling video completely getting worse results may be some
kind of kernel power management anomaly, related to whether
things are interactive (poll something), or not.

As to system CPU usage, all the differences were within variation
(which was several percentages), so it was impossible to do any
conclusions on that.


When using 512k EmuTOS, CPU usage was ~7%, when using TOS 1.04,
CPU usage was ~8.5%.
-> I think this is mostly specific to my GEM Desktop idle use-case,
   because EmuTOS uses halt when CPU should idle.

For good measure, I also tried UAE CPU core with "--compatible no":
* 5.7% SDL_VIDEODRIVER=dummy
* 6.3% --disable-video on
* 5.7% --frameskips 0
* 5.5% --frameskips 0 -z 1
* 5.5% --frameskips 4

-> "-z 1" (320x200 instead of 640x400) and "--frameskips 4"
   results being equal is expected, as both drop memory bandwidth
   for screen updates to 1/4th

It's possible that larger CPU usage with "--disable-video on"
is because user doesn't see what's on screen, and mouse moving
accidentally opened some desktop menu, but at least the number
was reproducible (tried 3 times).  Anyway, looks weird.


Conclusions:

* At least on my setup, --disable-video brings no performance
  advantages, just huge usability disadvantage. Better option is
  to use options already mentioned in Hatari manual performance
  section and use EmuTOS

* Surprisingly, video updates don't seem to have much impact on
  CPU usage, unlike ~10 years ago on Nokia's mobile ARM devices,
  which were the reason why I originally added frameskip support.
  I guess things are better optimized on SDL & HW side nowadays,
  and Hatari's CPU emulation takes larger proportion of CPU than
  decade ago


disabling video can make hatari similar to running sc68 (which emulates
only audio, not video), so you can just start hatari with an sndh player
and a sound file, no need for video or interaction with Hatari

According to its www-site:
	http://sc68.atari.org/project.html

It's a plugin to GUI music players, so usability & usage wise
it's IMHO not comparable.


Maybe that should have another option, e.g. --no-ui/--no-gui,
which checks that either remote control socket, natfeats or
--run-vbls is used?

I don't know, depends if there's a user need for that. Do user really
want to run Hatari without ui ? I'm not sure, especially with the
limitation it needs an additional layer (console, natfeats, ...) to
handle events.

Or it could be a warning.

Still, do we need --no-ui/--no-gui ?

I don't know about that, but for the sc68 use-case you gave
as example, it's a better fit than --disable-video option,
as it makes Hatari more plugin-like and requires external
program to use it...

Btw. External program can already send keyboard events to the native
applications e.g. to change the song, so doing the GUI outside
of Hatari for that is already possible.  If launched Atari
program reads some playlist file at startup, host program could
also provide that.


I thought about using --benchmark and --run-vbls 100000 for example,
with SDL UI disabled ; then if you realise you want to stop the program
early, without key events, you will have to wait 100000 vbl (or kill the
process which is not an easy solution for every OS)

If the option enables also "--confirm-quit no",
one can quit Hatari just with Ctrl-C.

"--benchmark" could also enable that.


I'd like to have all keys shortcuts while Hatari is running ; having
just the window created at start but not refreshed later gives a quick
solution to this : shortcuts still work, but SDL calls like Copy/Render
don't interfere with the benchmarking.

Having benchmarks that require manual intervention (besides
interrupting them if there's some problem), sounds really
something that should be fixed before doing benchmarking.


I know I have some real case for --benchmark as it is now to profile
some changes I'm working on ; if people have a need for disabling UI,
let's see, but this looks like a corner case to me that will not
interest many people. At least it can be handled by setting
SDL_VIDEODRIVER for now, not sure it requires an option on its own.

It's shorter than the env setting, more discoverable,
and only few lines of code.

Yes, but is it useful to some people ? I'm not really fond of adding
options just because we can but without knowing if there's a real use
for it. In the end, "hatari --help" will just grow, as well as manuals
and users will read them even less, as it is known that people don't
like reading long help text :)

It can replace the redundant --disable-video. :-)


	- Eero



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/