Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Emulation speed and general performance #157

Open
wavexx opened this issue Jun 27, 2020 · 6 comments
Open

Emulation speed and general performance #157

wavexx opened this issue Jun 27, 2020 · 6 comments

Comments

@wavexx
Copy link
Collaborator

wavexx commented Jun 27, 2020

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
Copy link
Owner

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
Copy link
Collaborator Author

wavexx commented Jun 27, 2020

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
Copy link
Owner

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
Copy link
Owner

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.

@vintagepc vintagepc removed the Wishlist label Oct 8, 2020
@vintagepc vintagepc modified the milestone: Wishlist Oct 8, 2020
@DRracer
Copy link
Collaborator

DRracer commented Oct 15, 2020

@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
Copy link
Owner

Debugging... since I'm basically always doing that. 😉

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/

@vintagepc vintagepc changed the title Emulation speed Emulation speed and general performance Oct 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants