|Re: [hatari-devel] Suspected problem iwith TimerD patch|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 12/10/20 4:31 AM, Roger Burrows wrote:
On 10 Dec 2020 at 1:55, Eero Tamminen wrote:
On 12/10/20 1:22 AM, Roger Burrows wrote:
On the EmuTOS list, Eero reported that the program Bomb Squad
a lot more slowly under EmuTOS (latest version) than under TOS4.04 (both
running under Hatari 2.2.1). After lengthy investigation, I believe that
is caused by a Hatari problem.
....> Are you saying that you don't do a TimerD patch any more? Or that
> it's not done for Falcons?
I'm saying that your change doesn't apply anymore
to Hatari v2.3, but that's irrelevant, because:
* There's a command line option and GUI setting to
enable/disable timer-D patching, one doesn't
need to change Hatari code for that (by default
Timer-D patching is disabled in Hatari)
* While Timer-D can have very noticeable *Hatari*
performance impact, I don't see any noticeable
impact on the emulated game, EmuTOS or TOS4
performance. They still have the same 4x
performance difference, regardless of whether
timer-D is patched or not.
=> I don't think your conclusions to be correct
(Currently Hatari compatibility list contains 2
ST games where timer-D causes color raster issues,
and one ST game where it impact music speed.)
This game doesn't need DSP, so you can run it
with "--dsp none" for a large emulation perf
Game works also without CPU cache emulation (like
many other Falcon programs that don't communicate
with DSP), so you can disable that too, with
"--cpu-exact off", for another large perf boost.
I really don't care about the game. I was reporting why it runs slower under
To make deductions about the visual emulated
Atari code speed you first need to make sure
that you aren't fooled by Hatari emulation
Former is affected by what the emulated programs
do and Hatari emulation accuracy, latter is
affected by the speed of your computer and Hatari
emulation efficiency and which parts one chooses to leave not emulated
(due to them being
irrelevant for what one is measuring).
What I mentioned above is generally applicable,
it's not specific to this particular game. And if
there isn't anything which emulation you could
disable or degrade without affecting what you're
trying to measure, you need to use profiler.
Because the performance gap between EmuTOS and TOS4 in this game is so
huge (4x), one can do
the comparison even by counting VBLs between game
Bconstat calls (2 VBLs with TOS4, 8 with EmuTOS).