Re: [hatari-devel] Feature request/idea: cycle counting

On 1 February 2018 at 07:27, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:

You were talking about cache hits & misses, which on 030 can have
a huge impact on performance. That's a run-time property dependent
on what you've run before (e.g. are you doing things in a loop, how
long your loop is etc).

I'm sorry, I should stop expecting other people reading my mind. :)

This is basically what I often do: I have some code (either mine or someone else's) and wondering how much I gain if using this or that approach (different addressing, reordering instructions, different head/tail offloads etc). So what I would do is to setup a breakpoint (say in the beginning of a loop), look at the "timing tagged" code, let it run for one iteration and look again -- which instructions gained from the cache most, which instructions still take the most cycles etc. Using the disassembly view (so I'm not flooded with every instruction, only the loop I'm interested in).

So you see, it's a very fine-grained work.

And while I agree it's not 100% related (or even useful) to profiling, if it's something easy to add, I'd even maintain my own branch for it, that's how useful I find it. Especially with all that recalculation needed for Falcon 16-bit bus where you have to do quite a few calculations by hand even if you have numbers from the timing table (which assumes a 32-bit bus).

Only execution of the instructions with the CPU emulation code
considers these things, disassembly considers each line only in
isolation.

I'm aware of that, see above for my detailed explanation. We are in agreement here.

I.e. you need to run the code for cycle information.

Yes.

MiKRO / Mystic Bytes
http://mikro.atari.org