Re: [hatari-devel] Hatari profiler updates and CPU cycle questions

[ Thread Index | Date Index | More Archives ]

Could you somehow verify that it's not off-by-one, like the cycles
information was?

If it is correct in other respects then yes I think so. If it suffers from similar problems to the cycle timings it could perhaps be a challenge.

The difficulty with the cache miss stuff is that it is naturally erratic - some instructions will repeatedly miss, where subsequent instructions will not (especially if they are small) since longword chunks of memory (or whole lines, if UAE is assuming burst mode) get fetched together - it requires some 'reading between the lines' to decide if it's valid, and it's easy to convince yourself one way or the other, more than any of the other figures.

I will study it though to see if I can figure out how accurate it is from specific cases.

Then there's the data cache thing, but as earlier discussed,
that would probably need separate statistics for reads and writes.

Yes this one is more tricky to implement because unlike i-cache, not all instructions have a mapping to the d-cache. Only instructions which reference memory. So it would be necessary to record BOTH misses AND hits in order to get ratios. Misses would not be enough I think, unless hits could be deduced from known instruction types which 'did not miss' (recording hits seems easier if UAE provides it).

Anyway this is probably best left alone until the cycle timing and i-cache misses are verified and any issues fixed, as it will just complicate everything I expect :-)

Mail converted by MHonArc 2.6.19+