vintagepc / MK404

A functional Simulator for Prusa (Mini/Einsy) Rambo based printers
https://vintagepc.github.io/MK404/
GNU General Public License v3.0
72 stars 9 forks source link

Emulation speed and general performance #157

Open wavexx opened 4 years ago

wavexx commented 4 years ago

I was checking simavr directly, but I don't see any option to set the runtime speed, only the emulated cpu frequency?

When running with the intention of scripting you could as well emulate the system as fast as the host can go.

vintagepc commented 4 years ago

I think the one thing you'd have to be careful of is that you might end up with irregular clock speeds, if there are events that have a lot going on, it's going to run a little slower than if there is less activity.

It probably doesn't matter for scripting. It might be possible to just add an option to override the MCU speed (or better, set a clock multiplier; you might get undesirable effects if, for example, the main printer runs at 32Mhz and the MMU is still clocking at 8.

wavexx commented 4 years ago

What I meant was the ability to decouple the clock speed from the actual speed of the emulation. This means setting only timers based on cpu cycles (so that they're accurate for the emulated board), and removing the internal sleeps after instruction processing.

This would allow to process instructions as fast as the host can go while still delivering timers and interrupts at the requested CPU rate.

The emulated system shouldn't see time passing differently.

At a first glance, simavr doesn't offer this out of the box. So, probably a lofty goal ;)

vintagepc commented 4 years ago

Yeah, in theory it should work for a single MCU, but I am pretty sure it will fall apart if you have two that need to communicate, because they are not locked to each other and have separate threads. I still think explicitly scaling the clock rate of the MCU is the most maintainable approach, otherwise you're going to end up with non-deterministic or system specific behaviour when using an MMU2 in this mode. The MMU isn't faked, it's legitimately running a second AVR simulation for that. If you set the scaling value high enough it should have the same net effect.

vintagepc commented 4 years ago

Hmm... I tried messing with the clock speed of the CPU as well as commenting out the simavr sleep cycle. It doesn't seem to have had all that much effect, appart from the LCD module getting annoyed that it's being written to while still busy. Still appears to run at roughly the same rate.

DRracer commented 4 years ago

@vintagepc is there a reason for not enabled optimizations? Just did a quick and dirty hack in the main CMakeLists.txt and my sim runs ~2x faster even than realtime (filename scrolling, visualization, moves ...).

....
if (ENABLE_GCOV)
    target_compile_options(MK404 PRIVATE -g -O0 -fprofile-arcs -ftest-coverage)
    target_link_libraries(MK404 -coverage -lgcov)
    add_definitions(-DTEST_MODE)
    set(CMAKE_CXX_OUTPUT_EXTENSION_REPLACE ON)
else()
    target_compile_options(MK404 PRIVATE -O2 -flto -mcpu=native -mtune=native)
    target_link_libraries(MK404 -flto)
    set(CMAKE_CXX_OUTPUT_EXTENSION_REPLACE OFF)
endif()

-O3 crashes on my box when starting printing though, I assume gcc 10.2 doesn't understand something correctly

Or is it just a coincidence of recent changes in master branch?

vintagepc commented 4 years ago

Debugging... since I'm basically always doing that. :wink:

But these values (or, at least, -O and -g are implicitly controlled by -DCMAKE_BUILD_TYPE=(debug or release):

https://cristianadam.eu/20190223/modifying-the-default-cmake-build-types/