New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Enhanced disk speed" is very slow when debugger is active (1.26.1.0) #383

Closed
peterferrie opened this Issue Feb 14, 2017 · 9 comments

Comments

Projects
None yet
3 participants
@peterferrie

peterferrie commented Feb 14, 2017

No description provided.

@peterferrie peterferrie changed the title from Enhanced disk speed" to "Enhanced disk speed" is very slow when debugger is active (1.2.6) Feb 14, 2017

@peterferrie peterferrie changed the title from "Enhanced disk speed" is very slow when debugger is active (1.2.6) to "Enhanced disk speed" is very slow when debugger is active (1.26.1.0) Feb 14, 2017

@tomcw tomcw added the 1.26.1.0 label Feb 14, 2017

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Feb 17, 2017

Contributor

Hi Peter,

Can you describe the steps that demonstrate this?

When debugging is active (eg. a breakpoint is set, or running in "g" (go) mode) then emulation will run at full speed (aka unthrottled). But debugging is implemented as a single-step mode, ie. one opcode is emulated, then debug checks are carried out (eg. check if any breakpoint has been hit). This single-step mode is naturally slower then normal emulation.

When in normal emulation mode (debugger not active), if the drive motor is on, then "enhanced disk" runs emulation at full speed (aka unthrottled).

NB. There's a bit about the differences between enhanced vs authentic disk speed in #202.

Contributor

tomcw commented Feb 17, 2017

Hi Peter,

Can you describe the steps that demonstrate this?

When debugging is active (eg. a breakpoint is set, or running in "g" (go) mode) then emulation will run at full speed (aka unthrottled). But debugging is implemented as a single-step mode, ie. one opcode is emulated, then debug checks are carried out (eg. check if any breakpoint has been hit). This single-step mode is naturally slower then normal emulation.

When in normal emulation mode (debugger not active), if the drive motor is on, then "enhanced disk" runs emulation at full speed (aka unthrottled).

NB. There's a bit about the differences between enhanced vs authentic disk speed in #202.

@peterferrie

This comment has been minimized.

Show comment
Hide comment
@peterferrie

peterferrie Feb 18, 2017

peterferrie commented Feb 18, 2017

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Feb 19, 2017

Contributor

FYI, Aztec load times running with debugger active (from power-on to "Press any key"):

g 435 ; 435: bit $c000

1.26.1.1: 36s
1.26.0.6: 32s ; NB. #363 meant that the screen wasn't updated (fixed at 1.26.1.0)
1.25.0.4: 10s

NB, my comment about this in #363 was:

NB. With AppleWin 1.26, the video is updated after every debug single-step operation. This gives a cycle accurate video display, but means that the debugger's g command runs much slower than in 1.25. We should probably offer a way for the debugger to ena/disable the cycle-accurate video when debugging (NB. debug single-step is used by more than just g command, eg. tf too).

Contributor

tomcw commented Feb 19, 2017

FYI, Aztec load times running with debugger active (from power-on to "Press any key"):

g 435 ; 435: bit $c000

1.26.1.1: 36s
1.26.0.6: 32s ; NB. #363 meant that the screen wasn't updated (fixed at 1.26.1.0)
1.25.0.4: 10s

NB, my comment about this in #363 was:

NB. With AppleWin 1.26, the video is updated after every debug single-step operation. This gives a cycle accurate video display, but means that the debugger's g command runs much slower than in 1.25. We should probably offer a way for the debugger to ena/disable the cycle-accurate video when debugging (NB. debug single-step is used by more than just g command, eg. tf too).

@peterferrie

This comment has been minimized.

Show comment
Hide comment
@peterferrie

peterferrie Feb 19, 2017

peterferrie commented Feb 19, 2017

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Mar 18, 2017

Contributor

Updated timings after fixes for #217, #291, #384.

On my desktop PC (AMD Phenom II), AZTEC.DSK boot time: (cf. #347)

  • Normal: 2s
  • Debugger, gg cmd: 15.5s
  • Debugger, g cmd: 17s
Contributor

tomcw commented Mar 18, 2017

Updated timings after fixes for #217, #291, #384.

On my desktop PC (AMD Phenom II), AZTEC.DSK boot time: (cf. #347)

  • Normal: 2s
  • Debugger, gg cmd: 15.5s
  • Debugger, g cmd: 17s
@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Mar 18, 2017

Contributor

I've built an experiment (pre-release) 1.26.2.0 version here.

Contributor

tomcw commented Mar 18, 2017

I've built an experiment (pre-release) 1.26.2.0 version here.

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Mar 20, 2017

Contributor

Confirmed by Peter in #389:

Thanks, that solves the write-protect and speed issue

Contributor

tomcw commented Mar 20, 2017

Confirmed by Peter in #389:

Thanks, that solves the write-protect and speed issue

@tomcw tomcw closed this Mar 20, 2017

@tomcw tomcw added the enhancement label Mar 20, 2017

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Apr 14, 2017

Contributor

Normal: 2s
Debugger, gg cmd: 15.5s
Debugger, g cmd: 17s

WHOA -- that's a huge performance hit. AH, timing discussion moved to #347.

Contributor

Michaelangel007 commented Apr 14, 2017

Normal: 2s
Debugger, gg cmd: 15.5s
Debugger, g cmd: 17s

WHOA -- that's a huge performance hit. AH, timing discussion moved to #347.

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Apr 14, 2017

Contributor

Yeah (from above) for the full-speed debug (MODE_STEPPING) case, we have gone from:

  • 1.25.0.4: 10s
  • 1.26.2.1: 15.5s

ie. a 50% slow down for the AZTEC.DSK boot-up time.

TBH, I didn't put any effort into optimising this MODE_STEPPING code-path. My priority was to simplify the MODE_RUNNING case (#347), with the nice side-effect of a small ~16% speed-up for the MODE_RUNNING case.

As you say in #217, having a dedicated 6502/65C02 emulation path for the debug (MODE_STEPPING) case is probably more optimal than hijacking the normal (MODE_RUNNING) emulation path.

Contributor

tomcw commented Apr 14, 2017

Yeah (from above) for the full-speed debug (MODE_STEPPING) case, we have gone from:

  • 1.25.0.4: 10s
  • 1.26.2.1: 15.5s

ie. a 50% slow down for the AZTEC.DSK boot-up time.

TBH, I didn't put any effort into optimising this MODE_STEPPING code-path. My priority was to simplify the MODE_RUNNING case (#347), with the nice side-effect of a small ~16% speed-up for the MODE_RUNNING case.

As you say in #217, having a dedicated 6502/65C02 emulation path for the debug (MODE_STEPPING) case is probably more optimal than hijacking the normal (MODE_RUNNING) emulation path.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment