Re: [hatari-devel] OS X performance problem

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On tiistai 03 kesäkuu 2014, Bob Carpenter wrote:
> I am sure you are running Frantick without its 640K Yamaha sound file. It
> is possible to run the game without the enhanced sound file. This came
> on disk 2. I created an HD floppy to be able to fit everything on one
> disk. I purposely picked Frantick with the 640K frantrak.dat file
> because I wanted something that would take a long time to load with the
> floppy disk.
> 
> Here is the Dropbox link to the HD floppy that I created for Frantick:
> https://dl.dropboxusercontent.com/u/16276054/Frantick.st

This is the same version as I used.  With STE mode it loads the module
in few seconds (with "--slowfdc yes --statusbar yes --fast-forward yes")
and whole thing in 7 secs:
------------------------------------------------
***************************************
*   Frantick Audio Track Detected!!   *
***************************************

FRANTICK RIFFS <1>
Original music by Dave Munsie.
Using YAMAHA keyboards.

***************************************
*   Please turn up the volume...      *
***************************************

639495 Bytes loading...please wait.
------------------------------------------------

"--fastfdc yes" option slightly decreases the time and with
"--statusbar off --drive-led off" it takes ~5 secs in STE mode.

In ST mode, module isn't loaded and startup takes 3 seconds,
regardless of statusbar i.e. it really seems to be related
to disk loading.

With Hatari v1.6.2, it takes 2-3s to start in *STE mode* with
statusbar i.e. it's considerably faster.  Either using ST mode
or disabling statusbar makes startup time into 2 secs.


I.e. the issue seems to be really related to disk load updates
and statusbar.  However, when I profiled it, statusbar update
took only 0.1% and screen drawing calling it only 0.7% of CPU.
This is expected because fast forward uses frame skipping.

(FDC interrupt handling, which isn't involved in CPU usage related
to statusbar updates, took 35% of Hatari CPU.)


What "FS" value you see in statusbar when you enable fast
forwarding (I see default 5)?

Is it same for your old and new Hatari versions?


> Unfortunately, Frantick does not allow you to put the frantrak.dat file
> on a separate floppy.

According to frantrak.doc it does...?


> Because of this, I do not know if HD floppies are
> slower to load than DD floppies. I would have preferred to leave the HD
> floppy out of the equation.

I don't think it matters.


	- Eero
> 
> 
> Bob C
> 
> On Jun 2, 2014, at 4:01 PM, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:
> > Hi,
> > 
> > On sunnuntai 01 kesäkuu 2014, Bob Carpenter wrote:
> >> I am sorry for not doing the tests with the status bar off. Here are
> >> the numbers:
> >> 
> >> 1.7 devel
> >> Fast forward - 25 sec
> >> Normal - 4 minutes 54 seconds
> >> 
> >> 1.8 devel
> >> Fast forward - 8 seconds
> >> Normal - 4 minutes 57 seconds
> > 
> > For me, it loads in ~7 secs with fast forward even with statusbar
> > enabled.
> > 
> > And without fast forward, the loading from (HD) floppy image takes:
> > ~10 secs from clicking the program icon until FRANTRAK data loading
> > starts ~20 secs to load FRANTRAK
> > ~30 secs of different info screens until game gets to start screen
> > = 1 minute in total.
> > 
> > This is under 4MB STE emulation, with:
> > *   Frantick (c) 1994-95 Dave Munsie  *
> > *   V 1.1 - Release date 01/03/1995   *
> > 
> > (Above is game's output with "-conout 2".)
> > 
> > 
> > Which version of Frantick takes 5 minutes to load?
> > 
> > 	- Eero
> > 	
> >> Since I was using the stopwatch on my mobile phone, I would not worry
> >> about a few seconds. It does appear that the status bar has an effect
> >> in fast forward mode. However, when the system is running normally,
> >> it does not appear to have an effect.
> >> 
> >> 
> >> Bob C
> >> 
> >> On Jun 1, 2014, at 3:01 AM, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:
> >>> Hi,
> >>> 
> >>> On sunnuntai 01 kesäkuu 2014, Bob Carpenter wrote:
> >>>> I decided to load the PD game Frantick with its 640K music track
> >>>> into memory from floppy disk. I thought that would be a good bench
> >>>> test since it has to read the floppy disk for a long time before
> >>>> the startup screen appears. Back in 1995, the author recommended
> >>>> loading it on a hard disk if you were going to use the music track..
> >>>> 
> >>>> Anyway, here are the numbers:
> >>>> 
> >>>> In fast forward mode:
> >>>> 1.7 devel version (no track information) - 21 seconds
> >>>> 1.8 devel version (track information) - 58 seconds
> >>> 
> >>> Do you see same difference also with statusbar disabled
> >>> (--statusbar off)?
> >>> 
> >>> * If you still see the difference, it's not because of statusbar,
> >>> 
> >>> but something else, most likely Nicolas' FDC emulation improvements..
> >>> 
> >>> * If difference disappears with statusbar, then the slowdown is
> >>> 
> >>> due to statusbar and needs to be looked into.
> >>> 
> >>> 	- Eero
> >>> 	
> >>>> In real time mode:
> >>>> Both 1.7 devel and 1.8 devel finished in 4 minutes 57 seconds
> >>>> 
> >>>> I do not know of many ST programs that accessed the disk during
> >>>> gameplay. Back when I had my 1040 with only a floppy drive, I would
> >>>> have thrown the disk across the room if it was accessing the disk
> >>>> while I was trying to play the game. Obviously, some games access
> >>>> the disk between levels (Zany Golf comes to my mind). If a game or
> >>>> demo was accessing the disk while running, I could see how the
> >>>> track information could slow things down. I just do not have
> >>>> examples of programs that are running and accessing the disk at the
> >>>> same time.
> >>>> 
> >>>> If you are only updating the information when it actually changes, I
> >>>> do not see how you can really improve this. The only other option
> >>>> would be to make the track information display optional. That way,
> >>>> OS X users that had problems with it could turn it off and they
> >>>> would be no worse than if they ran 1.7.
> >>>> 
> >>>> 
> >>>> Bob C
> >>>> 
> >>>> On May 31, 2014, at 5:11 PM, Eero Tamminen <oak@xxxxxxxxxxxxxx> 
wrote:
> >>>>> On lauantai 31 toukokuu 2014, Bob Carpenter wrote:
> >>>>>> I have only started using the devel version with the changes you
> >>>>>> made. It is running fine. I did not see any improved performance,
> >>>>>> but the performance was fine on Hatari with the previous version..
> >>>>>> Your changes may very well help users with older Macs though.
> >>>>> 
> >>>>> It's not related to how slow machine you have, but what you're
> >>>>> testing.
> >>>>> 
> >>>>> First fix I did was to do statusbar updates only when something
> >>>>> changes.  Now I fixed the case where statusbar actually changes.
> >>>>> 
> >>>>> I.e. you need a test case that causes constant updates to
> >>>>> statusbar state, something that does constant disk accesses.
> >>>>> 
> >>>>> 	- Eero