Re: [hatari-devel] Adding cache support for the MegaSTE |
[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]
Le 13/07/2024 à 22:37, Nicolas Pomarède a écrit :
Le 13/07/2024 à 15:29, Christian Zietz a écrit :Christian Zietz schrieb:Results attached.I struggle to understand the difference between 8 MHz and 16 MHz + 100% cache hits, though. The come out at $19E = 414 HBLs and $A7 = 167 HBLs, respectively, which is a 414/167 ≈ 2.5(!) speed increase.You do a MOVE.W (Ax)+,Dx; DBRA Dy,xxx. The MOVE is 8 cycles, the DBRA is 10 cycles. In 8 MHz mode the DBRA incurs two waitstates (because of unaligned prefetch from ST RAM). Hence, in 8 MHz mode the loop should take 8+10+2=20 cycles, equivalent to 40 16-MHz cycles.Assuming 100% cache hit, in 16-MHz mode the same loop ought to take 8+10 = 18 cycles.But that only would explain a 2.22 (40/18) speed increase. I wonder if the rest is due to overhead in interrupt handling in 8-MHz mode.Do you see a way to modify your test program to run with interrupts disabled, using, e.g., one of MFP timers for time measurement?In my case where I want to compare Hatari with MegaSTE, it's not too much of a problem if counting takes more time, as long as both Hatari and MegaSTE give the same resultbut it's true that an HBL interrupt takes 112 cycles, even with just a "add" in the interrupt. And when you run in monochrome an HBL is triggered every 224 cycles at 8 MHz, so half of the time is spent in the hbl, which is a lot compared to color mode at 50 Hz for example.and even at 16 MHz you loose a lot of cpu just for the hbl int, which makes it harder to really measure cache alone with as little overhead as possible.I will change the measure mode to use a timer and send a new version.
Here's an updated version that uses timer A running at div=100 24576 Hz instead of HBL. Overhead should be very low compared to HBL.
Attachment:
mste_cac.prg
Description: Binary data
Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |